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 dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
