Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Looks like the response I would expect from someone who has seen tons of "Why not just compile it and see it get magically faster?!?!" queries.

It's easy to compile it, but making the compilation actually useful for a dynamic language is HARD. There's a reason that most dynamic languages will either interpret or JIT, and it's not because the JIT writers overlooked something obvious.

A naive translation of the code will remove a little bit of overhead from the bytecode dispatch, but the resulting code bloat will blow out instruction caches for any reasonable sized code. In small programs with one translation unit, analysis can sometimes work to speed things up, but it quickly becomes either undecidable or intractable.

Basically, on dynamic languages, you can often see static compilation being worse than a naive attempt at native code, especially once the hot path for the interpreter fits in cache, but the generated native code no longer does. Wanting to see results on real world benchmarks is entirely reasonable.



I don't know. Lua (the non JIT version) runs circles around Python -- without compilation.

And when adding compilation into the game, I don't see CL as any less dynamic (probably more) than Python, and yet it goes to near C speeds too.


CL goes near C speeds with an INCREDIBLE amount of work to make your program as static and C-like as possible. It also requires intimate knowledge of your particular implementation.

Sometimes it's not even possible (!) to get C speed because of things like float boxing across function boundaries.


I'll give you that -- but, while not C-speed, it still runs circles around Python when coding in a idiomatic style too.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: