This is really really cool! One thing that I think would be really informative is how much time is spent in C++ stubs called from the baseline/ion. They happen frequently enough that you probably wouldn't want them to be interleaved on the graph, but maybe the time could be summed and attached to the enclosing jit block and then, I dunno, you could change the color of the block to indicate the % of time in stubs?
Cheers, Luke ----- Original Message ----- > I took the time to get tracelogging up and running again and create V2 out of > it. I think most know tracelogging already, but for those that don't: > > Tracelogging traces when which scripts runs and which engine we use for it. > Out of the log information I create graphs showing when which engine is run. > The graphs are visible on http://alasal.be/ionmonkey/ currently only for > Octane. > > So what is this reviving about. I had to patch spidermonkey properly again > after baseline got added and jeagermonkey was removed. The patch to do this > is in https://bugzilla.mozilla.org/show_bug.cgi?id=895019 and will get into > mozilla-inbound as soon as it is open for some decent time. Everybody can > trace any script by providing the --enable-trace-logging to ../configure > (64bit only atm, I don't have enough registers on 32bit). Afterwards when a > scripts run the information will be logged to /tmp/tracelogging.log. > > I also created a python script to get some meaningful information out of it. > Nice graphs ;). But actually much more info can get out of it. It's that > file I used to profile octane and find problems in it. The python script > that create nice graphs is on https://github.com/haytjes/tracelogger > (generate.py). > > I want to get this running automatically again. I'm looking into that, but > I'll probably need a dedicated machine/hosting for this. Something like > arewefastyet. So that's coming ;). > > So I now made the graphs for octane, normal and the GGC version. > > Some things I noticed on the graphs: > 1) Nice work Terrence with GGC. The graphs of raytrace and earley-boyer are > much nicer on it > > 2) There is something strange going on with Splay GGC. We could be much > faster on it. It seems like we are stuck in baseline on splay.js:49 for a > lot of time! That function is doing nothing but returning a value, but > somehow that takes 25% of the execution time (excluding gc). I guess > something bogus is happening there. We don't have this issue on Non-GGC > branch > > 3) Deltablue is taking 13% for compiling. That is a lot. Mostly caused by GC > throwing all scripts away. We (terrence, nbp and I) have been talking and it > would be a nice win if we could keep active scripts after GC's. The > consensus was that it shouldn't be that hard and give a nice boost. > > 4) Pdf.js is still our problem child. We are jumping a lot between baseline > and ionmonkey. I still haven't come around to look into it. Some issues are > already reported by nbp. But we still have a long way to go with this > benchmark. > > 5) Mandreel is taking a lot of time compiling. Mind this is IonBuilder only! > (we run parallel compilation). 17% is spend in IonBuilder and we don't gc. > So this is interesting and a nice place for improvement. > > 6) Gbemu runs way to much in baseline. That is 30%. I think we bail a lot in > that benchmark. So we need to find out how to run more in ionmonkey for this > benchmark. > > 7) Code-load runs only in interpreter/baseline. I think that is normal? Can > someone confirm? > _______________________________________________ > dev-tech-js-engine-internals mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals > _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
