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.
Script kiddies will be able to infect a Windows user in record time! Seriously,I install Noscript automatically with every new build and show the customer how to use it. It has just gotten too easy to infect Windows with JavaScript and it seems like everyday you're reading of a new JavaScript exploit. So it is safer just to kill it than to take the chance. So for me and my users at least it doesn't matter how fast FF renders JScript,because it has just gotten too dangerous to use. It is like saying "We've increased the speed of ActiveX by 300%!". But as always this is my 02c,YMMV
ACs don't waste your time replying, your posts are never seen by me.
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?
All your base are belong to Wii.
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. This is a good thing.
THL phish sticks
Expect this discussion to be full of astroturf, red herrings and trolls.
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++...
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.
+1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
Clear identification and optimization (e.g. compiling) of invariants can also dramatically increase speeds. I can't think of a loop that cannot be optimized (except for recursion, where you will have to unwind it and implement it in another way i.e. iteratively). So can looking at the problem from a different angle--i.e. the loop is different.
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!"
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.
Life is just a conviction.
given firefox's track record on memory useage, i won't hold my breath.
If you mod me down, I will become more powerful than you can imagine....
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.
Arash Partow's Philosophy: Be a person who knows what they don't know, and not a person who doesn't know.
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.
:wq
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.
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.
http://psyco.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, 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.
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.
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.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
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.
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?
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.
I can't speak to the C# benchmark, but I can't imagine any case where C++ would outperform C in straightforward computation. The fact that you have C++ two seconds faster indicates to me an error margin of at least two seconds in your tests.
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
ACs don't waste your time replying, your posts are never seen by me.
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
And stay off the chans.
So basically you suggest doing the exact opposite of what has been shown experimentally to work very in the article?
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)
I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
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]
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.
You are in a twisty maze of processor lines, all alike.
There is a lot of hype here.
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.
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.
I know JavaScript is the future of everything only because it's the only language that is available on "The Cloud" access devices (read "web browser" for you non web3.0 equipped reader) and it's good it get some optimization but when I see image manipulation software written in javascript and running inside a browser I mentally form the image of a giant rubber hammer trying to force a screw into a concrete wall.
:)
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.
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 :)
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.
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.
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.