Slashdot Log In
Firefox Gets Massive JavaScript Performance Boost
Posted by
Soulskill
on Fri Aug 22, 2008 09:00 PM
from the firefox-has-a-caffeine-buzz dept.
from the firefox-has-a-caffeine-buzz dept.
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.
Related Stories
Submission: Firefox gets massive JavaScript performance boost by Anonymous Coward
[+]
Development, Privacy, and Standards for Chrome 114 comments
Continuing our coverage of Google Chrome, snydeq points out an Infoworld story about looking at the new browser from a developer's perspective, and another about how WebKit should be the focus of development efforts, rather than the browsers that use it. TGdaily notes that Chrome's search box will fetch all types of data, and can be made to display banking information with little effort. ABC and coderrr have slightly more paranoid articles questioning Google's commitment to privacy. NetworkWorld suggests that Chrome's unique process model (explained here) will require the development of new measurement standards.
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.
As fast as C code??? (Score:5, Interesting)
Re:As fast as C code??? (Score:5, Informative)
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.
Well, it has a JIT compiler, so that would transform it into bytecode essentially. It's the reason why C# is as fast as C code, because it too has a JIT. Google JIT :)
Parent
Re:As fast as C code??? (Score:5, Insightful)
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?
Next you'll be telling me Java hasn't got obscene memory requirements in comparison to native C/C++...
Parent
Fast as C but uses lots more memory (Score:5, Informative)
In general, JIT systems can really provide CPU performance near C speed, or even faster for some benchmarks, once the application gets going. 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.
Even dynamic languages like Python can have a JIT - it specializes a function for various combinations of argument types, and then provides a catchall generic version for general objects. The catchall version is not much faster than the interpreter, usually (in fact it could *be* the interpreter), but the specialized versions can be much, much faster. (Also blocks can be specialized within any of the function versions.) But all those specialized versions take up memory. So the JIT keeps stats and tries to make only the ones that really help.
Parent
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.
Parent
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.
Parent
Re:Fast as C but uses lots more memory (Score:5, Informative)
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.
HP did a lot of research on this about 4-5 years ago where they proved this was exactly the case. Do some googling for HP's Dynamo project. Real runtime knowledge of exactly what is being used and when leads to better optimistaion than static optimisation.
Parent
Re:Fast as C but uses lots more memory (Score:4, Informative)
"It wouldn't be JIT then, it'd have to be 'before the code is executed', because you wouldn't want the compiler to spring into action, run on core 2 whilst core 1 twiddles its thumbs waiting for the compilation to finish."
For example, in Java HotSpot it _already_ works this way. A special thread compiles the code while other thread(s) work in interpreted mode. When compilation is finished, other thread(s) switch to this new fast compiled code.
Also, there are optimizations in Java HotSpot which are _impossible_ to do using static analysis.
Parent
Re:Fast as C but uses lots more memory (Score:5, Informative)
So far JIT's just aren't as fast as C. They are very far along. People are using them for programs which may run for days at a time. This has more to do with having an easier time developing in a higher level language. In my experience java rivals and often surpasses C++ programs heavily reliant on the stl. Where I work, speed or features win marketshare and programs written in C are performance kings. Python and java are becoming more popular.
Parent
Re:Fast as C but uses lots more memory (Score:5, Informative)
What a bunch of stupidity...
First, "programs reliant on STL" can be as fast as anything on plain C. And very often they can be faster (for example, because dwarf-style exception handling is faster than return result checks).
Second, JITs are NOT "very far along". HotSpot is _already_ faster than C/C++ on some benchmarks. And it's only going to get better, because HotSpot can use real runtime statistics to guide optimizations (C/C++ can also use Profile Guided Optimizations but it relies on static data).
Parent
Re:Fast as C but uses lots more memory (Score:5, Informative)
but never compared to C.
Here [idiom.com] is a somewhat old comparison of Java and C/C++ performance, done by the University of Southern California. Note that the article was written in 2003 and updated in 2004. Javas performance has improved significantly since then, most noticeably in JDK 1.6. This is the conclusion:
Java is now nearly equal to (or faster than) C++ on low-level and numeric benchmarks.
Parent
Re:Fast as C but uses lots more memory (Score:4, Insightful)
http://psyco.sourceforge.net/ [sourceforge.net]
The really neat thing about it is that you can just load the module and call some functions, and it'll start JIT compiling your Python code for some moderate speedups (particularly string and number crunching). It doesn't need a special version of CPython or anything.
The original author is no longer developing it though -- he's working on PyPy [codespeak.net], the Python interpreter/JIT written in Python. I think they're up to about half the speed of CPython, which is pretty impressive considering how slow Python is.
Parent
Re:As fast as C code??? (Score:5, Insightful)
Yes. Javascript will, just like C# or Java, be as fast as C/C++ in theory, and just like C# or Java, slower in practice.
On the bright side... Javascript will be as fast as C# or Java, which is certainly good enough for a lot of things.
Parent
Re:Java/C#/C++/C equally fast (Score:5, Insightful)
Parent
Re:As fast as C code??? (Score:5, Insightful)
You are ABSOLUTELY wrong! C# by its very nature can not be as fast as C. There is no example you can provide where the running time of an optimized C version will be as fast or slower than the most optimized C# version. Even with JIT and supposed optimal native code generation for tight-loops there is no way you can get the same performance.
You are obviously just regurgitating MS marketing without thinking critically.
Parent
Re:As fast as C code??? (Score:4, Insightful)
C# by its very nature can not be as fast as C
C#, once JIT'ed, is just a bunch of binary. C, when compiled, is also a bunch of binary. Given a theoretically perfect JIT compiler vs the theoretically perfect static compiler, they'll both output exactly the same code.
You are obviously just regurgitating anti-MS propoganda without thinking critically :P
(Note: I'm not saying that C# implementations are *currently* as fast as C ones, just that there's nothing to stop them becoming so in the future)
Parent
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.
Parent
Re:As fast as C code??? (Score:5, Informative)
Except that C# code isn't as fast as C code [debian.org]. It's 2.7 times slower.
Parent
Re:As fast as C code??? (Score:4, Informative)
1) That's the Mono implementation of C#
2) Intel's C++ compiler is known to be one of the best but cannot handle all situations. GCC's takes 1.3 times longer. Java 'only' takes 1.96 times longer.
2a) Intel's C++ compiler got 3 errors in the benchmarks you linked to, thus it should have been disqualified. The Intel C got 1 error and a "no program", so again, disqualified. The first compiler to run all the tests was in fact the Gnu C++ compiler.
Ruby at 63x longer (or 30x slower than Java) should shut up all the Java haters who witter on about Ruby (or PHP at 12 slower than Java) for web development.
Parent
Re:As fast as C code??? (Score:5, Informative)
The optimization in the story is to compile parts of code written in Javascript. So when using this optimization, the Javascript is only partly interpreted, and if the compiled part is the part that takes up most of the runtime, then the Javascript could conceivably be something like the speed of natively compiled C.
Parent
Re:As fast as C code??? (Score:5, Insightful)
It's kind of a non-sensical concept because Javascript as a language is capable of things C can't do, like eval new code at run time, modify existing types etc.
By the time you have a fair comparison (ie. written C code that can really do everything Javascript can), you have basically written Javascript itself in C. So all these comparisons are really just based on getting subsets of Javascript where it is really doing no more than plain C can do to run as fast as similar plain C, and guess what, that is done more or less by compiling said Javascript to native code.
I find it amusing that all these higher level languages (everything from Java, to Javascript to Python or VB) continuously promote how they are "nearly as fast as plain C now" but then a release or two rolls by and voila they suddenly announce they have improved performance by 10x or some similar metric. But when you ask the question, "oh, so are you 10x as fast as C now?", the reply will be "oh, no, but we're nearly as fast as C!"
Parent
Re:As fast as C code??? (Score:5, Insightful)
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.
So, _eventually_ C may be slower than JS/Python/Java. :)
And of course, as other pointed out the article says that JS is now getting compiled.
Parent
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.
Parent
Re:As fast as C code??? (Score:5, Informative)
Clue phone guys. Ring. Ring.
C is a high level language and like all high level languages it can either be compiled, interpreted, or even translated. JavaScript is no different than C and can also also be compiled, interpreted, or even translated. There is nothing special about the C language that makes it inherently faster than other languages. C itself is a derivation of the language BCPL, whos shortcomming was a lack of datatypes. The design goal of these language syntaxes was parsing with minimal overhead because RAM was in short supply in those days. C was not designed to be "faster" than anything.
C is commonly mistaken to be superior because the most popular C compilers are commonly more advanced than the compilers of other languages due to simple supply and demand metrics. C is more popular, so its compilers have traditionally gotten more development effort. C itself isnt special beyond its popularity.
Parent
Re:As fast as C code??? (Score:5, Informative)
Parent
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!
Parent
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.
Parent
Re:As fast as C code??? (Score:4, Informative)
Java ByteCode is NOT equal to C in speed in the real world. C# applications are NOT equal to C in speed in the real world. For that matter, C++ isn't even equal to C speed in the real world (although the margin is very slim if both are optimized correctly and C++ will work most anywhere that asm shouldn't be used IMHO).
That said, speed is not normally the most critical thing in an application. All of the above mentioned languages have strengths of their own and perform well when used properly.
Parent
Re:As fast as C code??? (Score:4, Informative)
Another loss is the lack of link time optimizations. Two identical static functions can not be identified and merged.
Sure they can. The JVM can calculate a hash of each method's code as it loads classes, then change constant pool entries to point to the canonical version of the merged method.
Nor can the functions be reordered to avoid page switching.
Sure they can. The code is just data and the JVM already does heap compacting.
Nor can virtual address mapping be done ahead of time (like SGI's requickstart and Linux' simpler prelink).
Why would you want to do that? As I understand, the more choices you can defer until you have "boots on the ground", the better.
Parent
Precursor to more of Firefox being in JS (Score:5, Insightful)
Re:Precursor to more of Firefox being in JS (Score:5, Insightful)
Javascript, especially when tied to a full featured framework such as ExtJS, is actually freagin cool. Add some IDE support, like in Visual Studio 2008, or in Aptana, and you've got one rock solid, multi purpose dynamic language that is already mainstream and well supported.
Not as cool as Groovy, and I'm a static typing fan myself, but thats the next best thing.
Parent
Re:Precursor to more of Firefox being in JS (Score:5, Funny)
Gecko *is* a full-featured framework.
ExtJS is for the more restricted web stuff without code signing.
But then, the parent probably doesn't even know what a prototype is or a closure.
Reading your first two sentences, I found your post informative and worthwhile. But, with the last sentence, the voice reading your comment in my head suddenly turned into that whiny, high-pitched geek voice they use on cartoons.
Parent
Re: (Score:3, Insightful)
Re: (Score:3, Informative)
Premature optimization.... (Score:3, Insightful)
Now if we can just stop all the xss. Now it's just xss 20-40 times faster (in certain contexts).
Actually, if JS gets fast enough, it could rival Flash [slashdot.org]. This is a good thing.
Re:Premature optimization.... (Score:5, Funny)
Considering how long Javascript has been out, and that javascript intensive applications are clearly there in the present, I don't think this is premature =P Its late!
Parent
Re:Premature optimization.... (Score:5, Informative)
intensive purposes
"Intents and purposes." Somewhere, an English teacher cries.
Parent
Re:Premature optimization.... (Score:4, Informative)
Like stupid simple multimedia.
like SVG, <canvas> <audio> and <video>
Parent
Not bad (Score:5, Insightful)
Firefox 3 already gave quite a nice performance boost to Javascript, enough to actually impress me (google maps is a great demonstration of this). It's good to see they haven't stopped there and are busy improving it further, a lot of software developers tend to spend too much time on making new features and not enough time fixing/optimising the existing one, but I think after the backlash from FF2's memory usage, Mozilla has rethought their priorities and I'm glad to say they're doing things right.
Oh no! (Score:4, Funny)
What does the scouter say about its power level?!
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.
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:The Greatest Idea (Score:5, Funny)
Expect this discussion to be full of astroturf, red herrings and trolls
Ah, no problem. Just give the red herring to the troll and he'll let you pass the bridge :)
Parent
Re:The Greatest Idea (Score:5, Funny)
I am rubber, you are glue.
Parent
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.
Parent
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.
Parent
Re:Start selling printers (Score:5, Insightful)
Does the DS have Age of Empires? FEAR? The simple fact is if I tried that the shop down the street would get the business and I am out on the street. You can't force your customers to take what they don't want. Rule One of Business: The customer is always right. I had four Linux boxes in the shop and had to reformat them because they were just gathering dust. The home user wants to be able to take the software he/she buys at Wal Mart and go "clicky clicky,next next next" and have it work,PERIOD. if it doesn't the machine is "broken" and it gets returned. And NOBODY wants to be handed a DS when they ask about games. Do you HONESTLY think if I did that to my customers they wouldn't just walk out?
This kind of attitude is EXACTLY why Linux has been stuck in the hobbyist section for so long. Instead of an honest discussion about what customers wants and needs you get told "Buy a PS3" or "stick with Winblowz". Guys like me would love to be able to sell easy to maintain Linux units,but the simple fact is we don't want to starve. My customers DON'T WANT a PS3,they want to pick up a game at Wal Mart and have it work. They DON'T WANT a $200 HP added to the price of the unit,they want to take their Lexmark all-in-one that they are quite happy with and have it work. If I was to adopt that elitist attitude my shop would be out of business in less than three months,instead of being busier than ever. Because I ask what they are going to do with their new PC and design it around their needs. Here is what I have found would be needed for Linux to take off in the home/small business sectors based on my customers:
1. VB6 support out of the box. Every single SMB I've ever done business with have one or more VB apps that are essential to the companies survival. No VB,no sale. 2. Windows software and games should be installable from the CD,especially games. If they pick up something at Wal Mart it had better work when they put in the disk. No easy way to install games? No sale. 3. An NDISWrapper for printers,especially those damned Lexmark all-in-ones. They are popular for a reason. They are cheap and give the folks what they want,an easy to use all-in-one printer/scanner/fax. No Lexmark support? No sale.
Without these 3 things I just can't give a Linux machine away. Folks simply don't want them. I have been able to sell the EEE because folks look at them as a "toy" that they don't expect to do the things a "real" computer can. But with a desktop they have expectations: they expect the software they buy to run,they expect the programs that their business depends on to work,and they expect their hardware like printers to just connect and go. Without that,they just sit there gathering dust. But as always this is my 02c,YMMV
Parent
No (Score:5, Insightful)
And stay off the chans.
Parent
Re:Server-Side is still the way to go if you can (Score:4, Insightful)
Doing anything that can be done server-side on the client side is generally a bad idea
Oh, I don't know - what about the simple stuff like form validation? On a high traffic site, receiving a complex form from a client, only to have to send a page back saying "sorry, you forgot this field,do it again" seems to be a waste of both the servers resources and the user's time. Better to just have a JS popup telling them and changing focus to the problem field - no effort on your server's part is needed.
Of course, double-check everything you get at the server, just give the client a chance to sort it out at their end first before troubling you with it.
Parent