Closed Bug 536277 (Jaeger) Opened 15 years ago Closed 11 years ago

[meta] JaegerMonkey: Baseline method JIT

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: dmandelin, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: meta) 

This is the meta bug for an inline-threading baseline JIT for SpiderMonkey (JaegerMonkey). 

For reference purposes, bug 506182 was the bug for the nanojit/LIR-based prototype of this work.
Depends on: 536285
Alias: Jaeger
Summary: [meta] Inline-threading baseline JIT → [meta] JaegerMonkey: Inline-threading baseline JIT
Depends on: 541488
Depends on: ClosurePerf
Depends on: JaegerCompiler
Whiteboard: [evang-wanted]
Depends on: 547851
Depends on: 548844
Depends on: 549504
Depends on: 549507
Depends on: 549509
Depends on: 549511
Depends on: JaegerPIC
Depends on: 549963
Depends on: 551087
Depends on: 551339
Depends on: 551341
Depends on: 551636
Depends on: 551761
Depends on: 552128
Keywords: meta
Depends on: 556181
Depends on: JaegerBrowser
No longer depends on: 551341
Depends on: 555395
Depends on: 563842
Got sick of the archaic terminology in the bug title.
Summary: [meta] JaegerMonkey: Inline-threading baseline JIT → [meta] JaegerMonkey: Baseline method JIT
Depends on: 569441
Would Firefox 4 be released without this? As in, is it blocking the final release? Yet another major release without the speed that all other popular browsers are now able to show would be a disaster :/

