Next-Gen JavaScript Interpreter Speeds Up WebKit 193
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.
iPhone Safari (Score:3, Insightful)
How about low-end PCs? (Score:3, Informative)
One can only hope that we could squeeze some more JS pe
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
On a 2 GHz MacBook Core Duo with OS X 10.5.3 (Webkit 5525.18 4/20/08 shows in profiler)
Firefox 2.0.0.14 15205.0ms +/- 1.3% -- score about 4 runs per minute
Safari 3.1.1 (5525.20) 4149.6ms +/- 0.5% -- score about 15 runs
iCab 4.0.1 4142.2ms +/- 0.4% -- score about 15 runs
Essentially identical results suggest that iCab 4 is also using Webkit.
It looks like my tes
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.
Re: (Score:2, Interesting)
Wouldn't the effect of such compliance threaten the fabric of the space-time continuum or something?
Re: (Score:2)
The second rule of MS Club is - you DO NOT talk about Linux Club.
Third rule of MS Club, someone yells Downturn!, goes bankrupt, drops out, the profit is over.
Fourth rule, only two developers get a look at Shared Source.
Fifth rule, one
Sixth rule, no cash, no C#.
Seventh rule, marketing lunches will go on as long as they have to.
And the eighth and final rule, if this is your first night at MS Club, you have to VB
Re:iPhone Safari (Score:5, Informative)
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)
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.
Re:The real question is.... (Score:5, Informative)
Re:The real question is.... (Score:5, Interesting)
Re:The real question is.... (Score:5, Insightful)
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.
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.
Re:The real question is.... (Score:4, Interesting)
Compare something like TCC to GCC. TCC can compile and run a short program in two seconds, although it does hardly any optimisation. GCC will still be in the middle of running optimisations by the time TCC has finished running the program. On the other hand, compare a server-side component of a web app. GCC may take a few minutes to compile it while TCC would take a few seconds, but the version compiled with GCC will be able to service twice as many clients on the same hardware. Something like Google Spreadsheet, or browser-based games, are the same. They use enough CPU power that adding a little compiler overhead for better code is a net gain. Things like dynamic menus and the Slashdot background comment loader aren't - they run fast enough on a crappy JS implementation, and on a faster one they are speed-limited by the network, not the CPU. For these, a fast bytecode interpreter will always be (or, at least, seem) faster than an aggressive JIT, because the time they spend executing is so small.
Re: (Score:3, Interesting)
I try not to be a Java apologist on Slashdot, but the latest JDK6 (especially in -server mode) and public builds of JDK7 are awfully fast. Considering Objective-C's dynamic lookup overhead and lack of inlining opportunities, is it really much faster? Especially when you're running it on a chip architecture other than the one it was compiled for, such as moving between some of the Atom, Core, AMD, and virtual machines. (Although I suspect the LLVM stuff will bring Objective-C up to Java p
Yes, interpreters are usually bad (Score:2, Interesting)
I don't know anything about Javascript interpreters in particular, but as a general rule, interpreters for any sort of "scripting" or "dynamic" languages tend to be pretty simplistic and weak. There are a lot of techniques for making language implement
Re: (Score:2, Insightful)
A. A site compatibility problem.
B. A FF plugin that I cannot live without.
In a perfect world, alternative Linux browsers would provide support for FF plugins, but the
Re: (Score:2)
At least that Jamie Zawinski ( http://en.wikipedia.org/wiki/Jamie_Zawinski [wikipedia.org] ), heavily involved in Netscape/Mozilla during early years, seems to agree...
http://jwz.livejournal.com/132696.html [livejournal.com]
http://jwz.livejournal.com/138051.html [livejournal.com]
PS. (Score:2)
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.
Re: (Score:2, Insightful)
Re: (Score:3, Insightful)
What if you didn't have to wait for faster hardware? What if everything ran much faster on what you have now - TODAY? Why should should we have to continue to spend thousands of our hard earned currency units because developers are frickin' lazy? And what about mobile devices such as PDAs and mobile phones?
Go back to Digg or wherever you crawled out from.
Re: (Score:3, Insightful)
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.
Re: (Score:3, Insightful)
It's because computers are cheaper than developers.
Last time I checked, compilers were cheaper than computers. I know compiler writers are developers (I am one), but time spent optimising a compiler has a much greater benefit than time spent optimising a single program, since the speedup applies to all code compiled with it. How much energy is taken per year, do you think, executing JavaScript in web pages? How much would be saved if the implementations were twice as efficient?
Re: (Score:2)
Clearly that's all you know, because this "throw more hardware at the problem" is a central tenet of the Unix philosophy, and furthermore - it's a fundamentally good idea. The fastest way to improve the speed of your program is to do exactly nothing. It's also BY FAR the most cost-effective option.
See here [faqs.org] for ESR's opinion in his book "The Ar
Re:The real question is.... (Score:5, Insightful)
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.
Re:squirrelfish? (Score:4, Informative)
SeaMonkey [seamonkey-project.org], of course. :)
I made a Mozilla product name generator [skynet.be] a half year back.
FireSomething (Score:2)
(Haven't checked if there's some incompatibility, or if a simple change in the maximum version does the trick)
Re: (Score:2)
Re: (Score:2)
Yeah, I looked at your source.
Re: (Score:2)
Re: (Score:2, Informative)
But incidentally, the squirrelfish is an actual fish (just like it turned out that the firefox was also an existing animal).
Re: (Score:2)
Re: (Score:3, Funny)
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
Re: (Score:2, Insightful)
This still isn't going to fix the fact that (X)HTML pages are transported and managed by what is still fundamentally a stateless protocol
I guess I don't understand. Wouldn't having a better browser-side language make stateful applications more likely? I mean, you dismiss AJAX, but wouldn't faster Javascript make AJAX much better? There are already many "applications" that run on the web that are very similar to their desktop counterparts - better performance will make these more common, I would think.
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.
Re: (Score:2, Insightful)
Re: (Score:2)
HTTP is perfectly fine the way it is. Seamless stateful interaction is a problem for server-side languages/frameworks to handle. Don't blame HTTP for a framework deficiency. There are frameworks that don't have this problem [sourceforge.net].
Re: (Score:2)
The gains made in responsiveness and security would be huge, not to mention the fact that the server could push data without the client asking for it first.
Re: (Score:2, Informative)
How do you think TCP works atop the "stateless" IP?
The whole stateless/stateful thing is extremely dated, and not even logically correct. HTTP w/cookies is stateful, and has been for a long time [yafla.com].
Re: (Score:3, Insightful)
As always, it depends. I can think of two cases offhand in which bandwidth was cheaper than JavaScript/DOM. Using JavaScript to zebra stripe a large table basically hanged the browser for five seconds, so we added a class to every other row and used CSS. Adding and deleting rows to a large table was extremely slow, so we rendered all of the extra rows hidden by default, then unhid them as necessary. (Not a general solution, but it wo
Re:Still Stateless (Score:4, Insightful)
The real excessive state transfer is the repeated sending of large quantities of (X)HTML from server to client. AJAX helps with that.
Re: (Score:2)
Re: (Score:2)
Most network provider SLAs guarantee a round-trip time of around 50 ms or less between any two backbone routers in the US. Add consumer connection latencies (which tend to suck), non-backbone routers, HTTP connection latencies, process spawning times, and all that, and we can expect to see a delay of maybe 50-75 ms from the moment the first bit leaves the client machine and the moment it can be processed by the server.
Once the f
plug-and-play javascript engine (Score:2, Interesting)
Re:plug-and-play javascript engine (Score:5, Interesting)
Re:plug-and-play javascript engine (Score:4, Informative)
Re: (Score:2)
Konqueror/KDE 4.? (Score:2)
I've been running KDE 4.1 through debian experimental. Buggy right now, but no show-stoppers. KDE and the new Konqueror are surprisingly fast.
Re:Konqueror/KDE 4.? (Score:4, Informative)
Re: (Score:2)
Real question: (Score:2)
And is it possible that Tamarin (Mozilla's version of this) and this will merge, creating some ridiculous new super-fast JS magic engine, interpreting code yet to be written?
Re: (Score:3, Informative)
why would the WebKit team be interested in merging code from a slower implementation?
Re: (Score:2)
Re: (Score:2)
Re:Real question: (Score:4, Interesting)
no, konqueror is using KHTML and will use it in the foreseeable future. There is a google summer of code to work on the webkit kpart [google.com] so that konqueror will be able to use webkit by the end of the summer, but it will probably wont be mainstream for a while:
A while ago, konqueror developers posted a FAQ [froglogic.com] describing the future of KHTML. As of today, it still applies
A posibility is that, a new browser may be added to kde, that will be tunned for web browsing as opposed to konqueror which is a swiss army knife. Kind of what Dolphin did for file management. There is already a webkit based browser [google.com] in the works that could achieve this in the future.
Re: (Score:2)
And I think Tamarin uses a fundamentally different approach, so I don't see a merger here. But friendly competition is always good.
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: (Score:3, Interesting)
I think early gripes were due to the fact that practically nobody was using JavaScript in a productive way. No, we don't want bouncing images, no, we don't want insane drop-down menus that don't behave right, and no, we don't want the web page to break back/forward buttons by doing some underhanded sly scripting work. Or worse! We don't want no stupid popups that ask me for my name.
I think JavaScript has proven now that it has *some* redeeming qualities and legitimate uses :)
Re: (Score:2)
The problems only come when you have to make it compatible with multiple browsers. If you just target one, it's a dream to use.
Re:Javascript grows up (Score:4, Informative)
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."
[OT] Design Patterns (Score:2)
If we're talking about *Javascript* design patterns -- common useful Javascript idioms -- then I think this is a useful statement. If we're talking about common idioms that have filtered out from C++ and Java known as "design patterns" as applied to languages that don't need to many of them, then I'd say Javascript is pretty useful even if you don't know much about them. Possibly more useful.
http://www.nofluffjuststuff.com/show_session_view.jsp?presentat [nofluffjuststuff.com]
jython (take two) (Score:2)
Re: (Score:3, Informative)
That being said, if the Squirrelfish VM and interpreter strategy are applicable to other languages besides JavaScript, some sort of "JSPython" strategy for putting lightweight (i.e., not requiring the JVM as Jython does) client-side Python scripts on web pages would be pretty cool. There doesn't seem to be any suggestion of that so far; presumably (and quite sensibly) the Squirrelfish folks are concentrating on getting eve
Re: (Score:2)
Re: (Score:2, Offtopic)
There's also a demo around somewhere of someone using PyPy [codespeak.net] to compile the Bubble Bobble game to Javascript from Python.
I'm surprised... (Score:2)
I won't even get into the fact that they weren't doing almost-free
Squirrelfish bytecode... use in Parrotcode? (Score:3, Interesting)
Webkit under linux? (Score:2)
I wanna give it a try, I've more and more begun to not enjoy running firefox under my older hardware.
Re: (Score:2)
Re: (Score:2)
There are prerelease versions of Konqueror and Epiphany. The trick is getting them to consistently install. I've had as many failures installing the pre-release version of Konqueror as successes.
JIT and store? (Score:2)
The next step after that is of course to JIT the bytecode, meaning compile it to the native architecture and eliminate all unnecessary calls. Even without further optimization or register allocation, such JIT-ed code would run MUCH MUCH faster. Unfortu
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)
Re: (Score:3, Funny)
You obviously haven't had to explain to a CEO why the company runs on Eunuchs. Kids these days have it far too easy.
Acid3 Slashdotted? (Score:2)
Re: (Score:2)
Re: (Score:2)
It get 100, but certainly not under 33ms, and there's no custom favicon. So I guess there's still some work to be done...
Re: (Score:2)
Ian Hickson says: [hixie.ch]
Firefox 3rc1 displays a red cat favicon when viewing the Acid3 test page, but no favicon when viewing the reference rendering. A quick inspection of the source of the reference rendering shows that the lack of
Re: (Score:2)
no mention of konqueror then (Score:4, Interesting)
It's bad enough that web developers ignore my minority browser (rather than defaulting it to the same template as safari), but ignoring the history of webkit completely must be hugely insulting to the authors of khtml. Give them some credit.
Re: (Score:2, Interesting)
Re: (Score:2)
Rhino (Score:2)
But the real question is... (Score:2)
Still seems slow... (Score:5, Interesting)
Re: (Score:3, Informative)
Re: (Score:2)