Firefox Gets Massive JavaScript Performance Boost 462
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.
As fast as C code??? (Score:5, Interesting)
Re:Precursor to more of Firefox being in JS (Score:3, Interesting)
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.
Dr. Michael Franz (Score:5, Interesting)
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 [uci.edu] looks like the paper the article is referencing.
Performance is great and all (Score:5, Interesting)
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 [wikipedia.org] in disguise.
Re:As fast as C code??? (Score:3, Interesting)
Does that also mean it's NOT as fast as native C/C++ code because C# is blatantly not and thus is part of the marketing guff that you were gulliable to believe?
That said, in general programs written using the .NET framework end up with the same basic overhead as a program written in C/C++. The biggest difference are all the .NET libraries and other managed features of the language. In this way C# would be about the same as C++ using a bunch of dynamically-linked 3rd party libraries and a completely autonomous garbage collection library.
Obviously this is more overhead than a small and simple C program but that wasn't the point. I think it would be interesting if you could provide pre-compiled Javascript files to browsers for execution -- give it the bytecode directly and allow it to skip the compile process. This would make Javascript much more like Java in that regard.
Re:As fast as C code??? (Score:5, Interesting)
For what it's worth tracemonkey is about the same speed as unoptimized C on integer math at this point. The difference is register allocation (which tracemonkey doesn't do yet).
Moving to more complicated examples, things get more interesting. Since the jit has full runtime information, it can do optimizations that a AOT compiler cannot do. At the same time, the lack of a type system does hurt, as you point out. At the moment, tracemonkey handles this by doing type inference and then if it turns out to be wrong (e.g. the type changes) bailing out and falling back on the interpreter. Turns out, types don't change much.
The real issue for a real-world Javascript program is that most of them touch the DOM too, not just execute JS. And right now tracemonkey doesn't speed that up at all. In fact, it can't jit parts of the code that touch the DOM. Eventually the hope is to add that ability.
That's pretty impressive... (Score:5, Interesting)
It would nice to see some demos of this with John Resig's Processing.js [ejohn.org]. 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.
Re:Precursor to more of Firefox being in JS (Score:2, Interesting)
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.
Re:As fast as C code??? (Score:4, Interesting)
Concurrency is another big win for interpreted (and to jit-ted code like Java) code. The compiler on the target machine gets to decide how to optimize the the code based on the number of processors.
Which would be great, if only someone had invented algorithms that could take advantage of that in cases other than trivial parallelisation where the more cores the better. Unfortunately, understanding of how to do that is still in its infancy even in academia, which means that the combination of old fashioned compilation plus moderate run-time adjustments are still likely to blow away anything interpreted for a while to come, and JIT compilation is no big advantage yet either.
Comment removed (Score:3, Interesting)
Re:Performance is great and all (Score:2, Interesting)
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.
Darn right. Virtually everyone one of your complaints is either based on personal taste (classes, strict typing, etc), missing bits of framework (threading, logging), or the inability to differentiate the DOM from JS the language (load order issues, dialog complaints, etc). About the only legitimate complaints I was able to identify are:
* lack of modules
* lack of namespaces
And both of these are well-known issues that were *supposed* to be addressed in JS4 (and hopefully will be addressed in the future).
Spoken like someone who has not programmed in enough languages to understand the GP's points.
For myself, the "Postel's Law" item has been the cause of a lot of grief, tied in a dead heat with the lack of strict typing. Grrrr....
Re:Fast as C but uses lots more memory (Score:5, Interesting)
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 [luajit.org], 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 [debian.org]. It also takes 2-8x less memory and starts up 10x faster than the JVM [debian.org], 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.
Re:Fast as C but uses lots more memory (Score:5, Interesting)
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.
Re:As fast as C code??? (Score:3, Interesting)
Re:Javascript can never run as fast as C (Score:1, Interesting)
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 [280slides.com], 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.
Re:As fast as C code??? (Score:3, Interesting)
Re:The Greatest Idea (Score:5, Interesting)
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.
Java/C#/C++/C equally fast (Score:2, Interesting)
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.
Re:Precursor to more of Firefox being in JS (Score:3, Interesting)
'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.
Re:As fast as C code??? (Score:3, Interesting)
It's true that dynamic typing is a clock-cycle hog, but almost all new languages use it... I'd be perfectly happy with a strongly-typed variant of Javascript if it will run faster.
Re:Fast as C but uses lots more memory (Score:2, Interesting)
Re:The Greatest Idea (Score:4, Interesting)
On the off-topic note: Don't even bother thinking about the task manager, just download the Process Explorer [microsoft.com] 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.
Re:As fast as C code??? (Score:4, Interesting)
you want "memory allocation voodoo" in a lower level language? easy. overload the new operator in C++ and you're done. We did this for a very very fast, very very scalable system ages ago (back when 900mhz CPUs were teh win). You basically pre-allocate a pool of fixed-size blocks (eg 16 bytes, 32 bytes etc) then grab the first free one off the relevant pool when you need an object. And without the overhead of a garbage collector too!
Re:As fast as C code??? (Score:3, Interesting)
Programming functional style (and limiting side effects) makes this task easier.
Programming functional style (and NO side effects) makes this task easier. With multi-threaded apps, its an all-or-nothing approach. Some side-effects will ruin your week in a difficult to reproduce (let alone debug) way.
Even then, I think you'll find its next to impossible to achieve without programmer hints to the compiler, but then you might as well make those hints into thread features of the language and let the programmer write threaded code.
Re:As fast as C code??? (Score:3, Interesting)
Damn. This is going to undo my mods in this discussion.
Unfortunately your argument has a hole in it at this point. I was just about to mod your earlier posts insightful but I thought I'd correct you instead. If you write your JIT compiler in C then it takes the Javascript as input and outputs native code. This glosses over the interactive nature of the JIT compiler but is largely true. The compiler does not execute code in the language that it is written in. It executes code in the language that it is emitting. The language being emitted is the native assembly language. So you do not have a C program that does the same thing as the same speed. You have a C program that generates code, which when run does the same thing. For this reason the output of the JIT can be faster than C, even if the JIT is written in C.
C is inefficient (Score:5, Interesting)
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.
Re:Fast as C but uses lots more memory (Score:1, Interesting)
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'.
Re:As fast as C code??? (Score:3, Interesting)
The overhead of dynamic types is quite immense
That is a common myth but unless you call a factor of 2.0 immense, it it wrong. The truth is that the cost is immense only in the most naive implementations (*cough* ruby *cough). For example, while the compiler has to insert type checks whenever you do something like "+", with a well designed implementation that uses pointer tagging that should cost at most one bitwise-and and one branch-if-zero (with modern CPU pipelines that should cost a fraction of a cycle since the branch should predict fail and in the fail case there is no data dependency). In addition a well designed system will be analyzing the code and eliminate/commonize those checks whenever possible. Finally for really high performance some implementations allow you to run in unsafe mode where those checks are turned off (not applicable to untrusted JavaScript code in a browser but in other applications may be useful).
We could spend all day debating the details of this but in reality it all comes down to the numbers so lets talk numbers. Looking at the programming language shootout [debian.org], I see Python Psyco, Scheme Ikarus, and Lisp SBCL as implementations of dynamically typed languages. Their performance relative to Intel C are 6.2, 5.9 and 2.0.
Bottom line, will dynamically typed languages always be slower than statically typed languages? Yes, but in good implementations it should only be a small (2-6) factor.
(Note, that Ikarus doesn't even do any heavy code analysis or optimization. It's just a good straight implementation of the language. I note this in case some cry foul that SBCL uses programmer supplied type hints and Psyco uses JIT specialization.)
video showcasing the improvements (Score:1, Interesting)
http://people.mozilla.com/~schrep/tm-image-adjustment.swf [mozilla.com]