Slashdot Mirror
Firefox Gets Massive JavaScript Performance Boost
monkeymonkey writes "Mozilla has integrated tracing optimization into SpiderMonkey, the JavaScript interpreter in Firefox. This improvement has boosted JavaScript performance by a factor of 20 to 40 in certain contexts. Ars Technica interviewed Mozilla CTO Brendan Eich (the original creator of JavaScript) and Mozilla's vice president of engineering, Mike Shaver. They say that tracing optimization will 'take JavaScript performance into the next tier' and 'get people thinking about JavaScript as a more general-purpose language.' The eventual goal is to make JavaScript run as fast as C code. Ars reports: 'Mozilla is leveraging an impressive new optimization technique to bring a big performance boost to the Firefox JavaScript engine. ...They aim to improve execution speed so that it is comparable to that of native code. This will redefine the boundaries of client-side performance and enable the development of a whole new generation of more computationally-intensive web applications.' Mozilla has also published a video that demonstrates the performance difference."
An anonymous reader contributes links the blogs of Eich and Shaver, where they have some further benchmarks.
Correct me if I'm wrong, but generally speaking, I was always under the impression that, as an interpreted language, javascript will never be able to run 100% as fast as natively compiled C code.
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 :)
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.
Bjarke Roune
Well, XUL is just an XML language used for the UI. As far as I know the main codebase is C++/JS right now, but probably more C++ than JS.
All your base are belong to Wii.
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.
A real world Javascript program will rarely, if ever, be as fast as C. The idea with this is: Normally, loops, no matter how tight, are executed in the interpreter environment with all the overhead that it entails. The idea is to profile loops that are 'hot' enough to be compiled to machine code so that the following iterations don't have the overhead of the interpreter. The more iterations for a loop the potentially faster speedup. Since compiling in itself takes time obviously part of the profiling will be to determine if a loop is worth compiling or not.
JS drives most of GUI interaction in FF. The bulk of the C++ is down in gecko, for rendering speed.
Climate Progress - Hell and High Water
Like stupid simple multimedia.
like SVG, <canvas> <audio> and <video>
Climate Progress - Hell and High Water
The amount of ignorance in this community is quite disturbing. I suspect that part of the cause is the unchecked pro-c religion, which always begins "C as faster than ...."
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.
"His name was James Damore."
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.
Well, you're on the right trail, but not quite right. The key difference between Javascript and C, from an optimization standpoint, is the type system. The overhead of dynamic types is quite immense even at its most optimal. I suggest looking into the architecture of the DLR -- it really shows the key problems behind compiling dynamic languages and how they're being solved.
Disconnect and self-destruct, one bullet at a time.
It does rival Flash. They're working with Adobe on Tamarin, which is using the same core JS engine in Mozilla and Flash (ActionScript).
The environment the JS runs in is different, of course. But the language itself... not so much. (They do have different parsers, though. They're different dialects of ECMA-262)
intensive purposes
"Intents and purposes." Somewhere, an English teacher cries.
Dewey, what part of this looks like authorities should be involved?
I'm sure you could easily argue back
I think I will
Tied too much to the browser/Bad syntax
Browser means it runs anywhere, syntax is C-like.
No reflection.
You can enumerate an object's methods, variables, etc as you can any other hash table.
No dictionary/Adding stuff to Object (prototype.js)
{} is a dictionary, no need to use Object. Even the author of prototype.js realized that adding methods to Object is a bad idea. I will complain that JS hash keys can only be strings.
No threading. No locking. Nothing resembling concurrent programming. The more complicated your app the more arbitrary events and multithreading are important.
setTimeout and setInterval are your friends. Cooperative multitasking makes some classes of problems more difficult, but greatly simplifies the language. There's quite a bit of infrastructure needed for correct behavior in the presence of preempting.
Scoping. Scoping is mind-numbingly bad.
Agreed. JS needs block level scoping like other sane languages.
Namespaces (again, see library complaint) are implemented via object nesting, which isn't really namespaces
It doesn't need to be called one to be one.
Logging and debugging/Haven't used firebug/Creators weren't thinking about debugging
If you haven't used Firebug, you are missing out! Debugging is no worse than other languages, and far better than IE's debugging support.
Standard dialogs are alert() and confirm(). Anything and everything else you have to roll your own...
Dialogs are modal... I think the absence of dialogs on the web encourages more usable alternatives.
Browser identification and JS version identification. Why should I have to jump through hoops, poke & prod things, and guess at what my JS run-time is?
Don't. Trigger off of capabilities rather than browsers. There may be a few instances where you have to specifically check for IE, but this is an exception rather than a rule.
... [JS is] a grossly inadequate language for rich application development...
Besides the scoping gone horribly wrong, I can't agree with your conclusion.
My wording was wrong - I did understand your paragraph and was merely trying to point that JS could be very helpful when doing SS'ing since it has native Dom parsers and methods. Indeed, there are many things in JS that lend itself well to being able to "read itself" - see Douglas Crockford's comments on JSLint, for instance.
Ever since the matrix, it's been green text on black background. That movie was 10 years ago, get with the times man!
No, Donald Knuth, Structured Programming with go to Statements, ACM Computing Surveys, Vol 6, No. 4, Dec. 1974 (p.268). (Unless you can find a reference for Hoare having said it. See here.)
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.
It's not that simple. A native compiler can do profiling as part of the compilation, and spend quite a bit of time on branch prediction and other time consuming optimizations. Five seconds extra while compiling natively might not be a problem, but five seconds extra when JIT compiling might be unbearable.
However, where languages like javascript, java and C# will always lose the most is in preemptive task switching, where the overhead is humongous compared to the native pre-compiled code, and you'll end up not just invalidating L1 cache but L2 (and great parts of L3 too where present).
Another loss is the lack of link time optimizations. Two identical static functions can not be identified and merged. Nor can the functions be reordered to avoid page switching. Nor can virtual address mapping be done ahead of time (like SGI's requickstart and Linux' simpler prelink).
JIT can du run-time profiling with valid data and genuine IO? So can native compiled code. It's just more work to set it up, but it's not rocket science either.
Yes, you can get JIT code that approaches compiled code, but only for special cases, and the price is both a much higher memory use (which can negatively impact other tasks you may have running) and increased startup time. But I have yet to see bytecode or JIT that runs faster unless the tester does some blatant cheating to get the desired results (e.g. by using different algorithms, like comparing perl's using hash tables to a linear search in C, or by disabling all optimizations in the native compiler but keeping them in the JIT compiler).
Except that C# code isn't as fast as C code. It's 2.7 times slower.
IIRC, it's possible for the same program to be faster when compiled using the C++ mode of the compiler than the C mode, due to C++ being stricter and allowing some optimisations that aren't safe in C. Don't quote me on this, though.
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.
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.
tip: don't use Task Manager, for investigating performance issues, use PerfMon (under administrative tools on your start menu).
Open a performance report, add the %CPU counter for just IE (it'll be under the Process counter set).
You can get it to update faster than 1 second default, and get it to log to a file instead so you can view it later. Add a network counter and memory counter too for more insight.
At least IE natively will let you debug JS!
That's the first I've heard of that. In order to debug JavaScript you either have to have Office installed, or download the MS Script Debugger. IE does report errors, but their description is horrible. I've found that just the error console in Firefox is much, much better than IE's error reporting. You really should look into Firebug. It's invaluable
Just use hasOwnProperty.
for (var i in myDict) if (myDict.hasOwnProperty(i)) {
doStuffWith(myDict[i]);
}