Slashdot Mirror
Firefox Gets Massive JavaScript Performance Boost
monkeymonkey writes "Mozilla has integrated tracing optimization into SpiderMonkey, the JavaScript interpreter in Firefox. This improvement has boosted JavaScript performance by a factor of 20 to 40 in certain contexts. Ars Technica interviewed Mozilla CTO Brendan Eich (the original creator of JavaScript) and Mozilla's vice president of engineering, Mike Shaver. They say that tracing optimization will 'take JavaScript performance into the next tier' and 'get people thinking about JavaScript as a more general-purpose language.' The eventual goal is to make JavaScript run as fast as C code. Ars reports: 'Mozilla is leveraging an impressive new optimization technique to bring a big performance boost to the Firefox JavaScript engine. ...They aim to improve execution speed so that it is comparable to that of native code. This will redefine the boundaries of client-side performance and enable the development of a whole new generation of more computationally-intensive web applications.' Mozilla has also published a video that demonstrates the performance difference."
An anonymous reader contributes links the blogs of Eich and Shaver, where they have some further benchmarks.
Correct me if I'm wrong, but generally speaking, I was always under the impression that, as an interpreted language, javascript will never be able to run 100% as fast as natively compiled C code.
Its a question of what is "core framework" type stuff, and what is "actual application". Things like UI layout, interaction, networking, security, caching, rendering - as well as executing run time JS - is "core" functionality. I'd wager that >90% of binary code of Fx and, say, Thunderbird is the same.
And most of that core stuff is written in C++. Well, actually, its written in an obscure dialect of C++, developed when Netscape ran on a dozen various platforms, with mutually incomparable cpp compilers.
But that 10% that makes an application engine a web browser, or a mail client.. Most of that is written in Javascript. And most of it is "leaf" code, with not much cross calling, or dependencies that don't go through the underlying engine. Stuff that the just about total lack of "programming in the large" that Javascript has doesn't much matter.
The theories behind tracing optimization were pioneered by Dr. Michael Franz and Dr. Andreas Gal, research scientists at the University of California, Irvine.
Hey that's my old compilers professor and my school!
This PDF looks like the paper the article is referencing.
I've written my share of JS-heavy apps and the boost will be nice for that. However, my complaints with JS don't lie with performance.
I think that's enough. I'm sure you could easily argue back but this is my rant about why this boost is not the saving grace to JavaScript.
Basically my point is that performance does not bring JS up another tier. It just prolongs the pain of having a grossly inadequate language for rich application development. JS does have some nice things about it (first-class functions, closures, for(..in..), etc.) but in no way would I consider it "good" for application development.
Step back and realize the movement is pushing applications into the browser. Yes, the same apps that currently use threading; the same apps that have more than 4 input widgets (input, select, radio, checkbox); the same apps that run slow even when written in native code; the same apps that depends on libraries of code; etc. JavaScript, as is, is not The Answer and this performance boost is just a Bluepill in disguise.
:wq
It would nice to see some demos of this with John Resig's Processing.js. It could definitely use the kind performance boost being discussed here.
In addition to a performance considerations, it would also be nice to have addtional some additional bit depth in JavaScript.
I anticipate JavaScript will continue to be very popular, but there are alot a lot of reasons other than performance that people won't want to use the language for writing desktop applications over C/C++/Java. That said, there have been alot of recent developments that have made me cautiously optimistic about the future of the language along these lines.
Afterall, Firefox developers probably aren't the most 1337 C/C++ coders out there, but they are probably amongst the best JavaScript ones.
Whoa! Not so fast!
The Javascript interpreter in Firefox is written in C, and related stuff (XPConnect, etc.) is written in C++. You should go read it some time; this stuff was definitely NOT written by mere mortals.
You can browse the source at the Mozilla Developer Center; no link, so only the truly interested will go there. Look in mozilla/js/src.
"The empty vessel makes the greatest sound." -- William Shakespeare; Henry V, 4. 4
Because then their damned Lexmark printers don't work and I go out of business? Until linux can run Windows games with a "clicky clicky,next next next" installer,and I can install those damned Lexmark all-in-ones that everyone seems to have there is just no way i can survive selling Linux boxes. i tried and ended up having to reformat them and put Windows because folks didn't want them. You can talk about how much safer Linux is to a customer all day long,but if it doesn't work with their hardware and they can't easily install and play their games,it is no sale.
And as for flamebait? Has nobody seen the massive amounts of JavaScript exploits hitting the net lately? If this was an article touting an increased speed for ActiveX would we all be cheering? JavaScript is the script kiddies tool of choice ATM,and it is just getting worse. Don't believe me? Just go here or here and look for yourself. Or type "JavaScript Exploit Firefox" into Google and see how many hits you get. I counted over 702,000! We need to be increasing the security of JavaScript,not the speed. Who cares how fast it'll render if you are afraid to allow your users to have it on for fear of being hacked? But as always this is my 02c,YMMV
ACs don't waste your time replying, your posts are never seen by me.
The catch is that you pay two penalties: startup time and memory. Lots of memory: for keeping stats on what needs compiling, trampolines to call in and out of the interpreter vs. JIT native code, and the native code *plus* the byte code.
That JITs automatically incur large memory footprint or startup time penalties is the logical conclusion you come to if you look at the JVM. But the truth is that JITs don't have to suck as much as the JVM does.
For example, take LuaJIT, a JIT for the already-speedy dynamic language Lua. It speeds up Lua roughly 2-5x while starting up in less than 0.01 CPU-seconds and introducing less than 20% memory overhead. It also takes 2-8x less memory and starts up 10x faster than the JVM, despite the fact that Lua is compiling from source, whereas the JVM starts with bytecode.
I've never looked at the source for the JVM, so I can't say just why it takes so many resources, but I can only conclude that it's because Sun just doesn't consider startup time or memory footprint a priority.
So, really the memory access will be a bottle neck, you can never hope to have your program in cache and it will be much slower than C.
That's not always a given. If we go by the old rule of thumb that 80% of the time is spent in 20% of the code, we could stick that 20% in one place to maximize cache usage. You can even optimize so that if branches that are taken are kept in the cache, and infrequently executed branches are moved out of the way, maybe in a separate page so they can be swapped to disk.
You can do this to a certain degree at compile time, but often you don't know in advance what paths are going to be hot (it might be based on the data) and it may even change as the program runs.
In practice, if someone tells you that Java is faster that C, they're speaking mostly in hypotheticals. Java and another high-level languages encourage so many layers of abstraction that the sheer amount of code that needs to run will probably make it slower than your typical C program. There's also a lot of things, particularly anything that needs to be dynamic, that you can't easily/efficiently compile.
What's interesting is LLVM and .NET, where you can run C/C++ code in an interpreted/JIT-compiled environment. Potentially, with the optimizations mentioned above, you could have C code running in a virtual machine that's faster than statically-compiled C code.
It's true that for applications where a Javascript function takes a long time to execute, that translation overhead can be neglected, yielding comparable speed with C, however such functions are rare enough in ordinary web applications that the point is moot.
They're becoming increasingly less rare as people write more complex applications for the web. There are Javascript libraries that do complex layouts not possible in CSS/HTML which dynamically resize when you drag and drop items around. Someone a Keynote workalike, which chugs badly on slower machines -- while you could probably blame a lot of it on DOM, the Javascript and the Objective-C-like abstraction layer and windowing library probably doesn't help.
So it might be that it "only" takes 400 ms to update the layout after you drag a slider to resize a divider, but it'd be great if it only took 100 ms, especially on old hardware. If you only compile code that actually gets executed, the translation overhead might be less than you think. In particular, the method mentioned in the article uses a less expensive type of JIT than traditional JIT compilers.
Sharepoint 2007 is a good example. Editing of the content is via a browser-based interface, which is quite script heavy. What's interesting is just how script heavy it is. While testing on an old laptop we have connected to an external link, I was a bit dismayed at how slow loading our site was. I got the impression that the browser was pausing before displaying the page for some reason.
Opening up task manager, I saw that before IE displayed the page, it would spin on 50% CPU (on an old hyperthreaded P4) for over 5 seconds before finally rendering the page. After some experimenting which yielded consistent results, I tried Firefox and the difference was dramatic, to say the least.
The upshot of all this is that we may need to recommend to our clients that they use Firefox to edit their Sharepoint 2007 sites, because it provides a significantly better experience than IE does if you have older hardware. On my own desktop at work (a reasonably modern Core 2 Duo) IE does spike the CPU usage, but generally it's for less than a second or two so it's not really distracting. Firefox is faster, but both are quick enough that it doesn't make a real difference to a human.
Completely off-topic: I used refreshes of the task manager process listing to judge how long IE was spinning for. I always assumed the default setting was to refresh the list once per second, and some quick testing now confirms that that is what it does. If you go to View -> Update Speed, the default setting is "Normal". The status tip for this setting says "Updates the display every two seconds". Clearly a lie - or is it? If you select "Normal", then the display does in fact update every two seconds, and there doesn't seem to be any way to get it to go back to refreshing once per second.
About the memory, you are correct (for now).
About the speed:
I made a benchmark written in a pure C subset of C/C++/C#/Java in all of these languages. A simple benchmark involving calculations with integers (primes) and floating point numbers (sums of products of square roots of primes). The result, when running a bazillion iterations:
C# and Java took 50 seconds, C++ took 49 seconds and C took 51 seconds. Other benchmarks I made showed similar results.
So for pure calculating, C#/Java + JIT is equally fast. For big real-life systems involving a lot of other stuff, the results might be different.
But it is a long time ago that Java et. al. were 3 times slower than native code.
'actually, its written in an obscure dialect of C++, developed when Netscape ran on a dozen various platforms'
Really? I was under the impression that the core of Firefox 1.0 was a complete rewrite because the developers determined that the old Netscape stuff was a mess that wasn't worth moving forward with.
Makes sense, by compiling for a specific architecture you can get a %5-%10 performance increase. If the JIT compiler uses less than the %5-%10 and can optimise for the arch then its a saving. Of course it won't be a saving over compiling the code specifically for the architecture in the first place, but it is rare to see that (Gentoo'ers and other build from source distros). And multi-core processors are going to further reduce the speed since you can just offload the JIT to one of the other cores (of several if its threaded) and since few programs are very well threaded it shouldn't be a problem (and the kinds of things that are well threaded generally are longer number crunching tasks so the initial compile will be a small amount of the overall speed). In addition to that you might find other cool things like the ability to thread non-threaded code in some instances. For instance there is no reason for a basic function that's return value isn't used for a fairly long time not to be threaded, you can sort a list while you continue pass it on through the rest of the program as long as you don't actually need to read the content to decide where to send it or try and do something to it. As for memory, ram is cheap enough now that it shouldn't be a problem, 4GB will be fairly standard soon. Ubuntu already burns around 500Mb for me doing nothing.
cat
On the off-topic note: Don't even bother thinking about the task manager, just download the Process Explorer and set it to replace the task manager. It's light weight and vastly superior to the task manager in every way. One of the utils I miss in Linux.
Switch back to Slashdot's D1 system.
You are ABSOLUTELY wrong! C# by its very nature can not be as fast as C.
The C# JIT has all the information that a C compiler has (essentially, the entire source code). In addition, it has a lot of global program information and it has runtime statistics. And, the C# language has better defined semantics. All of this taken together means that C# can be optimized better than C.
In terms of performance, C is a lousy language; Fortran is a "faster language" than C.
The only reason C even runs as well as it does is because people have invested 20 years in making compilers squeeze out the last cycle, because C compilers play fast and loose with C semantics at high optimization, and because even CPUs have been tuned to accommodate its semantics.
At a previous job, we experimented with the profile guided optimizations provided by Microsoft's Visual C++ compiler. The results were *AMAZING*.
As part of our release build process, we had a program that included a few traces of our common usage scenarios through our core computation bottleneck path. We got anywhere from 0% to 20% performance improvement.
*This* is the theoretical JIT advantage. Profile guided optimization. It is available statically today. Having JITs match this will be very difficult, but in a way it seems like the HDD vs. SSD debate. Disks are always getting better, but it seems like SSDs will take over at the end of the day. A matter of 'when', not 'if'.
http://people.mozilla.com/~schrep/tm-image-adjustment.swf