V8: a tale of two compilers | Hacker News Reader

V8: a tale of two compilers

wingolog.org

113 pointsp4bl017 comments

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.

Have you tried HipHop? https://github.com/facebook/hiphop-php

That is a PHP to C compiler, is it not?

Wrong on both (but not far off) :P a) It's a "restricted subset of PHP" it doesn't compile the entire language, b) it compiles to C++.

Wow. Anytime I hear about people choosing C++ as their target, I have mingled feelings of awe and uneasiness.

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.

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.

> It's amazing how much faster dynamic languages can run with some engineering effort

It's a bit more than just "some", and it's an evolution 20 years[0] in the making[1].

[0] http://en.wikipedia.org/wiki/Self_(programming_language)

[1] http://en.wikipedia.org/wiki/StrongTalk

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.

apt-get install php5-xcache

I guess that v8 is leading a revamp in the languages. Even perhaps the bytecodes will die!! the AST IS the bytecode :D

What?

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...

> 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).

in fact firefox trace and jaeger monkey are pretty nice themselves if not more than v8. theyre also faster often time

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.

Reply on news.ycombinator.com