9 ms·
Chromium Blog: A New Crankshaft for V8
- greattypo 16y agoThe Chrome javascript engine team is simply a beast.
- CJefferson 16y agoHas anyone got any experience using javascript/V8 as a scripting language for a C++ app? We currently use python with boost::python bindings, but are finding we have to limit the amount of python code, as it is too slow.
- tlb 16y agoAt Anybots, we built all the real-time robot code in Python with performance-critical bits in C++ wrapped using boost::python. Server code is in pure Javascript on Node.JS. I haven't tried to integrate C++ into Node, but it looks easy.
- kqr2 16y agoHave you looked into lua? It's a good embedded scripting language. http://www.lua.org/ http://www.lua.org/
- pygy_ 16y agoEspecially, for x86 and x64, where you can use LuaJIT. LuaJIT2 is still in beta, but it is already very stable. Performance-wise, it is comparable to Haskell and Java. http://luajit.org/ http://luajit.org/
- nitrogen 16y agoAre there any plans to port LuaJIT to ARM or LLVM? I see a couple of posts mentioning slow FP performance on ARM, but that could be solved with a technique like that used by LNUM.
- joeyo 16y agoThere is sponsorship for a PPC LuaJIT port (targeting embedded systems, I believe) and Mike Pall has expressed interest in an ARM port in the past, but I don't know what the status of that is.
- nitrogen 16y agoPPC LuaJIT sounds like it would be useful in console games (Why did the big three consoles switch to PPC just as Macs switched to Intel, anyway?).
- pygy_ 16y agoThe LLVM IR is too low level. It loses some context necessary to get the performance of the tailored JIT written by Mike Pall. 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).
- pjscott 16y agoAlso, the language itself is pleasant and straightforward. If you know other modern programming languages, Lua shouldn't be too surprising.
- DanielRibeiro 16y agoEver looked into Cython? http://www.cython.org/ http://www.cython.org/ Sage (a open source replacement for matlab) uses it quite successfully for speeding up critical paths.
- russell_h 16y agoThats essentially what Node.js is, although with a heavy focus on asynchronous operation. Check out: https://www.cloudkick.com/blog/2010/aug/23/writing-nodejs-native-extensions/ https://www.cloudkick.com/blog/2010/aug/23/writing-nodejs-na...
- azakai 16y agoSyntensity moved from Python to JavaScript as an embedded scripting language, http://www.syntensity.com/toplevel/intensityengine/ 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 ;)
- ashot 16y agounreal. how much theoretical headroom is left to optimize js compiler performance? I had assumed we were reaching some theoretical upper-bound because all major frameworks were on par in terms of performance.
- jerf 16y agoTo a first approximation, my answer would be something like http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=luajit&lang2=v8 http://shootout.alioth.debian.org/u32/benchmark.php?test=all... . That's not necessarily the whole answer and I imagine JS can't ever quite go that fast. But still....
- Raphael_Amiard 16y ago> and I imagine JS can't ever quite go that fast 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.
- grayrest 16y ago> 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)
- thasmin 16y agoWhen Chrome was released two years ago, I noticed a significant difference in speed. Nowadays I think the announcements JavaScript performance improvements is a bit overenthusiastic. The only real world benchmark mentioned in the article is that Gmail loads 12% faster. What JavaScript apps are constrained by performance and what are Crankshaft's effects on them?
- InclinedPlane 16y agoMuch web client JS is constrained by dom speed so this will only have an incremental effect. However, for node apps this willbe pretty significant.
- pohl 16y agoI'm happy that the various javascript teams are developing towards where the web is going rather than where it is. "A good hockey player plays where the puck is. A great hockey player plays where the puck is going to be." — Wayne Gretzky
- timtadh 16y agoI don't think the GP would disagree with you. I believe he was asking what specific apps benefit today (besides GMail which was mentioned in the blog).
- pohl 16y agoI'm guessing you're right. I was responding to the tone of "Nowadays...overenthusiastic" — in support of enthusiasm — and to the notion of naming specific current apps — which I'm imagining as the puck's current location. 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.
- silentOpen 16y agoThe coming WebGL games desperately need all the performance they can get.
- Splines 16y agoSo - how long does it take for features to make their way into production? Am I reading the release calendar correctly in that it'll take 12 weeks from start of development to beta, and another 12 weeks from beta to stable? It looks like Chrome 8 went stable on 12/2. So we'll see Chrome 10 in 4 months?
- aboodman 16y agoChrome stable releases are every 6 weeks. 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
- Splines 16y agoAh, ok. I guess I misread the release calendar. Thanks for the clarification :). > 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 :).
- kenjackson 16y agoI'm curious to see if they broke any code, like the IE engine did recently. For example, with loop-invariant code motion, what is legal in a language like C, may not be in Javascript (for same reason the IE DCE optimization was invalid). 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.
- pbiggar 16y agoLoop-invariant code motion is still legal in JS, and most dynamic languages, as is DCE. You just need to take into account the weird semantics of JS. 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.
- kenjackson 16y agoExactly. I'm not saying those opts aren't legal, but in cases that look legal in C, they're not legal in JS. And note, you can still do it in the presence of a custom valueOf method, as long as it doesn't have side effects (and thus of course loop-invariant itself). 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.
- VMG 16y agoI'd like to have a guide for writing code that is easily optimized by V8 and similar engines. Having local variables is good, as far as I can tell, but it would be nice to have a full overview with dos and don'ts
- drivebyacct2 16y ago"Having local variables is good" 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.
- todd3834 16y agoWill this have any effect on NodeJS?
- jrockway 16y agoSeems like it should.
- tlrobinson 16y agoSure, I would expect node.js to be an ideal environment for this type of hot code analysis, since servers written with it are typically long running vs. more transient web pages. Of course whether there are significant gains depends a lot on whether your server is CPU-bound or IO-bound.
- mxavier 16y agoThis seems like it would be huge for the Node.js people. The next big milestone for V8 for node has to be the GC issues that have been wreaking havoc on node apps under high load.
- chrislloyd 16y agoI doubt it. 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.
- nene 16y ago
- swannodette 16y agoIt will be interesting to see how this optimization affects V8's memory profile (and how that in turn affects the currently slim memory profile of Node.js).
- dtwwtd 16y agoIt will also be interesting to see if this improves performance of long running Node.js scripts.
- panarky 16y agoLooks like this Node patch includes Crankshaft: https://github.com/ry/node/commit/c30f1137121315b0d3641af6dc61e3b047f940e1.patch https://github.com/ry/node/commit/c30f1137121315b0d3641af6dc...
- natmaster 16y ago"...performance of JavaScript property accesses, arithmetic operations, tight loops..." Does this mean Crankshaft includes a tracing JIT like Firefox? This layman speak confuses me.
- scott_s 16y agoYes, look at the list of the four main components.
- pbiggar 16y agoI don't think that says it uses a tracing compiler (naturally the terms are vague in this field, so I'm not certain). Their architecture looks much more like HotSpot than TraceMonkey.
- wmf 16y agoEspecially considering that HotSpot and V8 were designed by the same person.
- pbiggar 16y agoI don't think this is true. Do you have a reference for that?
- maw 16y agoSee the first and fourth paragraphs of http://en.wikipedia.org/w/index.php?title=Lars_Bak_(computer_programmer)&oldid=399837027 http://en.wikipedia.org/w/index.php?title=Lars_Bak_(computer....
- codebaobab 16y agoThis may not be 100% literally true, but it is definitely true in spirit. (The previous poster is referring to Lars Bak, but both Hotspot and V8 are/were team efforts.) The family tree here is: self->hotspot->V8 But, yes, Lars is the man.
- cosgroveb 16y agoGmail really does seem to load in about half the time now in the Canary build.
- ams6110 16y agoOTOH this does not bode well for the future potential bloat in Gmail.
- StuffMaster 16y agoSounds like they borrowed the tracing idea from mozilla.
- scott_s 16y agoNot really. It's a well-known VM optimization technique.
- cpr 16y agoFirst featured in Self many years ago, done by the same folks (Lars Bak and crew) who brought you V8. Then Sun bought their Smalltalk/Self-based company, and they built HotSpot for the JVM. Then Google hired them to do the same for Javascript, and now we have V8. It generally takes about 10-20 years to get truly new ideas from the labs to consumer-level products.
- effn 16y agoNeither Self nor HotSpot uses tracing. It's a relatively new compilation technique, the implementation in the original tracing paper used java bytecode as the source language. I think you are confusing tracing with adaptive compilation.
- kingkilr 16y agoActually there's even older work using tracing for re-optimization of assembley :)
- grayrest 16y agoThey don't mention that they're tracing. I think they're just optimistically optimizing functions in hot loops.
- erik_landerholm 16y agoI thought someone was actually developing a new kind of crankshaft for a real V8 engine....
- eru 16y agoDoesn't `Chromium Blog' and the URL give it away?
- jorangreef 16y agoNext up, remove the 1.9GB max memory limit of V8 processes: http://code.google.com/p/v8/issues/detail?id=847 http://code.google.com/p/v8/issues/detail?id=847
- tsta 16y agoI've benchmarked Google Chrome 9.0.597.10 and 10.0.603.3 (with Crankshaft) and the latter is 30% faster. See the detailed results: http://dromaeo.com/?id=124912,124913 http://dromaeo.com/?id=124912,124913