Slashdot Log In
Next-Gen JavaScript Interpreter Speeds Up WebKit
Posted by
timothy
on Tue Jun 03, 2008 02:48 PM
from the zippity-zappity dept.
from the zippity-zappity dept.
JavaScript is everywhere these days. Now WebKit, the framework behind (among others) Safari and Safari Mobile, as well as the yet-unreleased Android, is getting a new JavaScript engine called Squirrelfish, which the developers claim provides massive speedups over the previous one. The current iteration of the engine is "just the beginning," they claim; in the near future, six planned optimizations should bring even greater speed. With JavaScript surviving as a Web-page mainstay despite many early gripes, and now integral to some low-powered mobile devices, this may mean many fewer wasted seconds in the world.
Related Stories
[+]
Technology: Apple's SproutCore, OSS Javascript-Based Web Apps 203 comments
99BottlesOfBeerInMyF writes "AppleInsider is running an article about Apple's new SproutCore Web application development framework, utilizing Javascript and some nifty HTML 5 to offer a 'Cocoa-inspired' way to create powerful Web applications. Apple built on the OSS SproutIt framework developed for an online e-mail manager called 'Mailroom.' Apple used this framework to build their new Web application suite (replacing .Mac) called MobileMe. Since SproutCore applications rely on JavaScript, it seems Apple had good reason to focus on Squirrelfish for faster JavaScript interpretation in Webkit. Apple hosted a session last Friday at WWDC introducing SproutCore to developers, but obviously NDAs prevent developers from revealing the details of that presentation. Apple has a chance here to keep the Web becoming even more proprietary as Silverlight and Flash battle it out to lock the Web application market into one proprietary format or another. Either way, this is a potential alternative, which should make the OSS crowd happy." TechDIrt's writeup on the browser evolving towards acting as an OS expands on the theme AppleInsider raises.
[+]
Apple: Revamped WebKit JavaScript Engine Doubles In Speed 270 comments
Shin-LaC writes "In a post on their official blog, WebKit developers introduced the 'next generation' of their JavaScript engine, SquirrelFish Extreme, claimed to be twice as fast as its predecessor. The post lists several changes contributing to the performance improvements, including 'bytecode optimization,' a 'polymorphic inline cache' (which sounds similar to V8's 'hidden class transitions'), and a 'context threaded JIT' compiler which generates native code (currently only for x86 processors), and is also applied to regular expressions. The new JavaScript engine is already available in the latest WebKit nightly builds. According to comparative benchmarks, the new engine is around 35% faster than the V8 engine recently introduced in Google Chrome, and 55% faster than Mozilla's TraceMonkey."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
The real question is.... (Score:5, Interesting)
Of course, anything that improves JS performance in browsers (making some of the libraries faster and/or hardware accelerated always helps... hint, hint!) is a win for the consumer. And from that perspective this sounds very interesting.
Re:The real question is.... (Score:5, Informative)
Parent
Re:The real question is.... (Score:5, Interesting)
The iPhone is the one to really benefit from this, because it's where the pauses are currently noticeable.
And IE really, really suffers in comparison. Microsoft has to be wincing about all this, if only for pride's sake... I'd love to see speed improvements to IE 8 beyond the what's known already [ejohn.org], though the DOM speed improvements will help a lot for parity.
Parent
Re:The real question is.... (Score:5, Informative)
Parent
Re:The real question is.... (Score:5, Interesting)
Parent
Re:The real question is.... (Score:5, Insightful)
Parent
Re:The real question is.... (Score:5, Informative)
The fastest dynamic language implementation at the moment is Objective-C. This isn't as fast as it could be in the GCC implementation (I'm working on it in LLVM, and hope to have some nice speedups soon), but it's not far off. This compiles dynamic lookups to fast native code and compiles everything else to static code.
Next up in terms of speed are the various Smalltalks. Something like GNU Smalltalk does well in terms of speed. It JIT compiles things in a way quite similar to Objective-C, but with a very naive compiler with very little optimisation. This is slightly faster than something like Squeak, which compiles to bytecode and interprets this. Bytecode is generally quite fast. Basically, the interpreter is a loop which contains a switch statement. Each instruction is a fixed size with (typically) the first byte being an opcode, and so this is compiled to a static jump table and the 'decode' cost for each instruction is a load and a jump. This is slightly slower than naive compilation, but not much. In some cases it can be faster, because your interpreter is likely to be compiled with a compiler that does quite aggressive optimisation and so you may get fewer register spills than something like GNU Smalltalk (which lacks a peephole optimiser, for example). The new JavaScript interpreter is of this nature - it compiles to bytecode and then interprets this.
Even slower are interpreters which try to run the AST directly. These turn each statement (or part of a statement) into a generic operation and step through these. This is what the old WebKit implementation did.
Part of the problem with this kind of thing is that you are always trading compile time for run time. The benchmarks they published take around 10 seconds to do a complete run. This includes both your compile and run time. If you take more than a second to compile, people will notice. If you take one second to parse, and then execute the AST slowly, you may take 10 seconds in total. If you take one second to parse and four seconds to compile and optimise then you need to get a 500% speedup just to break even - your perceived speed will be the same. This is why things the StrongTalk and Self VMs did dynamic profiling - they began by interpreting everything, but if you spent a lot of time executing a part of the code, it will aggressively optimise it. The newer Java VMs do the same thing.
For most JavaScript, this is a complete waste of time. It is very rare for JavaScript to run for more than a fraction of a second at a time and so latency caused by interrupting execution much worse than just running it slightly more slowly. The ActionScript VM in Flash is very different, since it is designed to run scripts that stay running for minutes at a time and are fairly CPU intensive. If people start using JavaScript and canvas tags or SVG in the same way as they use Flash, then a JS runtime with a JIT compiler and optimiser is likely to be a win.
Parent
Re:The real question is.... (Score:5, Interesting)
I have to disagree with you about Smalltalk. Before it in performance are LISP and on the great benchmark shootout even LuaJIT (!) is faster than VisualWorks smalltalk -- vw is pretty fast for a smalltalk. Smalltalk has been optimized a lot, but it's not really a 'fast' language.
Parent
Re:The real question is.... (Score:4, Informative)
On the other hand, it bears noting that Tamarin isn't going to make it into shipping code until Mozilla 2.0--presumably that will be Firefox 4, but it's still so far off that I believe that determination hasn't even been made yet. Whereas on past experience I would expect SquirrelFish to be in a shipping Safari build much sooner.
Parent
Re:The real question is.... (Score:5, Insightful)
Parent
Re:The real question is.... (Score:5, Insightful)
I recently had the opportunity to work with some code I hadn't touched in over a decade, and port it to a modern hardware platform (same OS). It was amazing, because I could now do the "overnight full build" in 15 minutes. Daemons that used to take 5-10 minutes to compile now took 1 to 2 seconds.
Faster computers change everything. (Just like the availability of cheap screens, and then cheap graphics hardware, moved us from teletypes to CRTs to GUIs.) Continuous integration? Sure, we have cycles to spare. Automated testing? Ditto. Over-modularized components for quicker builds? Don't need 'em. Complex, custom circular buffers? Just log it and parse it later. Need more cache? Have some RAM.
Could I still write code that fits in 2048 bytes and runs at 1MHz? Sure. Can I do a lot more when I don't have to worry about it? Yep. Do we gain more from standing on the shoulders of frameworks and libraries than we lose to hardware costs? Hell yeah.
Parent
squirrelfish? (Score:5, Funny)
Re:squirrelfish? (Score:4, Interesting)
Usually what happens is a development team uses themed codenames to easily distinguish product versions. In this case, they're probably using fish names. I worked somewhere with the same theme. We had all sorts of fish names and eventually they got a bit wacky (aquaman). The problem is when in OSS or other open development models, those names become public instead of a properly chosen name. With OSS, this happens because name recognition builds up as people discuss the unfinished software. We only had this happen once, where Man-O-War was demoed for the defense department and they liked the name so much we had to keep it for PR reasons.
Parent
Re:squirrelfish? (Score:4, Informative)
SeaMonkey [seamonkey-project.org], of course. :)
I made a Mozilla product name generator [skynet.be] a half year back.
Parent
Still Stateless (Score:4, Insightful)
Every time you click a button that triggers a server-side transaction, the page needs to explicitly transmit info - a cookie, GET/POST variables, something - back to the server to "remind" it of its current state.
To me, this would seem to be where most of our time is wasted...
Re:Still Stateless (Score:5, Informative)
The GP is saying that if we had a stateful protocol, we could eliminate most of the overhead and make applications move a lot faster.
Parent
Javascript grows up (Score:5, Informative)
Javascript is doing more than just surviving. Early implementations of Javascript were quite buggy and standards were pretty lax. Things have improved significantly since "Javascript" became ECMAScript. The name may still have "script" in it, but it's a huge misnomer. Javascript is a full-fledged language - a very powerful one with many unique properties, and very useful if you know how to apply design patterns.
I encourage anyone involved in building websites, widgets, or enterprise applications to check out the Javascript lecture series by Douglas Crockford of Yahoo! located at http://video.yahoo.com/video/play?vid=111585 [yahoo.com] to get a real feel for the power of modern Javascript.
And have a look at the modern AJAX frameworks like YUI and JQuery, which are being used to develop some pretty complex applications.
Re:Javascript grows up (Score:5, Interesting)
http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html [blogspot.com]
"Why JavaScript? Well, it was Ajax. See, what happened was... Lemme tell ya how it was supposed to be. JavaScript was going away. It doesn't matter whether you were Sun or Microsoft or anybody, right? JavaScript was going away, and it was gonna get replaced with... heh. Whatever your favorite language was.
I mean, it wasn't actually the same for everybody. It might have been C#, it might have been Java, it might have been some new language, but it was going to be a modern language. A fast language. It was gonna be a scalable language, in the sense of large-scale engineering. Building desktop apps. That's the way it was gonna be.
The way it's really gonna be, is JavaScript is gonna become one of the smokin'-est fast languages out there. And I mean smokin' fast."
Parent
Great name (Score:5, Funny)
Did someone make a rule that every new tech has to have a name that would make me sound like a fucking idiot if I tried to pitch it to my boss?
Re:Great name (Score:5, Funny)
Parent
Still seems slow... (Score:5, Interesting)
Re:plug-and-play javascript engine (Score:5, Interesting)
Parent
Re:iPhone Safari (Score:5, Informative)
Parent
Re:iPhone Safari (Score:5, Informative)
On a mac, it's simple to install and remove the WebKit nightly. It's literally just dragging and dropping a specially built application.
Now, you'll only be using the webkit libraries when browsing with that gold WebKit icon. To prove this to yourself, you can visit the Acid3 test [acidtests.org] page using both Safari and Webkit without quitting either and see very different results. Safari still has major incompatibilities while WebKit seems almost perfect.
Finally, when you are ready to uninstall WebKit, quit the app and drag the gold colored icon from the applications folder to the trash. Or, drag a new version that you download the next day on top to replace the old nightly.
Parent
Re:Konqueror/KDE 4.? (Score:4, Informative)
Parent