It's amazing how much faster dynamic languages can run with some engineering effort. It's also frustrating, because it contrasts starkly with my PHP code's performance. I wish the PHP team had the resources to do this kind of work, because at this point it's the slowest subcomponent in my stack.
I learned about this when watching Avi Bryant's great talk "Bad Hackers Copy, Great Hackers Steal" : http://vimeo.com/4763707
He explains that dynamic languages are not inherently slow. It's their current implementation that's slow. Java is not fast thanks to static typing, it is fast thanks to the Hotspot VM, which builds upon the StrongTalk VM implementation.
Quote taken around the 13" mark (some trolling included ;) ):
"Ruby has the dynamic part, and Java has the fast part. And this has led to this assumption that people have that the reason that Java is fast and Ruby is slow is because Java is static and Ruby is dynamic. And that's just not true, that's just a myth. Nothing about Java being fast has anything to do with it being static. It's simply that the papers that the Java people read were the ones that told you how to make it fast, and the papers that Matz read were the ones that told you how to make it usable."
> I wish the PHP team had the resources to do this kind of work, because at this point it's the slowest subcomponent in my stack.
That's a business opportunity. PHP is not my bag, but an interested compiler hacker could make a quick trace JIT (a la Dalvik), license it out, and probably get a fair bit of cash.
Is that still true for you if you use APC? What if you use nginx instead of Apache? In our experience, APC makes an order of magnitude difference, and nginx makes several.
Hopefully projects like HLVM will be able to fix that by proving a very good target for dynamic language implementations. It's a very ambitious project that's in relatively early stages, but seems promising.
> I guess that v8 is leading a revamp in the languages.
1. v8 is an implementation, not a language, so it hardly makes sense to say v8 is leading a revamp in the languages.
2. most of v8's behaviors were pioneered by Self and put to task in JVMs (HotSpot and — even earlier — Jikes RVM) and Strongtalk (v8's assembler comes in significant parts from strongtalk, I believe), so it hardly makes sense to say that v8 is leading unless you restrict this to the pretty small world of javascript in-browser runtimes.
3. finally, other browsers were already walking down the route of JITs when Chrome arrived (Tracemonkey landed in Firefox trunk in October 2008)
V8 is definitely a strong work of software engineering put to good use, but the amount of inane praises are grating: it's not magic and it's mostly the application of preexisting practical research and development (meaning stuff which was already used, not just research papers).
I don't think so, in my experience working on dynamic languages there's no need to kill bytecode, it's a useful intermediary form, as you still need either a stage-one compiler or an interpreter anyway, and interpreters are (to a first approximation) easier to write.
I think ceyusa was referring to the elision of bytecode as an intermediate step. Interestingly though, my assertion that V8 kept around the AST was wrong: it keeps around the source, and re-parses as needed. So maybe it's JavaScript that is the new bytecode now...