(I think "really, really fast" JavaScript was promised in a slide about Firefox 4. Even with the goals defined at https://wiki.mozilla.org/JaegerMonkey, we would be slower than the others.)
The bug is blocking Firefox 4, plus this is a huge feature. If Arewefastyet.com is any indication, getting current fatval branch to trace would put us in the neighborhood with V8 and JSC. Then more optimizations after release could put us in the front!
This work is indeed slated for Firefox 4. 

We do have tracing on the fatval branch for x86. It is a smallish speedup against trunk (mostly--V8 benchmarks in the browser show pretty big wins).

Perf work is ongoing. Our goal is certainly to be as fast as V8 and JSC. Exactly how far we get between now and release time is unpredictable, but we're doing our best. As you say, we'll have the chance to continue work after that if necessary.
Depends on: JaegerSpeed
No longer depends on: 578245
Depends on: WebJSPerf
Depends on: 580429
Depends on: 580428
Depends on: 581620
Since the Mozilla FTP server contains current work on Electrolysis (also an ongoing project), what if JaegerMonkey's current status could be put into its own project folder on the server like Electrolysis? (Sorry if I'm referring to JaegerBrowser)
(In reply to comment #5)

There's a project branch (called "jaegermonkey") w/ tinderbox builds. They're not green yet but we're working on it.
@David Anderson: Thanks for pointing that out for me. I mentioned JaegerBrowser because I would love to try JaegerMonkey (JM) in an experimental build of Firefox. I understand that JM is in the early stages of development at the moment but the current performance results for JM on arewefastyet.com are starting to get interesting.
Shane, you can compile a browser from that branch right now, or if you just want a snapshot I can spin up a try server build for you; let me know.  But the point is that we know it doesn't pass our own correctness tests yet, so it's _definitely_ buggy.
(In reply to comment #8)

I am more than happy to try out a snapshot build (even if it's really buggy). I try out the trunk builds anyway so I'm used to bugs. I don't know how to build Firefox from source yet, even though I've done it with WebKit using Qt.
Boris, would the try server builds be here?: http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/
Depends on: 581936
Huh.  I wonder why I didn't get mail for comment 9...

Shane, I just pushed to the try server, and those builds will appear in the dir you list with my name on them in a few hours.  Once I know the exact url, I'll post it here.
I'm assuming it's http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/bzbarsky@mozilla.com-47f400145c83/

But the problem is I am running WinXP x86 and there is no build for it. Was there trouble compiling?
(In reply to comment #12)
> I'm assuming it's
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/bzbarsky@mozilla.com-47f400145c83/
> 
> But the problem is I am running WinXP x86 and there is no build for it. Was
> there trouble compiling?

My question was stupid. I just went through my emails and found out that JM failed to compile. Thanks for letting me know. :)
(In reply to comment #14)

The tinderbox build is 6,197 bytes smaller than the tryserver build. Why is that (other than the XUL dll)?
Both of the builds in comment 14 are jaegermonkey builds.  The second one is from my second try push.  The first one is from a tinderbox.  Unless you really care about the exact changeset you're testing, it doesn't matter which one you use.  The sizes are most likely different because they're just built from different changesets.... (though there are configuration differences between tryserver and the jaeger tinderbox too, I bet).
I've tried the JM build but was disappointed when using Celtic Kane's JS Benchmark. I was only getting scores of 190-195, while the latest nightly build scores between 200-225.
I was really looking forward to JM's promising performance but at the moment it's not as good as the trunk builds squeeze out, bearing in mind JM is still in heavy devlopment.

I know this is off the topic a bit but why are the trunk builds (and Firefox 3.6 for some reason) built to O1? I'd love to see even more potential performance improvements but I guess it's done to avoid build errors. :(
Celtic Kane's benchmark, like most of his benchmarks, is more or less BS.  In particular, it doesn't exercise anything that JM would actually help with, last I checked.
Looking at the benchmarks on arewefastyet.com it seems they're basically tied. I know they're to be integrated, but if they're performing nearly the same independently I don't see the combination being competitive with v8 et al. presently. It's not really a complaint since I know it doesn't affect real world usage much. It just seems like they're hitting the same set of issues, and as a layman I wonder what those are.
> It just seems like they're hitting the same set of issues,

Yes and no.  There are tests in Sunspider and V8-suite where TM is much much faster than JM, and vice versa.  Integrating them will help with such tests, as long as the heuristics are right.  There are also tests where both are slower than the competition due to runtime issues; see http://blog.mozilla.com/dmandelin/2010/07/19/jagermonkey-update-getting-faster/ for details.
BUG: JaegerMonkey builds freeze temporarily when javascript.options.methodjit.chrome is TRUE. Is this a known issue?

Also, it's possible to enable both tracejit(?) and methodjit in about:config but does not improve JS performance. Why? (sorry if I'm asking too many questions)
> Also, it's possible to enable both tracejit(?) and methodjit in about:config
> but does not improve JS performance.

It actually does; the tracejit is used to jit regexps even in JM builds.  But except for regexps the tracejit preference is ignored for now in JM builds, until dvander actually lands tracing integration.

It's worth filing a bug on the chrome thing, unless a bug search turns something up for you.
I haven't tested with javascript.options.methodjit.chrome=true yet. I'm still working on getting things to work right with the methodjit on for content.

On the combination of JM/TM and comparisons with V8/JSC, bz nailed it, but just to amplify: Most of the difference between us and them is: function calls, strings/regexps, object allocation, and a few other library function bits. JM/TM share all of those things, except that TM avoids some of the function call slowness with inlining, which may be why their perf is fairly similar. TM is particularly good on some code, so adding TM to JM might boost SunSpider by about 10% or so. Such comparisons are highly benchmark-dependent.
May I suggest moving general discussion out of this bug, which spams a lot of people, and into the newsgroups? Thanks.
Got carried away, sorry about that. I will move my discussion into the newsgroups instead.
I am more than willing to become the evangelist for this project because I see potential in this project and I would like to be a part of it.
Depends on: 585120
Depends on: 585541
Depends on: 586161
Depends on: 586518
Depends on: 588656
Depends on: 477999
Depends on: 591526
Depends on: 592781
Depends on: 617937
Depends on: 617949
Depends on: 617976
Depends on: 618007
Depends on: 618024
Depends on: 618150
Depends on: 618319
Depends on: 619565
Depends on: 619822
Depends on: 620649
Depends on: 620761
Depends on: 621055
Depends on: 621377
Depends on: 621421
Depends on: 621512
Depends on: 624483
Depends on: 624518
Depends on: 625141
Depends on: 625377
Depends on: 625438
Depends on: 625701
Depends on: 625718
Depends on: 625757
Depends on: 627857
No longer depends on: 627857
Depends on: 632157
Depends on: 646938
Depends on: 658968
Depends on: 659286
Depends on: 686106
Since IM landed, is this (and any dependant) Bug obsolete? Or is JM still in the code somewhere?
JM is still used.  IM doesn't kick in until the code is very hot.
So it's SM -> JM -> IM?

(To avoid further bugspam, only reply if I'm mistaken, or via email. Thanks.)
JM has been removed from the tree, replaced by Ion and Baseline.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [evang-wanted]
You need to log in before you can comment on or make changes to this bug.