Chromium Blog: A New Crankshaft for V8
blog.chromium.org
blog.chromium.org
I'd find it hard to believe that Goog would make the same mistake after all the hullaballoo, but I'd love to see it validated.
Reading sentences like this scare me because it reminds me that some people don't know what the 'var' keyword means or think it's acceptable to shove everything in window or global.
for(var i=0; i<3; i++) { console.log(i); }
function foo() { var x = 1; if (true) { var x = 2; var y = 3; } console.log(x); console.log(y); }
foo(); // 2, 3 (vs 1, undefined if there was block scope)
function(){ var i; … for(i=0; …
alert(i);
var i;
alert(k);
var i;
What the IE team got wrong was the assumptions they made about the semantics of the code that was optimized. If they had checked for the presence of a valueOf property, they could still have done the optimization.
In essence I'm asking if Google does in fact do this check, and does analysis to ensure that the valueOf method doesn't get written dynamically in the loop itself.
Does this mean Crankshaft includes a tracing JIT like Firefox? This layman speak confuses me.
self->hotspot->V8
self->hotspot-> Resilient Smalltalk Embedded Platform ->V8
In other words, they're paving the way for the future more so than trying to squeeze every last ounce of speed from current applications (which just happens to be a great side effect of their work).
"A good hockey player plays where the puck is. A great hockey player plays where the puck is going to be." — Wayne Gretzky
We may not even be equipped to answer that question. There are a lot of web-based but private & internal corporate applications that we'll never know about, and can't hope to name.
Canvas and WebGL games.
I had assumed we were reaching some theoretical upper-bound because all major frameworks were on par in terms of performance.
That's not necessarily the whole answer and I imagine JS can't ever quite go that fast. But still....
I'm not the most knowledgeable person on the subject, but from what i understand, there is no theoretical reason that JS couldn't go that fast. The two languages are more similar than they are different, even if JavaScript is quite more complex.
I remember Mike Pall saying something similar in an LTU thread some time ago.
He did and the mozilla guys pointed out how this wasn't the case. The languages are very similar but JS has some weird semantics due to how things are scoped. (ref. the Chakra optimization brouhaha a month ago)
I'm not confident enough in my memory to write out a probably incorrect list of things I remember. Here's a list of the various things I've read from Brendan in case you're interested in tracking it down:
http://lambda-the-ultimate.org/node/3851#comment-57671
This is the LtU thread my previous comment referred to. It's a large (and fantastic!) thread, but I believe that comment and children are the most direct comments back and forth between Mike and Brendan. Andreas Gal is also on the thread and from Mozilla.
http://www.aminutewithbrendan.com/
Brendan's weekly JS podcast. They're relatively accessible and generally cover a lot of area. A good way to get in the language zeitgeist.
Brendan's blog, mostly focuses on ES Harmony stuff and Mozilla specific topics.
I'm not familiar with Lua, beyond reading an article or two about it, but does its simplicity imply some sort of maximal efficiency? Are the developers behind Lua simply the best programmers in the world and already have everything figured out with regard to optimizing a JIT? I'm not arguing with you...it does seem like that's a reasonable goal for JavaScript JITs to strive for in the near future. But, it doesn't really answer the question of how much better performance can get (in JavaScript or Lua or any other language). Past performance is not necessarily indicative of future performance when so many people are working on the problem from so many angles.
You can gain another factor of 2 or so in speed by going to a static language like C or Ada, but that isn't really a fair comparison and you can see the price paid in code size.
The good news for the web is that there may be another factor of 2 to 3 available for Javascript speedup.
(The conventional "JIT can be faster than compiled code" argument doesn't apply because the problems are accurately known by the author of the shootout benchmark code in advance, so, for instance, if there's a speed advantage to sticking with 'char' where you might have been tempted to write 'int', the C shootout code already does that.)
Doing this in a static compiler is hard, because it would have to compile both paths for every such disambiguation possibility. This quickly leads to a code explosion. You'd need very, very smart static PGO to cover this case: there are no branch probabilities to measure, since the compiler doesn't know that inserting such a branch might be beneficial. It may only derive this by running PGO on code which has these branches, which leads to the code explosion again.
Auto-vectorization is another example: a static compiler may have to cover all possible alignments for N input vectors and M output vectors. This can get very expensive, so most static compilers simply don't do it and generate slower, generic code. A JIT compiler can specialize to the runtime alignment and even compile secondary branches in case the alignment changes later on (e.g. a filter fed with different kernel lengths at runtime).
VLIW (compilers try to optimize processing based on static knowledge - e.g. Intel's Itanium) vs. the current Intel CPUs (based on P3/P4 architecture) which dynamically allocate resources depending on runtime knowledge.
Runtime information can help compilers. Just look at profile guided optimizations in current static compilers.
The real trouble in JIT compilers is usually that the target languages semantics are very high level. For example an integer in C is machine sized and is not expanded in size to fit its value -- unlike some dynamic languages.
This link doesn't quite give what you are after (it's mostly about static compilation in the Java HotSpot compiler), but I believe the lock elision features (http://www.ibm.com/developerworks/java/library/j-jtp10185/in...) have to be done at runtime in the JVM (because of late binding).
Obviously this doesn't totally invalidate your argument ("except in the cases where runtime code loading is used"), but it is worth noting that in many languages late binding is normal, and so this is the general case.
Also, HP's research Dynamo project "inadvertently" became practical. Programs "interpreted" by Dynamo are often faster than if they were run natively. Sometimes by 20% or more. http://arstechnica.com/reviews/1q00/dynamo/dynamo-1.html
Think about it this way: a 20% difference isn't unrealistic if you compare -O1 vs. -O3.
But it's completely unrealistic to expect a 20% improvement if you'd try this with the machine code generated by a modern C compiler at the highest optimization level.
There's no theoretical limit to how close a compiler can come to a programmer when it comes to generating machine code to do a particular well-defined task.
It looks like Chrome 8 went stable on 12/2. So we'll see Chrome 10 in 4 months?
The releases are overlapped though, so we are testing v n+1 in beta while v n is in stable, and we are starting new feature development for v n+2 while v n is in stable.
Chrome 8 just went stable, and we've just started testing Chrome 9.
So crankshaft will either be 6 weeks from today (if it's in 9), or 12 weeks from now (if it's in 10).
I don't think it's been announced which it's targeted for.
HTH
> I don't think it's been announced which it's targeted for.
According to the perf comparison chart on the blog, it's in Chrome 10. Also, it's mentioned that Crankshaft is available in the canary build, which is currently at 10 too.
12 weeks then. I sometimes revert back to FF for the plugins, but I always come back to Chrome for the perf :).
LuaJIT2 is still in beta, but it is already very stable. Performance-wise, it is comparable to Haskell and Java.
There is a separate effort to write a JIT complier for Lua on top of the LLVM, but the performance is not as good as LuaJIT, and reaching such a level will be very complex, (assuming it's possible).
Sage (a open source replacement for matlab) uses it quite successfully for speeding up critical paths.
Check out: https://www.cloudkick.com/blog/2010/aug/23/writing-nodejs-na...
http://www.syntensity.com/toplevel/intensityengine/
worked out very well there.
Of course the real examples are... web browsers, which are C++ apps that are scripted by a JavaScript engine. Seems to work good there as well ;)
From what I understand, the significant improvements in speed come from Crankshafts tradeoff of compilation optimisation for startup speed. If your app is a for loop with 2 iterations that code path won't be heavily optimised as the interpreter would potentially be more spending more time compilation code than in execution of unoptimised code. It will therefore startup faster. However, hotspots (loops with 1,000 iterations, per se) will be heavily optimised.
This is great for websites as speed and responsiveness is perceived as startup time. You'll certainly notice a difference when using the Node as a scripting tool. However, most Node applications are long running servers executing the same code paths over and over. Its unlikely that Crankshaft is performing any extra optimisations, it is just changing when it performs these optimisations. However, if Crankshaft _is_ doing significantly more advanced optimisations (I don't know) then, yes, Node will benefit. Please correct me if I am wrong, I would love to be.
> In addition to improving peak performance as measured by the V8 benchmark suite, Crankshaft also improves the start-up time of web applications such as GMail.
As I understand it, there is more to Crankshaft than just startup time improvement.
It generally takes about 10-20 years to get truly new ideas from the labs to consumer-level products.
I think you are confusing tracing with adaptive compilation.