Slashdot Mirror
Firefox 18 Beta Out With IonMonkey JavaScript Engine
An anonymous reader writes with a quick bite from The Next Web about the latest Firefox beta, this time featuring some under-the-hood improvements: "Mozilla on Monday announced the release of Firefox 18 beta for Windows, Mac, and Linux. You can download it now from Mozilla.org/Firefox/Beta. The biggest addition in this update is significant JavaScript improvements, courtesy of Mozilla's new JavaScript JIT compiler called IonMonkey. The company promises the performance bump should be noticeable whenever Firefox is displaying Web apps, games, and other JavaScript-heavy pages."
None of these improvements feel any faster. Pages still load as quickly as they did a decade ago (provided your connection was fast). Why can't they make anything render faster?
Only the State obtains its revenue by coercion. - Murray Rothbard
With Mozilla's frequency of spitting out new and newer versions, I just can't keep up!
No problem, just turn automatic updates on.
Signature has left the building.
I haven't kept track with the JIT's that have been in Firefox. I recall the days when TraceMonkey and JagerMonkey were added to boost performance. Could somebody recap or tell why Firefox is abandoning the older versions or redoing them? I'm truly curious as to what they learned, what worked and what didn't work. Are they finding new usage patterns that warrant a new JIT design? Thanks.
Its good to see the focus of this release being an attempt to increase javascript speed by leaps and bounds. Modern webpages often use JS that goes way beyond anything people did 10 years ago (Jquery for example) and the complexities of what people do with javascript noticably slow down most webpages considerably.
http://interserver.net/
Its good to see the focus of this release being an attempt to increase javascript speed by leaps and bounds. Modern webpages often use JS that goes way beyond anything people did 10 years ago (Jquery for example) and the complexities of what people do with javascript noticably slow down most webpages considerably.
When I first learned to program in BASIC, I used to think that people should try speeding up C and Assembly language -- Make EVERYTHING run faster... Then I learned C and x86 Assembly and I realized, you can't speed up assembly language -- It's a perfectly optimized language, there's nothing under the hood to tweak. You might select a better algorithm, or better use registers, but this isn't changing ASM. C can't really be hugely optimized either, it's pretty close to the metal, but there there are a few things one can do to increase performance in the space of its minimal abstractions; fewer with a mature compiler on mature hardware/platform...
I always wondered what the deal was with JavaScript too, "Wow, it's getting faster, AGAIN?" Then I created my own languages and compilers and I learned: A sign of a horribly designed language is that the speed of its implementations can be repeatedly increased "by leaps and bounds"...
But only marginally so. In most benchmarks, it looks to be roughly on par with v8 now. In some, what, 20% slower? I think that's pretty respectable - compare with the situation a year or two ago when Firefox's Javascript engine was several times slower than v8.
Wikipedia goes into a bit of detail about it but in basic summary...
TraceMonkey was the first JIT compiler for SpiderMonkey released in Firefox 3.5.
JagerMonkey is a different design on TraceMonkey which outperforms it in certain circumstances (Some differences between TraceMonkey and JagerMonkey)
IonMonkey is another attempt at better perfecting the idea of JagerMonkey allowing even greater optimisations under particular circumstances.
However TraceMonkey, JagerMonkey and IonMonkey are part of SpiderMonkey as JIT compilers, not a replacement of SpiderMonkey itself.
That's not quite true.
TraceMonkey has in fact been removed, and JaegerMonkey may be too once the new baseline JIT being worked on now is done.
A short summary:
1) TraceMonkey turned out to have very uneven performance. This was partly because it type-specialized very aggressively, and partly because it didn't deal well with very branchy code due to trace-tree explosion. As a result, when it was good it was really good (for back then), but when it hit a case it didn't handle well it was awful. JaegerMonkey was added as a way to address these shortcomings by having a baseline compiler that handled most cases, reserving tracing for very hot type-specialized codepaths.
2) As work on JaegerMonkey progressed and as Brian Hackett's type inference system was being put in place, it turned out that JaegerMonkey + type inference could give performance similar to TraceMonkey, with somewhat less complexity than supporting both compilers on top of type inference. So when TI was enabled, TraceMonkey was switched off, and later removed from the tree. But keep in mind that JaegerMonkey was designed to be a baseline JIT: run fast, compile everything, no fancy optimizations.
3) IonMonkey exists to handle the cases TraceMonkey used to do well. It has a much slower compilation pass than JaegerMonkey, because it does more involved optimizations. So most code gets compiled with JaegerMonkey, and then particularly hot code is compiled with IonMonkey.
This is a common design for JIT systems, actually: a faster JIT that produces slower code and a slower JIT that produces faster code for the cases where it matters.
https://blog.mozilla.org/dmandelin/2011/04/22/mozilla-javascript-2011/ has a bit of discussion about some of this.
aaaand I'll be abel to boot Linux faster!
I don't understand why this comment got +5. It is pretty misguided.
The statement:
> I realized, you can't speed up assembly language -- It's a perfectly optimized language, there's nothing under the hood to tweak
makes some limited sense in some contexts (one could argue that the microcode supporting the assembler on the CPU is repeatedly optimized), but none in this. The IonMonkey JIT does essentially optimize the assembler code[*], by rearranging it in various ways to make it faster. E.g. it takes stuff like this (in javascript, as I have not written assembler in years):
for ( var i = 0; i != 10 ; ++ i ) {
var foo = "bar";
}
and changes it to e.g. this:
for ( var i = 0; i != 10; ++i ) {
}
var foo = "bar";
possibly then this:
var foo = "bar";
This is an optimization and it is performed at assembler level (Again: the above is not meant to be read as JavaScript, but assembler).
The other statement that really sticks out is this:
> A sign of a horribly designed language is that the speed of its implementations can be repeatedly increased "by leaps and bounds"...
This simply highlights that the poster really do not understand the goals behind crossplatform languages, such as Java, Dalvik, JavaScript, lisp, ML, Python, Perl, and so on, or the goals for weakly typed languages.
[*] It works on an abstract representation of the assembler code, but it might as well have been working directly on the assembler, was it not for the fact that this would require it to learn to many assembler variants.
I have to support a lot of low power systems and since around FF V6 its been completely unusable, especially for watching SD video, but even opening new tabs can cause FF to slam the CPU to 100%.
Well, yes. I have an eee 900 (which is single core). I found firefox and chromium both to be pretty pathetic at playing video. Even in HTML 5. Actually, I'm not sure how they manage to make such a meal of it. It's really terrible. They're basically no better than flash. Perhaps even worse.
I used to use flashvideoreplacer, but that doesn't work any more. I now use a greasemonkey script which basically replaces youtube videos (perhaps others?) with MPlayer, and it can decode 720p just fine in realtime.
Firefox can slam the CPU to 100%. Chromium is multiple threaded, so it can slam the CPU to 100% with a load average of 57 making the machine grind completely to a halt.
Chromium feels a bit snappier in that the UI elements give visual feedback quicker, but it doesn't actually seem to get the pages up faster. I switched back to firefox after a while.
SJW n. One who posts facts.
Then I learned C and x86 Assembly and I realized, you can't speed up assembly language -- It's a perfectly optimized language, there's nothing under the hood to tweak.
Well, not really. You can't optimize perfectly optimized assembly any further, but that's just tautology. You can optimize even quite well written assembly further, especially on modern CPUs with various selections of functional units, variable pipelines, multiple instruction dispatch per cycle, vectorising etc.
In fact, the days have generally passed where I can write better ASM that what gcc can output from a C/C++/Fortran program, because it has much better knowledge of the CPU internals and is generally better at doing things like register allocation etc.
In terms of Fortran, C99 and GNU's extensions to C++, it can even be told when pointers don't alias, so one of the final benefits of assembly has vanished. With good SSE scheduling and support from within higher level languages, the other main benefit of assembler has vanished.
It's now at the point where C++ is generally faster than assembler for all but the best of assembler programs and some very specific cases, for instance where it helps to have direct access to something like the CPU flags.
One reason is that the optimizers have got really, really good. They can even figure out when you're stepping through a 2D array in the wrong order can re order the loops. They are also excellent at removing redundancy which means you can write simpler code (and therefore write more advanced algorithms much more easily) without worrying about redundancy killing performance.
The optimizers are amazing and do an awful lot. This is why optimized code is more or less impossible to debug. Once it does passes of inline, partial redundancy emimination, loop unswitching, fusion, strip mining, dead code elimination, constant propagation, alias analysis, loop unrolling, modulo scheduling and register allocation, a given instruction probably doesn't correspond to any one line of code at all, so no stack trace is even possible.
And as for assembly, things aren't so simple there. Look at the difference between the faster clocking P4 and the much faster performing Ivy Bridge i7. The result of that is essentially that the i7 has an optimizer inside it which runs at 3.3 GHz and performs many of those steps real-time before actually farming out instructions for computation. IPC is all about optimizing assembler as much as possible.
Then I created my own languages and compilers and I learned: A sign of a horribly designed language is that the speed of its implementations can be repeatedly increased "by leaps and bounds"
It depends on what you mean "horribly designed". Many languages are designed to be easy for some particular task rather than maximal performance. It's hard to argue that Haskell is poorly designed, but optimization is a very tricky problem and performance has certainly increased greatly as optimization techniques have become well understood.
Even FORTRAN, which was specifically designed to be optimizable even given the non-existant state of the art at the time (optimizing compilers were essentially invented for FORTRAN) has seen significant improvements in the performance of the compilers.
C and C++ which were designed to be close to the metal and so not need much optimizing have also got much better with improved optimizers.
It seems that the key to a high performing language is to allow the user to tell the computer as much as possible about the program's intent, so that things can be proven and optimization can be performed.
SJW n. One who posts facts.
The problem is that as runtimes evolve the compiled format changes. Furthermore, the end result of the compilation depends on the exact processor being used by the user, and at least in SpiderMonkey on things like the location of the Window object in memory.
Not only that, but the final compiled version is unsafe machine code, so a browser couldn't trust a web page to provide it anyway.
So pages wouldn't be able to provide a final compiled version no matter what. They may be able to provide bytecode of some sort, but again the bytecode format browsers use is not fixed (assuming it exists at all; V8 doesn't have a bytecode) and compilation of JS to bytecode would have to be replaced by some sort of bytecode verifier for security reasons, so there may not even be much of a performance win from the switch.
Yes, apparently they did, but it's still quite recent (and only works on Windows 7). Naturally, it took them years to come out with it after 64-bit Windows came out (yes, I'm counting XP x86_64, it was a 64-bit desktop OS). Whether or not Adobe came out with it now, they're hardly the ONLY plug-in developer. The problem of plug-ins not being ported to 64-bit browsers on Windows is hardly just Adobe's. That being said, I'm not sure why you think Flash is the only plug-in Adobe makes.
Yes, we get it, you're a person that works on everything, and so you know what you're talking about. That's nice. Some of us have been using Fx just fine (including myself), only we don't complain about it every time it comes up on Slashdot. You're not going to convince me to stop using Slashdot because you named a list of machines you work on and say that Firefox has been awful on every single one. If Fx stops working well on my machines, then I'll switch, but I'm not going to switch just because someone says Fx doesn't work for them.
If you're talking about HTML5 video then fine, but if you're talking about Flash, why in the hell are you blaming the browser for that? Naturally, on the three computers I regularly use, I have exactly zero of the problems you mention, with both HTML5 and Flash videos. Anecdotes are completely pointless, because everyone can have different experiences. Yours aren't special because you can list a lot of computers.