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.
Comment removed (Score:2, Insightful)
Precursor to more of Firefox being in JS (Score:5, Insightful)
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: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.
Re:Precursor to more of Firefox being in JS (Score:3, Insightful)
Re:The Greatest Idea (Score:1, Insightful)
Expect this discussion to be full of astroturf, red herrings and trolls.
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++...
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.
Re:Wow (Score:2, Insightful)
Re:As fast as C code??? (Score:1, Insightful)
Re:Precursor to more of Firefox being in JS (Score:3, Insightful)
Interestingly, one of the linked blogs talks about how this could lead to more of Firefox being written in Javascript. I haven't done much non-web related Javascript programming, and I haven't really used those new frameworks, but it seems to me like application programming in Javascript is like trying to hammer a nail with the handle of a screwdriver. Sure, it might work, but there are much better tools for the job. What do you guys think?
Why do you think Javascript is so unsuitable? I've done a fair bit of application programming in Javascript and it's fine so long as you keep your code structured (so no different to Perl or even C in that regard).
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!"
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.
Re:As fast as C code??? (Score:1, Insightful)
given firefox's track record on memory useage, i won't hold my breath.
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.
Re:Performance is great and all (Score:3, Insightful)
Wow, you get a gold star for arguing word semantics unnecessarily! (Double bonus for intentionally being flamebait.)
The context of the entire thread, the performance boost, and my comment is that of JavaScript in web apps. My comment was *clearly* about JavaScript in the context of web apps. Hell, my first bullet was that the language and browser are tied too closely together. I guess you read what you want to read.
That said: practically there is no difference between DOM & JS. JavaScript has no libraries or modules which means all functionality IS the language (no more differentiable than alert()). Again: if there was any mention of writing stand-alone apps or tools in JavaScript then you'd have more of a point but what Firefox, IE, etc. provide as "JavaScript" is, de facto, JavaScript.
I hate to see what you work on to call threading, logging, debugging, reflection, missing XML parsers, minimal date support, drag-and-drop, browser identification, etc. (and that's just where I stopped) just "missing bits"? If you want to write real apps then that stuff is not "bits" but necessities.
Re:Premature optimization.... (Score:2, Insightful)
You fail. It's a pun, dude.
Re:Javascript can never run as fast as C (Score:3, Insightful)
However, I never said that improving JS performance is undesirable. It's the old scripting vs low level programming debate: Low level is faster, but needs more expertise and programmer time. Pick the best tool, etc.
The Mozilla architecture is a case in point. The UI is controlled by JS functions, which delegate all the hard work to XPCOM objects. That's more overhead than controlling the UI in C++ directly, but has the _huge_ advantage of being easier to modify and adapt the code for developers.
Re:Performance is great and all (Score:2, Insightful)
My comment was *clearly* about JavaScript in the context of web apps.
Then you should've framed it as such, rather than stating "[your] complaints with JS don't lie with performance.", thus clearly implying that you were going to go on a rant about JS, the language, as opposed to web browsers in general. Furthermore, your first bullet was this:
"Tied too much to the browser. JS works great for some (some love it) but syntactically I hate every last part of it. However: web == JS so I have no other option."
Frankly, I'm not sure *what* you're complaining about, here. First, it's that it's tied too much to the browser. 'course, that's simply a matter of tradition, there's nothing about the language that makes it browser specific (and there are a number of implementations of javascript that work outside of a browser context), and so it's a weak criticism at best. But then you bitch about the syntax... which, again, is just personal dogma, but so be it. And then you complain that you have "no other option", which isn't even a complaint about javascript, but rather about the browser implementations.
JavaScript has no libraries or modules which means all functionality IS the language (no more differentiable than alert())
Tell that to the guys who built Rhino. Or any number of other standalone JS implementations.
If you want to write real apps then that stuff is not "bits" but necessities.
Yes, but again, that has nothing to do with Javascript, the language, which is the subject of this article. Your problems seem to be with the W3C and the browser implementations, not with JS, so perhaps you should've phrased your post accordingly.
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.
Re:Performance is great and all (Score:3, Insightful)
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
Then what technology is The Answer on a platform where native code must be digitally signed by someone other than the user but JavaScript code need not be? Examples of such platforms include PSP, PS3, Wii, iPhone, and some enterprise installations of Windows.
Re:Fast as C but uses lots more memory (Score:3, Insightful)
Since web browsers usually can cache JavaScript it will be useful to cache the compiled JavaScript.
Next step is that we shall be able to see a server-side compiled JavaScript, but we will have to wait for browsers to support that. In that case we will be able to have language-agnostic browsers since the compiled code won't necessarily have to reflect which language that was used to write the script.
Re:As fast as C code??? (Score:2, Insightful)
no kidding.
take a simple statement such as this
x = y + z;
you could in theory have 3 different types going on here. C cheats and just munges it up to the highest type on the right and then truncates for whats on the left.
But in a typeless lang such as Python, VB, Javascript, etc... that thing turns into several function calls and nested switch statements. It is quite amazing how much the 'higher' languages hide from you.
Re:Precursor to more of Firefox being in JS (Score:2, Insightful)
Give JS some time. I had similar feelings when I first stepped into it, but now I've come to appreciate not having to worry about datatypes and the like.
There are occasions where I would appreciate some basic support for classes. But I suppose they could be mimicked through function variables in some way.
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.
Re:Java/C#/C++/C equally fast (Score:5, Insightful)
Comment removed (Score:5, Insightful)
Re:Javascript can never run as fast as C (Score:1, Insightful)
When Javascript is deployed, after the source text is downloaded from a web site, it must first be converted into executable form suitable for a VM. That extra translation step is an overhead which must be amortized over the execution time of the code. Since most Javascript code takes very little time to execute in the first place, this translation overhead is a significant fraction of total computing time in typical applications.
Because, obviously, caching whatever is pointed to by URLs doesn't work, so you can't cache any pre-transformed JavaScript. Right?
When properly done (both on the client and on the server side), the translation overhead will be O(1) the second time you visit a page.
Besides, the fact that improving stuff other than translation overhead (just tight loops!) has helped so much, means that on a good proportion of sites your assumptions simply don't hold.
I don't think that the goal of making JS "as fast as" C is impossible -- heck, I presume that due to the way the optimization is done, it can actually generate better code than gcc does now. The trivial example would be a function that calls a function passed as a pointer-to-a-function as an argument. I've checked a few months ago and gcc flatly refuses to optimize cases where a function is called with a constant pointer-to-function as an argument. OCaml native compiler from a few months ago didn't optimize this either.
As far as I understand it, the TraceMonkey either does it already or will do it very soon. Of course TraceMonkey's native code is not quite up to par yet, when compared with gcc, but it's an issue orthogonal to the optimizations obtained by the trace itself.
Cheers, Kuba
No (Score:5, Insightful)
And stay off the chans.
Re:suggestions for improvement (Score:3, Insightful)
So basically you suggest doing the exact opposite of what has been shown experimentally to work very in the article?
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)
Re:As fast as C code??? (Score:3, Insightful)
I'd have thought that it's possible in a limited scenario to produce the same machine code from various high-level languages. It surely depends on the compilation not the language?
[You're right, I'm not a programmer]
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.
Re:Fast as C but uses lots more memory (Score:3, Insightful)
You mean "in theory", not "in general". In general, real-world JIT systems are significantly slower than native code, though they certainly are noticably faster than regular bytecode, which in turn is faster than a pure interpreter.
Re:As fast as C code??? (Score:2, Insightful)
Clearly no matter how fast the interpreted language goes it can never be faster than C, as long as the interpreter (or JIT, or whatever) is written in C.
So if I wrote a C compiler in Ruby, the generated code could never run as fast as Ruby?
Even though that is what a JIT is doing, taking a bytecode (or source code) and compiling it (at runtime, thus benefiting additionally from the runtime statistics) into native code. It's been proven that JIT compiling native code into native code on the same architecture can improve performance (HP Dynamo) - maybe the original compiler wasn't very good?
Ruby, FYI, is about 50x slower than C for the same algorithms. Your comment is true if you had left out that "or JIT, or whatever" statement.
Nice but not enough... (Score:2, Insightful)
I've done *a lot* of javascript dev over the last 10 years, and I can tell one thing, execution speed of javascript has never really been my most important issue. In order network communications, DOM manipulation and that retarded single thread execution model where way higher on my annoyance list.
My hope is that someone will come up with a "pluggable" script engine that can be updated on demand so that I actually use those latest feature instead of having to target 5 years old tech if I don't want to lose potential clients. And yes I imply they should port their engine to IE.
Re:Not bad (Score:3, Insightful)
Re:As fast as C code??? (Score:3, Insightful)
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.
nonsense :) if you want machine performance, go with C/C++. If you don't care about how fast your app runs becuase you're focussed on programmer productivity go with Ruby or Python. Java/C# therefore is a worse-in-every-case option :)
Re:As fast as C code??? (Score:3, Insightful)
A JIT can work out the OS and exact chipset on which it is running and therefore choose to generate different native code optimized specifically for you system.
Even if a static C compiler happens to have been optimized for your exact CPU, cache size and memory a JIT could still collect or access runtime statistics about your application and do optimizations based on this information - this information is not available to a static C compiler.
Perhaps the .NET JIT sucks or always produces code that is slower than compiled C code - I have no idea. But it doesn't take a genius to work out that there are going to be cases where a JIT could produce better optimized code than a static compiler.
Re:As fast as C code??? (Score:2, Insightful)
Good point.
One thing though - please do not call C a "high level language" - this has no meaning. And since you accuse others of mangling terms, it is important to get this straight. C is human readable textual language expression. That is what it is.
Also, be careful generalizing. It is true that since C is a plaintext, it cannot be "fast" or "slow".But because of the way it expresses certain things, variables for instance, some optimizations will be out of reach for any C compiler.
This is why Bjarne for example advances C++ into the C++0x. The STL has gotten to the point where it was near the very performance ceiling it could provide with the C++ syntax, but some clever tricks using C++0x expression MAY help future C++0x compilers to optimize the code by having more information (which the code contains).
Stuff like "inline", "static" etc. This is an aid to compilers in optimizing code for speed. So even though strictly speaking C cannot be fast or slow, because it lacks such properties altogether, the real world compiler implementations do allow for certain languages to emit significantly faster process images than others. Consider an assembler program. Designed for one architecture, when ported to another, it becomes useless, because the abundance of many detailed instructions confuses the compiler, robbing it of the big picture. After all, a mov, cmp and jmp sequence does not tell much about what the program is all about, and there is little room for optimization.
Re:C is inefficient (Score:3, Insightful)
Huh? You say that C is a lousy language for performance and then commence to list the reasons why it is a good language for performance?
No, I list the reasons why C programs benchmark well even though the language is hard to optimize.
Anyway... it seems C can be optimized better than Fortran [...] but real-world examples and benchmarks do not agree with you.
The fact that you think that those numbers are in any way relevant to what we are talking about just shows that you know absolutely nothing about benchmarking or high performance computing.