3 ms·

To be fair - I've never seen such docs for SpiderMonkey. I may have just failed at finding them though. Keeping up-to date documentation of compiler is a horri

by fridek 13y ago

To be fair - I've never seen such docs for SpiderMonkey. I may have just failed at finding them though. Keeping up-to date documentation of compiler is a horrible job. I think it's good enough that V8 may be built as standalone binary with really extraordinary debug options and tools. At the same time, I'd love to see more talks like http://www.youtube.com/watch?v=FrufJFBSoQY http://www.youtube.com/watch?v=FrufJFBSoQY There are also guys who write about V8 from time to time (http://mrale.ph/ http://mrale.ph/ http://floitsch.blogspot.com/ http://floitsch.blogspot.com/ http://wingolog.org/tags/v8 http://wingolog.org/tags/v8) but this is needle-in-a-haystack type of learning.

kevingadd 13y ago
SpiderMonkey isn't a shining city on a hill in this case, certainly. In my experience though the docs that are there are easier to understand, the log messages are more verbose and understandable, and the developers are easier to get help from. I think this is all just a result of the fact that Mozilla relies more on community involvement to get stuff done, so they have to be a bit more dev-friendly. The same dislike of documenting performance details and internals exists on the SM team, though. Standalone binaries with debug options like d8 and spidermonkey js.exe are great for narrowly-scoped tuning and microbenchmarks, but in the real world your app runs in the browser and you end up having to debug and profile it there. That's where the whole picture falls apart (and where Spidermonkey's tools are dramatically better). Mozilla ships two different performance analysis tools for in-browser JS that give you extremely detailed, precise performance information (JIT Inspector and SPS). They're more stable than Chrome's tools on average as well. You can literally get the browser to dump the native assembly it produced when JITting a given function. I haven't done any perf tuning in a while, so this page is probably out of date, but I've made a point of documenting the stuff I discover about each engine, and linking to sources where possible: https://github.com/sq/JSIL/wiki/JavaScript-Performance-For-Madmen https://github.com/sq/JSIL/wiki/JavaScript-Performance-For-M...
- mraleph 13y ago
  > You can literally get the browser to dump the native assembly it produced when JITting a given function. You can literally get Chrome to dump native assembly it produces when JITting a given function. You just need to build Chromium yourself, because disassembler is not built into it. It's a dead bloat I guess for 99% of people, even for JS VM engineer disassembly is the last resort. You can get compiler IR from any Chrome build and people do get it. And usually it means that VM itself should be fixed. People should not need to care about IR or (worse) disassembly. If your code is reasonable it should just work reasonably fast. File bugs if it does not, instead of tuning, which can break as soon as V8 moves left or right.
  - kevingadd 13y ago
    To be more precise, the Firefox addon that does this lets you select a specific function and view the assembly on demand, instead of getting a multi-gigabyte IR/assembly dump from a debug build of the browser. That's what makes it useful. I agree that in general users should not need to care about IR or disassembly. Unfortunately, I'm not sure we'll ever end up in that world.
    - mraleph 13y ago
      I see, yes just printing a simple function on demand is indeed quite useful. IIRC V8 has Debug.disassemble(f), requires both a special build and mirror debugger exposed to the page. Prints disassembly to stdout. Can be tweaked to return disassembly as string, but that requires knowledge of V8. (I actually don't know who is the client of this function or why it was added). [side note: if you get function disassembly you can't really be completely sure that that's the code that was running 2 seconds ago, that's one of the reasons why V8 just dumps everything]
    - andrewf 13y ago
      Could you point me at this extension? I was trying to get disassembly of asm.js compiled by IonMonkey a couple of months ago. I had to run SpiderMonkey under gdb and disassemble the JITted entry points. (Or maybe I didn't...)

by fridek 13y ago

kevingadd 13y ago

SpiderMonkey isn't a shining city on a hill in this case, certainly. In my experience though the docs that are there are easier to understand, the log messages are more verbose and understandable, and the developers are easier to get help from. I think this is all just a result of the fact that Mozilla relies more on community involvement to get stuff done, so they have to be a bit more dev-friendly. The same dislike of documenting performance details and internals exists on the SM team, though. Standalone binaries with debug options like d8 and spidermonkey js.exe are great for narrowly-scoped tuning and microbenchmarks, but in the real world your app runs in the browser and you end up having to debug and profile it there. That's where the whole picture falls apart (and where Spidermonkey's tools are dramatically better). Mozilla ships two different performance analysis tools for in-browser JS that give you extremely detailed, precise performance information (JIT Inspector and SPS). They're more stable than Chrome's tools on average as well. You can literally get the browser to dump the native assembly it produced when JITting a given function. I haven't done any perf tuning in a while, so this page is probably out of date, but I've made a point of documenting the stuff I discover about each engine, and linking to sources where possible: https://github.com/sq/JSIL/wiki/JavaScript-Performance-For-Madmen https://github.com/sq/JSIL/wiki/JavaScript-Performance-For-M...

mraleph 13y ago
> You can literally get the browser to dump the native assembly it produced when JITting a given function. You can literally get Chrome to dump native assembly it produces when JITting a given function. You just need to build Chromium yourself, because disassembler is not built into it. It's a dead bloat I guess for 99% of people, even for JS VM engineer disassembly is the last resort. You can get compiler IR from any Chrome build and people do get it. And usually it means that VM itself should be fixed. People should not need to care about IR or (worse) disassembly. If your code is reasonable it should just work reasonably fast. File bugs if it does not, instead of tuning, which can break as soon as V8 moves left or right.
- kevingadd 13y ago
  To be more precise, the Firefox addon that does this lets you select a specific function and view the assembly on demand, instead of getting a multi-gigabyte IR/assembly dump from a debug build of the browser. That's what makes it useful. I agree that in general users should not need to care about IR or disassembly. Unfortunately, I'm not sure we'll ever end up in that world.
  - mraleph 13y ago
    I see, yes just printing a simple function on demand is indeed quite useful. IIRC V8 has Debug.disassemble(f), requires both a special build and mirror debugger exposed to the page. Prints disassembly to stdout. Can be tweaked to return disassembly as string, but that requires knowledge of V8. (I actually don't know who is the client of this function or why it was added). [side note: if you get function disassembly you can't really be completely sure that that's the code that was running 2 seconds ago, that's one of the reasons why V8 just dumps everything]
  - andrewf 13y ago
    Could you point me at this extension? I was trying to get disassembly of asm.js compiled by IonMonkey a couple of months ago. I had to run SpiderMonkey under gdb and disassemble the JITted entry points. (Or maybe I didn't...)