[Discussion] Spidermonkey upgrade

[alpha123]

I guess that's been covered a lot(couldn't find in forum search, though), and I'm very late there, but why not V8 js engine ( https://code.google.com/p/v8/ )?

1. That would be much harder than simply upgrading SpiderMonkey.
   
2. It would be a ton of work for no performance gain - SpiderMonkey is at least comparable with V8's performance these days, sometimes it is even faster.
   
3. The code contains quite a lot of SpiderMonkey-specific synax (short lambdas, destructuring assignments, array comprehensions, etc).
   

V8 does have far better docs though.

[Yves]

I don't like it when people tell me to redo everything from scratch after writing tons of code .

... no I'm just kidding, of course it's always good to talk about alternatives.

There's a bigger community around than mozilla js afaik, lots of apps & docs & tutorial around (http://athile.net/li...ary/V8/Tutorial), nicer docs

Yes the docs are a problem but I've already used APIs that were a lot worse in that regard.

and also has buitltin profiler/debugging capabilities. (even gdb support https://code.google....GDBJITInterface or with some work webkit/chrome dev tools like nodejs did here https://github.com/d.../node-inspector ).

Spidermonkey also has some integrated profiling and debugging support. We even have a graphical interface.

If I understand that GDB support correctly it just shows symbol names in the backgrace but it doesn't allow you to actually step through the JS code, right?

Alpha123 has some good points. It would be a lot more work at the moment and both engines are developing well, so I wouldn't take performance into account at all. Maybe Spidermonkey's documentation will also improve in the future.

[tuan kuranes]

Ok. got the point. now documented in forum why mozilla-js rather than v8.

@alpha123

1. agree. Just want to make sure alternatives are known/considered. Docs, support & community is a big part of reliable 3rd party library, better change soon than late and having more work to do when having to upgrade...
   
2. Didn't know that js code could be SpiderMonkey-specific. Perhaps "Polyfills" (like es5/es6 polyfills) could perhaps help there?
   
3. Not sure about same perf, as to my understanding that mozilla-js optimisation where mostly "tracing" (spotting and optimising hot-path) and v8 were more "compilation" (type inference) oriented
   

@Yves:

I know I'm late. Just wanted to be sure that alternative are considered (especially when hitting a wall)

Yeah, GDB thing is just stack trace naming, still useful though, notably in Cpu profilers that get lost by js stack...

My secret point is that mozilla-js is really a pain to get running, especially under win64... still didn't succeed here (would like to be able to release 64bits exe, much faster, notably on the fixed sqrt calls...)

[historic_bruno]

My secret point is that mozilla-js is really a pain to get running, especially under win64... still didn't succeed here (would like to be able to release 64bits exe, much faster, notably on the fixed sqrt calls...)

That would be nice to have, in fact building most of the libraries on Windows is a pain We've discussed a few times setting up VC++ projects for them and having the source code in an SVN repo somewhere (part of the ongoing Git migration), so it would be simple[r] to build them with new compilers.

Does this help? https://developer.mozilla.org/en-US/docs/SpiderMonkey/Build_Documentation#Specifying_compilers_and_compiler_flags

To build a 64-bit Windows version, you can use the following:

$SRC/configure --host=x86_64-pc-mingw32 --target=x86_64-pc-mingw32

Note: You must have started your MozillaBuild shell with the proper -x64.bat script in order for the 64-bit compilers to be in your PATH.

(assuming it applies to 1.8.5)

[alpha123]

agree. Just want to make sure alternatives are known/considered. Docs, support & community is a big part of reliable 3rd party library, better change soon than late and having more work to do when having to upgrade...

You have good points. I really, really wish the SpiderMonkey docs/support/community was better.

The library itself is excellent though. (Well, at least performace/feature wise.)

Didn't know that js code could be SpiderMonkey-specific. Perhaps "Polyfills" (like es5/es6 polyfills) could perhaps help there?

You can't really polyfill this:

[n * n for each (n in [1, 2, 3, 4, 5])].map(function  n + 1)  // [2, 5, 10, 17, 26]

contrived example, but demonstrates some (but not nearly all) of the SpiderMonkey-specific syntax.

Not sure about same perf, as to my understanding that mozilla-js optimisation where mostly "tracing" (spotting and optimising hot-path) and v8 were more "compilation" (type inference) oriented

SpiderMonkey doesn't use a tracing JIT anymore, they use a method JIT (like V8) combined with a powerful type inference and optimization engine. I wish they had put more effort into TraceMonkey personally; IMO tracing JITs are superior to method JITs. Just look at LuaJIT (an insanely fast tracing JIT compiler).

[Yves]

I've compared v1.8.5 and v17 using sunspider.

How I did the tests (also the same for the sunspider-1.0 suite):

svn checkout http://svn.webkit.org/repository/webkit/trunk/PerformanceTests/SunSpider
cd SunSpider
./sunspider --args='"-m -n"' --shell=/home/yves/Projekte/0ad_original_trunk/libraries/source/spidermonkey/js-1.8.5/js/src/build-release/shell/js --run=30 --suite=v8-v6
./sunspider --args="-m -n" --shell=/home/yves/Projekte/0ad_spidermonkey1_trunk/libraries/source/spidermonkey/mozjs17/js/src/build-release/shell/js --run=30 --suite=v8-v6
./sunspider-compare-results --shell=/home/yves/Projekte/0ad_spidermonkey1_trunk/libraries/source/spidermonkey/mozjs17/js/src/build-release/shell/js --suite=v8-v6 v8-v6-results/sunspider-results-2013-05-25-16.58.04.js v8-v6-results/sunspider-results-2013-05-25-16.59.41.js | gedit

The results of the sunspider-1.0 benchmark:

TEST				   COMPARISON			   FROM				 TO			 DETAILS
===============================================================================
** TOTAL **:		   1.21x as fast	 340.8ms +/- 0.3%	280.5ms +/- 0.3%	  significant
===============================================================================
  3d:				  1.098x as fast	 54.3ms +/- 1.4%	 49.5ms +/- 1.5%	  significant
	cube:			  1.065x as fast	 20.2ms +/- 3.9%	 18.9ms +/- 4.0%	  significant
	morph:			 1.42x as fast	  15.2ms +/- 0.4%	 10.7ms +/- 1.3%	  significant
	raytrace:		  *1.048x as slow*   19.0ms +/- 0.8%	 19.9ms +/- 0.3%	  significant
  access:			  2.35x as fast	  54.1ms +/- 0.1%	 23.0ms +/- 0.2%	  significant
	binary-trees:	  2.18x as fast	   6.2ms +/- 0.5%	  2.8ms +/- 0.4%	  significant
	fannkuch:		  2.26x as fast	  22.6ms +/- 0.1%	 10.0ms +/- 0.1%	  significant
	nbody:			 2.74x as fast	  15.5ms +/- 0.1%	  5.7ms +/- 0.2%	  significant
	nsieve:			2.18x as fast	   9.8ms +/- 0.3%	  4.5ms +/- 0.3%	  significant
  bitops:			  1.57x as fast	  33.7ms +/- 0.2%	 21.5ms +/- 0.4%	  significant
	3bit-bits-in-byte: 2.33x as fast	   3.0ms +/- 0.4%	  1.3ms +/- 0.7%	  significant
	bits-in-byte:	  1.62x as fast	  11.5ms +/- 0.1%	  7.1ms +/- 0.7%	  significant
	bitwise-and:	   1.42x as fast	   9.2ms +/- 0.6%	  6.5ms +/- 1.0%	  significant
	nsieve-bits:	   1.51x as fast	  10.0ms +/- 0.0%	  6.6ms +/- 0.2%	  significant
  controlflow:		 1.164x as fast	  3.4ms +/- 0.1%	  2.9ms +/- 0.2%	  significant
	recursive:		 1.164x as fast	  3.4ms +/- 0.1%	  2.9ms +/- 0.2%	  significant
  crypto:			  *1.191x as slow*   23.4ms +/- 0.3%	 27.8ms +/- 0.3%	  significant
	aes:			   *1.178x as slow*   12.2ms +/- 0.2%	 14.4ms +/- 0.2%	  significant
	md5:			   *1.42x as slow*	 6.4ms +/- 0.8%	  9.0ms +/- 0.7%	  significant
	sha1:			  1.080x as fast	  4.8ms +/- 0.3%	  4.4ms +/- 0.3%	  significant
  date:				*1.189x as slow*   30.4ms +/- 1.0%	 36.2ms +/- 0.4%	  significant
	format-tofte:	  *1.142x as slow*   18.2ms +/- 0.8%	 20.8ms +/- 0.4%	  significant
	format-xparb:	  *1.26x as slow*	12.2ms +/- 1.8%	 15.4ms +/- 0.7%	  significant
  math:				1.72x as fast	  45.2ms +/- 0.2%	 26.3ms +/- 0.2%	  significant
	cordic:			2.54x as fast	  15.0ms +/- 0.4%	  5.9ms +/- 0.4%	  significant
	partial-sums:	  1.32x as fast	  20.1ms +/- 0.3%	 15.2ms +/- 0.2%	  significant
	spectral-norm:	 1.93x as fast	  10.1ms +/- 1.0%	  5.2ms +/- 0.3%	  significant
  regexp:			  *1.009x as slow*   18.3ms +/- 0.3%	 18.5ms +/- 0.2%	  significant
	dna:			   *1.009x as slow*   18.3ms +/- 0.3%	 18.5ms +/- 0.2%	  significant
  string:			  1.042x as fast	 77.9ms +/- 0.1%	 74.8ms +/- 0.3%	  significant
	base64:			1.52x as fast	   9.0ms +/- 0.3%	  5.9ms +/- 0.3%	  significant
	fasta:			 1.51x as fast	  15.6ms +/- 0.3%	 10.3ms +/- 0.3%	  significant
	tagcloud:		  *1.048x as slow*   21.6ms +/- 0.3%	 22.6ms +/- 0.7%	  significant
	unpack-code:	   *1.20x as slow*	22.5ms +/- 0.2%	 27.0ms +/- 0.3%	  significant
	validate-input:	1.039x as fast	  9.3ms +/- 0.3%	  9.0ms +/- 0.4%	  significant

And the v8-v6 benchmark:

TEST			  COMPARISON			   FROM				 TO			 DETAILS

===============================================================================

** TOTAL **:	  1.84x as fast	 2220.2ms +/- 0.3%	1208.5ms +/- 0.3%	  significant

===============================================================================

  v8:			 1.84x as fast	 2220.2ms +/- 0.3%	1208.5ms +/- 0.3%	  significant
	crypto:	   2.81x as fast	  395.3ms +/- 0.3%	 140.7ms +/- 0.4%	  significant
	deltablue:	2.70x as fast	  457.5ms +/- 1.1%	 169.4ms +/- 0.9%	  significant
	earley-boyer: 1.71x as fast	  254.6ms +/- 0.7%	 148.6ms +/- 0.6%	  significant
	raytrace:	 -				  137.0ms +/- 0.5%	 136.0ms +/- 1.5%  
	regexp:	   1.089x as fast	 349.1ms +/- 0.7%	 320.5ms +/- 0.3%	  significant
	richards:	 2.02x as fast	  432.3ms +/- 0.1%	 214.5ms +/- 0.4%	  significant
	splay:		2.47x as fast	  194.4ms +/- 0.5%	  78.7ms +/- 0.4%	  significant

My conclusions are:

1. V17 is generally faster and these are my own builds, so it can't simply be a problem of wrong build settings
   
2. The two test suites give very different results (1.21x compared to 1.84x) and in some of the tests v1.8.5 is faster. Taking into account that these are the same benchmarks the Mozilla guys use (and the engine is therefore specially optimized to produce good benchmark results), it seems to be possible that our code simply runs slower with version 17 because it does things that spidermonkey handles worse in the newer version.
   
3. I still don't know if there is an issue about how we are embedding Spidermonkey or if it's normal that v17 runs slower in our case.
   

EDIT:

New idea, new challenge.

Maybe I can isolate some parts of code that run slower and write a Sunspider test for it.

This way I could test it easily with newer versions of Spidermonkey and probably fill a bug for Spidermonkey if it's slower there too.

[Yves]

I looked a bit closer at the random map alpine_lakes to see where the speed difference comes from.

I figured out that there are about 2 seconds difference (in the configuration used for the tests posted on the previous page) in this loop.

After replacing the Math.random() in randInt with 0.777 Spidermonkey 17 became faster than 1.8.5 (the total time is now different from the previous test because the random number has a big impact and changes the generated map):

17
TIMER| Load RMS: 13.5352 s
TIMER| Load RMS: 13.7982 s
TIMER| Load RMS: 13.5488 s
TIMER| Load RMS: 13.6651 s
TIMER| Load RMS: 13.4973 s
TIMER| Load RMS: 13.4511 s

1.8.5
TIMER| LoadRMS: 14.1331 s
TIMER| LoadRMS: 13.7393 s
TIMER| LoadRMS: 13.7287 s
TIMER| LoadRMS: 13.768 s
TIMER| LoadRMS: 13.7408 s
TIMER| LoadRMS: 13.8551 s

The difference is small but I think it seems to be relevant (especially because 17 was slower before).

I suspect that JS_GetReservedSlot and JS_GetContextPrivate could be the problem. These are used from C++ to get a pointer to the network synchronized random number generator we use for replacing the default one (which is truely random and would break replays, and would generate different random maps with the same seed). The same functions for reserved slots are also used for many other functions to store pointers to objects. I'm going to test if I can prove a performance difference by writing a specific test for the JS_GetReservedSlot function.

[wraitii]

Interesting bottleneck you found here. And great work so far, it's been a very interesting read!

[sanderd17]

Just wondering,if it's a single player game, so randoms don't have to be synced, can't you use a native random function that's faster? And if you set a debug option, it could still switch to the deterministic random generator to warrant replays. It looks like a nice tradeoff. In single player, you have faster randoms, but the AI will always take a serious amout of cpu time, and in multiplayer, you have no AI slowdown, so a bit of margin for longer random creation.

[Yves]

The random numbers aren't really a problem I think. I've just picked that as an example to figure out in which situations Spidermonkey 17 is slower.

I'm picking the random map generation instead of the places where this really is a problem because it's easier to debug there. Hopefully it gives me some information that is useful in other cases too.

I've checked JS_GetContextPrivate using Valgrind in the meantime and it shows 0.00% of the execution time in 62 000 calls. If that's correct, it isn't the bottleneck.

[Yves]

I made another SunSpider benchmark with MethodJIT disabled.

It shows that Spidermonkey 17 is significantly slower (half as fast) as Spidermonkey 1.8.5 in this case.

I suspect that in the randInt method it falls back to interpreter mode because one argument of Math.floor is a random number that comes from C++ code and it's unknown for Spidermonkey what value this code will return and what type this value will have.

That's just a guess though, I don't know enough Spidermonkey internals yet to be sure.

The same problem could apply to other parts of code interacting with results returned from engine (C++) functions.

With TypeInference enabled for Spidermonkey 17.

TEST				   COMPARISON			   FROM				 TO			 DETAILS

===============================================================================

** TOTAL **:		   *1.97x as slow*   1475.5ms +/- 0.2%	2913.8ms +/- 1.0%	  significant

===============================================================================

  3d:				  *1.98x as slow*	209.1ms +/- 0.5%	 413.3ms +/- 0.9%	  significant
	cube:			  *1.56x as slow*	 78.0ms +/- 1.0%	 121.5ms +/- 0.6%	  significant
	morph:			 *2.40x as slow*	 60.6ms +/- 0.6%	 145.6ms +/- 2.0%	  significant
	raytrace:		  *2.07x as slow*	 70.5ms +/- 0.7%	 146.3ms +/- 0.8%	  significant

  access:			  *1.77x as slow*	345.4ms +/- 0.3%	 610.6ms +/- 1.4%	  significant
	binary-trees:	  *2.35x as slow*	 29.9ms +/- 0.3%	  70.4ms +/- 0.5%	  significant
	fannkuch:		  *1.61x as slow*	185.7ms +/- 0.4%	 299.1ms +/- 1.9%	  significant
	nbody:			 *2.04x as slow*	 76.0ms +/- 0.8%	 155.1ms +/- 1.1%	  significant
	nsieve:			*1.60x as slow*	 53.8ms +/- 1.4%	  86.0ms +/- 1.2%	  significant

  bitops:			  *2.14x as slow*	285.2ms +/- 0.6%	 609.8ms +/- 1.0%	  significant
	3bit-bits-in-byte: *1.39x as slow*	 48.2ms +/- 0.8%	  67.1ms +/- 2.7%	  significant
	bits-in-byte:	  *1.118x as slow*	81.7ms +/- 0.9%	  91.3ms +/- 1.5%	  significant
	bitwise-and:	   *4.69x as slow*	 70.0ms +/- 0.7%	 328.4ms +/- 0.6%	  significant
	nsieve-bits:	   *1.44x as slow*	 85.3ms +/- 1.6%	 122.9ms +/- 1.8%	  significant

  controlflow:		 *2.45x as slow*	 34.2ms +/- 0.5%	  83.9ms +/- 0.4%	  significant
	recursive:		 *2.45x as slow*	 34.2ms +/- 0.5%	  83.9ms +/- 0.4%	  significant

  crypto:			  *2.03x as slow*	124.5ms +/- 0.3%	 252.9ms +/- 0.8%	  significant
	aes:			   *2.19x as slow*	 51.3ms +/- 0.4%	 112.3ms +/- 0.7%	  significant
	md5:			   *2.01x as slow*	 35.2ms +/- 0.6%	  70.6ms +/- 1.0%	  significant
	sha1:			  *1.84x as slow*	 38.1ms +/- 0.4%	  70.0ms +/- 1.1%	  significant

  date:				*2.06x as slow*	 69.6ms +/- 0.5%	 143.2ms +/- 0.9%	  significant
	format-tofte:	  *2.04x as slow*	 42.6ms +/- 0.4%	  86.8ms +/- 0.5%	  significant
	format-xparb:	  *2.09x as slow*	 27.0ms +/- 1.1%	  56.4ms +/- 1.6%	  significant

  math:				*1.91x as slow*	217.9ms +/- 0.5%	 416.7ms +/- 1.1%	  significant
	cordic:			*1.66x as slow*	106.5ms +/- 0.9%	 177.1ms +/- 1.2%	  significant
	partial-sums:	  *2.31x as slow*	 64.9ms +/- 0.3%	 149.7ms +/- 1.6%	  significant
	spectral-norm:	 *1.93x as slow*	 46.5ms +/- 0.7%	  89.9ms +/- 1.1%	  significant

  regexp:			  *1.010x as slow*	18.3ms +/- 0.3%	  18.5ms +/- 0.2%	  significant
	dna:			   *1.010x as slow*	18.3ms +/- 0.3%	  18.5ms +/- 0.2%	  significant

  string:			  *2.13x as slow*	171.3ms +/- 0.4%	 364.9ms +/- 1.5%	  significant
	base64:			*2.56x as slow*	 31.6ms +/- 0.5%	  80.7ms +/- 1.3%	  significant
	fasta:			 *2.29x as slow*	 54.7ms +/- 1.0%	 125.2ms +/- 2.2%	  significant
	tagcloud:		  *1.72x as slow*	 33.7ms +/- 0.3%	  58.0ms +/- 0.9%	  significant
	unpack-code:	   *1.49x as slow*	 27.6ms +/- 0.5%	  41.0ms +/- 1.1%	  significant
	validate-input:	*2.53x as slow*	 23.7ms +/- 0.5%	  60.0ms +/- 1.3%	  significant

With TypeInference disabled for Spidermonkey 17:

TEST				   COMPARISON			   FROM				 TO			 DETAILS

===============================================================================

** TOTAL **:		   *1.46x as slow*   1475.5ms +/- 0.2%	2147.5ms +/- 0.2%	  significant

===============================================================================

  3d:				  *1.37x as slow*	209.1ms +/- 0.5%	 287.5ms +/- 0.3%	  significant
	cube:			  *1.191x as slow*	78.0ms +/- 1.0%	  92.9ms +/- 0.8%	  significant
	morph:			 *1.67x as slow*	 60.6ms +/- 0.6%	 101.4ms +/- 0.5%	  significant
	raytrace:		  *1.32x as slow*	 70.5ms +/- 0.7%	  93.2ms +/- 0.2%	  significant

  access:			  *1.33x as slow*	345.4ms +/- 0.3%	 460.3ms +/- 0.6%	  significant
	binary-trees:	  *2.24x as slow*	 29.9ms +/- 0.3%	  67.0ms +/- 0.7%	  significant
	fannkuch:		  *1.182x as slow*   185.7ms +/- 0.4%	 219.5ms +/- 0.9%	  significant
	nbody:			 *1.35x as slow*	 76.0ms +/- 0.8%	 102.6ms +/- 0.3%	  significant
	nsieve:			*1.32x as slow*	 53.8ms +/- 1.4%	  71.2ms +/- 1.3%	  significant

  bitops:			  *1.68x as slow*	285.2ms +/- 0.6%	 478.7ms +/- 0.4%	  significant
	3bit-bits-in-byte: *1.179x as slow*	48.2ms +/- 0.8%	  56.8ms +/- 0.7%	  significant
	bits-in-byte:	  *1.038x as slow*	81.7ms +/- 0.9%	  84.7ms +/- 0.8%	  significant
	bitwise-and:	   *3.49x as slow*	 70.0ms +/- 0.7%	 244.2ms +/- 0.6%	  significant
	nsieve-bits:	   *1.089x as slow*	85.3ms +/- 1.6%	  93.0ms +/- 0.6%	  significant

  controlflow:		 *1.60x as slow*	 34.2ms +/- 0.5%	  54.8ms +/- 1.1%	  significant
	recursive:		 *1.60x as slow*	 34.2ms +/- 0.5%	  54.8ms +/- 1.1%	  significant

  crypto:			  *1.36x as slow*	124.5ms +/- 0.3%	 169.0ms +/- 0.4%	  significant
	aes:			   *1.37x as slow*	 51.3ms +/- 0.4%	  70.5ms +/- 0.9%	  significant
	md5:			   *1.38x as slow*	 35.2ms +/- 0.6%	  48.6ms +/- 0.6%	  significant
	sha1:			  *1.31x as slow*	 38.1ms +/- 0.4%	  49.9ms +/- 0.5%	  significant

  date:				*1.38x as slow*	 69.6ms +/- 0.5%	  96.3ms +/- 0.8%	  significant
	format-tofte:	  *1.39x as slow*	 42.6ms +/- 0.4%	  59.2ms +/- 1.1%	  significant
	format-xparb:	  *1.37x as slow*	 27.0ms +/- 1.1%	  37.1ms +/- 0.7%	  significant

  math:				*1.46x as slow*	217.9ms +/- 0.5%	 318.3ms +/- 0.4%	  significant
	cordic:			*1.33x as slow*	106.5ms +/- 0.9%	 141.6ms +/- 0.5%	  significant
	partial-sums:	  *1.73x as slow*	 64.9ms +/- 0.3%	 112.3ms +/- 0.8%	  significant
	spectral-norm:	 *1.39x as slow*	 46.5ms +/- 0.7%	  64.5ms +/- 0.7%	  significant

  regexp:			  *1.009x as slow*	18.3ms +/- 0.3%	  18.4ms +/- 0.2%	  significant
	dna:			   *1.009x as slow*	18.3ms +/- 0.3%	  18.4ms +/- 0.2%	  significant

  string:			  *1.54x as slow*	171.3ms +/- 0.4%	 264.2ms +/- 0.3%	  significant
	base64:			*1.86x as slow*	 31.6ms +/- 0.5%	  58.6ms +/- 0.5%	  significant
	fasta:			 *1.63x as slow*	 54.7ms +/- 1.0%	  89.3ms +/- 0.6%	  significant
	tagcloud:		  *1.30x as slow*	 33.7ms +/- 0.3%	  43.8ms +/- 0.7%	  significant
	unpack-code:	   *1.187x as slow*	27.6ms +/- 0.5%	  32.8ms +/- 2.1%	  significant
	validate-input:	*1.67x as slow*	 23.7ms +/- 0.5%	  39.7ms +/- 0.5%	  significant

[scroogie]

Just out of curiosity, can't you compile some functions manually? In the examples, I found this: https://developer.mozilla.org/en-US/docs/SpiderMonkey/JSAPI_User_Guide#Compiled_scripts

[Yves]

Just out of curiosity, can't you compile some functions manually? In the examples, I found this: https://developer.mo...ompiled_scripts

Compiling means bytecode compilation in this context which is not the same as JIT-compiling. When I'm talking about interpreter-mode I mean executing bytecode compiled code instead of JIT-compiled code.

JIT-compiled code is further optimized. It can be JIT-compiled with JaegerMonkey or with IonMonkey which is available since V18 (so IonMonkey is not involved in the benchmarks posted in this thread because I'm using version 17).

JaegerMonkey has a relatively small overhead for compiling but the code is less well optimized than code JIT-compiled using IonMonkey. This confused me too in the beginning and I hope I could clear that up a bit...

I've asked if JIT-compilation can be done manually here.

The answer was that this is not possible but if you refer to the graph I posted here, you see that this is not really necessary because the compilation overhead is relatively small. I'm trying to figure out which parts of code are run in interpreter mode and why, but I need a few more hours for that.

[Yves]

Here are some JIT statistics generated using getPCCountScriptSummary.

I'm not yet sure what to do with it because I can only guess what these values mean (or dive deep into the Spidermonkey sourcecode).

{file:maps/random/rmgen/tileclass.js
line:33
name:RangeOp.get
totals:{mjit:632478063
mjit_calls:12801440
mjit_code:182814883720
mjit_pics:832092560
infer_poly:320608662
infer_nobarrier:54230321
observe_int32:279179765
observe_double:3024625
observe_object:38404272
id_unknown:12801424
elem_other:12801424
prop_other:28627473
arith_double:49034454
arith_unknown:142706585}}
{file:maps/random/rmgen/tileclass.js
line:86
name:TileClass.add
totals:{mjit:124019
mjit_calls:41
mjit_code:43368701
mjit_pics:654702
infer_poly:75051
infer_nobarrier:43713
observe_int32:40837
observe_double:15
observe_object:34199
id_unknown:26646
elem_other:26646
prop_other:18530
arith_double:4757
arith_unknown:9514}}
{file:maps/random/rmgen/tileclass.js
line:105
name:TileClass.countInRadius
totals:{mjit:228563040
mjit_calls:12144848
mjit_code:70984882285
mjit_pics:1028498109
infer_poly:128065770
infer_nobarrier:33462594
observe_boolean:99063
observe_int32:88520486
observe_double:6082690
observe_object:33363531
id_unknown:3024625
elem_other:3024625
prop_other:18293141
arith_double:12044536
arith_unknown:39664542}}
{file:maps/random/rmgen/tileclass.js
line:141
name:TileClass.countMembersInRadius
totals:{interp:20
mjit:594366
mjit_calls:4
mjit_code:209712137
mjit_pics:6934200
infer_poly:396244
infer_nobarrier:99061
observe_int32:296979
observe_double:204
observe_object:99061
prop_other:99061}}
{file:maps/random/rmgen/terrain.js
line:10
name:Terrain.place
totals:{mjit:57084
mjit_calls:16
mjit_code:22134321
mjit_pics:946577
infer_poly:42813
infer_nobarrier:23785
observe_undefined:4757
observe_int32:19012
observe_double:16
observe_object:19028
id_unknown:9514
elem_other:9514
prop_other:9514}}
{file:maps/random/rmgen/terrain.js
line:31
name:SimpleTerrain
totals:{mjit:540
mjit_calls:186
mjit_code:124860
mjit_pics:26060
infer_poly:240
infer_nobarrier:60
observe_undefined:120
observe_string:120
prop_other:120
arith_unknown:60}}
{file:maps/random/rmgen/terrain.js
line:44
name:SimpleTerrain.placeNew
totals:{mjit:71355
mjit_calls:4780
mjit_code:26429892
mjit_pics:1274806
infer_poly:47570
infer_nobarrier:38056
observe_undefined:9514
observe_int32:9506
observe_double:8
observe_string:4757
observe_object:23785
id_unknown:9514
elem_other:9514
prop_other:19028
arith_unknown:4757}}
{file:maps/random/rmgen/terrain.js
line:63
name:RandomTerrain
totals:{mjit:360
mjit_calls:39
mjit_code:84480
mjit_pics:8410
infer_poly:150
infer_nobarrier:60
observe_int32:30
observe_object:120
prop_other:60
arith_other:30
arith_unknown:30}}
{file:maps/random/rmgen/terrain.js
line:75
name:RandomTerrain.placeNew
totals:{mjit:52327
mjit_calls:12
mjit_code:21016426
mjit_pics:623101
infer_poly:38056
infer_nobarrier:28542
observe_int32:14263
observe_double:8
observe_object:23785
id_unknown:4757
elem_other:4757
prop_other:19028}}
{file:maps/random/rmgen/tileclass.js
line:24
name:RangeOp.add
totals:{mjit:472065
mjit_calls:22899
mjit_code:141313373
mjit_pics:1487720
infer_poly:234602
infer_nobarrier:94413
observe_int32:163077
observe_double:2861
observe_object:68664
id_unknown:45776
elem_other:45776
prop_other:48637
arith_double:71525
arith_unknown:45776}}
{file:maps/random/rmgen/point.js
line:8
name:PointXZ
totals:{mjit:659910
mjit_calls:131990
mjit_code:141132752
mjit_pics:17245392
infer_poly:263964
infer_nobarrier:87988
observe_undefined:87988
observe_int32:175822
observe_double:154
prop_other:87988
arith_unknown:87988}}
{file:maps/random/rmgen/random.js
line:12
name:getRnd
totals:{mjit:83300
mjit_calls:13
mjit_code:17297000
mjit_pics:3472600
infer_poly:29400
infer_nobarrier:29400
observe_int32:19600
observe_double:4900
observe_object:4900
id_unknown:4900
elem_other:4900
arith_double:19600
arith_unknown:4900}}
{file:maps/random/rmgen/random.js
line:27
name:randFloat
totals:{mjit:2075
mjit_calls:502
mjit_code:654123
mjit_pics:11039
infer_mono:166
infer_poly:1079
infer_nobarrier:581
observe_int32:664
observe_object:332
id_int:166
elem_other:166
prop_other:249
arith_double:249
arith_unknown:249}}
{file:maps/random/rmgen/random.js
line:76
name:randInt2
totals:{mjit:540
mjit_calls:4
mjit_code:139380
mjit_pics:7888
infer_poly:240
infer_nobarrier:60
observe_int32:180
observe_object:60
arith_double:60
arith_unknown:120}}
{file:maps/random/rmgen/random.js
line:81
name:randInt1
totals:{mjit:38536
mjit_calls:4825
mjit_code:11445192
mjit_pics:1280790
infer_poly:19268
infer_nobarrier:14451
observe_int32:4817
observe_object:14451
prop_other:4817
arith_unknown:4817}}
{file:maps/random/rmgen/painter.js
line:48
name:LayeredPainter
totals:{interp:217
mjit:504
mjit_calls:63
mjit_code:163181
mjit_pics:4996
infer_poly:283
infer_nobarrier:142
observe_int32:94
observe_object:189
id_unknown:24
elem_other:24
prop_other:106
arith_double:24
arith_other:11
arith_unknown:35}}
{file:maps/random/rmgen/painter.js
line:64
name:LayeredPainter.paint
totals:{mjit:3497292
mjit_calls:16927
mjit_code:1191853027
mjit_pics:21310902
infer_poly:2097009
infer_nobarrier:827715
observe_int32:1357019
observe_double:661
observe_object:739329
id_unknown:360592
elem_other:360592
prop_other:269744
arith_double:318488
arith_unknown:303693}}
{file:maps/random/rmgen/painter.js
line:160
name:MultiPainter
totals:{interp:75}}
{file:maps/random/rmgen/painter.js
line:165
name:MultiPainter.paint
totals:{interp:272
mjit:168
mjit_calls:12
mjit_code:61752
mjit_pics:2157
infer_poly:108
infer_nobarrier:68
observe_int32:44
observe_object:64
id_unknown:12
elem_other:12
prop_other:56
arith_double:12
arith_unknown:16}}
{file:maps/random/rmgen/painter.js
line:186
name:SmoothElevationPainter
totals:{interp:270}}
{file:maps/random/rmgen/painter.js
line:198
name:SmoothElevationPainter.checkInArea
totals:{interp:730
mjit:3821121
mjit_calls:458
mjit_code:1408901783
mjit_pics:47904276
infer_poly:2557606
infer_nobarrier:1395036
observe_int32:1394174
observe_double:862
observe_object:1162570
id_unknown:464932
elem_other:464932
prop_other:465052
arith_double:201590
arith_unknown:232466}}
{file:maps/random/rmgen/painter.js
line:209
name:SmoothElevationPainter.paint
totals:{interp:636
mjit:7913563
mjit_calls:29528
mjit_code:2517176030
mjit_pics:49818653
infer_poly:4390153
infer_nobarrier:1308756
observe_int32:2924550
observe_double:125999
observe_object:1339604
id_unknown:508945
elem_other:508945
prop_other:532862
arith_double:859623
arith_unknown:639107}}
{file:maps/random/rmgen/painter.js
line:400
name:TileClassPainter
totals:{interp:75}}
{file:maps/random/rmgen/painter.js
line:405
name:TileClassPainter.paint
totals:{interp:373
mjit:80671
mjit_calls:15
mjit_code:31342880
mjit_pics:331870
infer_poly:56939
infer_nobarrier:28466
observe_int32:23726
observe_double:5
observe_object:33208
id_unknown:4742
elem_other:4742
prop_other:23724
arith_double:4742
arith_unknown:4749}}
{file:maps/random/rmgen/pathplacer.js
line:19
name:PathPlacer
totals:{interp:675}}
{file:maps/random/rmgen/pathplacer.js
line:33
name:PathPlacer.place
totals:{interp:335
mjit:4872377
mjit_calls:124189
mjit_code:1690918961
mjit_pics:5191708
infer_poly:2956366
infer_nobarrier:976680
observe_undefined:7
observe_int32:1279541
observe_double:531451
observe_object:1145367
id_int:44094
id_unknown:83354
elem_other:127448
prop_other:802999
arith_double:209388
arith_unknown:1059239}}
{file:maps/random/rmgen/pathplacer.js
line:148
name:PathPlacer.place/tri<
totals:{interp:96
mjit:222000
mjit_calls:4
mjit_code:80364000
infer_poly:148000
infer_nobarrier:74000
observe_int32:73912
observe_double:88
observe_object:74000
prop_other:74000
arith_unknown:37000}}
{file:maps/random/rmgen/pathplacer.js
line:155
name:PathPlacer.place/fillLine
totals:{interp:706
mjit:4224619
mjit_calls:332048
mjit_code:1460123114
mjit_pics:53396917
infer_poly:2669182
infer_nobarrier:1329844
observe_int32:1215763
observe_double:222384
observe_object:1231035
id_unknown:188990
elem_other:188990
prop_other:516458
arith_double:112493
arith_unknown:278527}}
{file:maps/random/rmgen/map.js
line:218
name:Map.createArea
totals:{mjit:86197
mjit_calls:90
mjit_code:38149627
mjit_pics:10354
infer_poly:66903
infer_nobarrier:33413
observe_undefined:29
observe_int32:33326
observe_double:5
observe_object:33543
id_unknown:19028
elem_other:19028
prop_other:19075
arith_double:4765
arith_unknown:4818}}
{file:maps/random/rmgen/library.js
line:530
name:avoidClasses
totals:{interp:360
mjit:342
mjit_calls:82
mjit_code:114165
mjit_pics:1224
infer_mono:9
infer_poly:189
infer_nobarrier:81
observe_int32:99
observe_object:63
id_int:9
id_unknown:27
elem_other:36
prop_other:36
arith_double:72
arith_unknown:18}}
{file:maps/random/rmgen/map.js
line:83
name:Map.getTextureID
totals:{mjit:38080
mjit_calls:4781
mjit_code:13695126
mjit_pics:1693819
infer_poly:23803
infer_nobarrier:14277
observe_int32:4766
observe_string:9517
observe_object:9520
id_unknown:4760
elem_other:4760
prop_other:9523}}
{file:maps/random/rmgen/map.js
line:105
name:Map.validT
totals:{mjit:128466
mjit_calls:16483
mjit_code:37330902
mjit_pics:1110078
infer_poly:65880
infer_nobarrier:32940
observe_undefined:6588
observe_boolean:3294
observe_int32:32925
observe_double:15
observe_object:23058
prop_other:16470
arith_double:6588
arith_unknown:23058}}
{file:maps/random/rmgen/map.js
line:124
name:Map.inMapBounds
totals:{mjit:5833670
mjit_calls:4
mjit_code:1472817870
infer_poly:2499812
infer_nobarrier:833080
observe_int32:2498221
observe_double:1591
prop_other:833080
arith_double:833652
arith_unknown:833080}}
{file:maps/random/rmgen/map.js
line:130
name:Map.validH
totals:{interp:368
mjit:4337159
mjit_calls:5
mjit_code:1097266514
mjit_pics:18434800
infer_poly:1897448
infer_nobarrier:813174
observe_boolean:271100
observe_int32:1625691
observe_double:657
prop_other:542074
arith_double:542200
arith_unknown:542074}}
{file:maps/random/rmgen/map.js
line:143
name:Map.validClass
totals:{mjit:240
mjit_calls:3
mjit_code:69330
infer_poly:120
infer_nobarrier:60
observe_int32:90
observe_object:30
prop_other:60
arith_double:30
arith_unknown:30}}
{file:maps/random/rmgen/library.js
line:294
name:createTerrain
totals:{mjit:1770
mjit_calls:109
mjit_code:561780
mjit_pics:31204
infer_poly:990
infer_nobarrier:450
observe_int32:240
observe_string:180
observe_object:570
id_unknown:60
elem_other:60
prop_other:150
arith_double:60
arith_unknown:90}}
{file:maps/random/rmgen/library.js
line:313
name:createSimpleTerrain
totals:{mjit:840
mjit_calls:68
mjit_code:258420
mjit_pics:15428
infer_poly:480
infer_nobarrier:240
observe_int32:60
observe_string:240
observe_object:180
prop_other:120
arith_double:60}}
{file:maps/random/rmgen/library.js
line:360
name:getTileClass
totals:{mjit:330
mjit_calls:10
mjit_code:115770
mjit_pics:9918
infer_poly:210
infer_nobarrier:150
observe_int32:60
observe_object:150
id_unknown:30
elem_other:30
prop_other:60
arith_unknown:30}}
{file:maps/random/rmgen/library.js
line:371
name:createArea
totals:{interp:126
mjit:7
mjit_calls:3
mjit_code:2547
mjit_pics:68
infer_poly:5
infer_nobarrier:2
observe_object:5
prop_other:1}}
{file:maps/random/rmgen/library.js
line:381
name:getMapSize
totals:{interp:6
mjit:222
mjit_calls:3
mjit_code:76072
mjit_pics:5032
infer_poly:148
infer_nobarrier:148
observe_int32:74
observe_object:74
prop_other:74}}
{file:maps/random/rmgen/library.js
line:518
name:paintClass
totals:{interp:120}}
{file:maps/random/rmgen/library.js
line:39
name:scaleByMapSize
totals:{interp:208
mjit:480
mjit_calls:6
mjit_code:135520
mjit_pics:8512
infer_poly:224
infer_nobarrier:128
observe_int32:192
observe_object:32
arith_unknown:192}}
{file:maps/random/rmgen/constraint.js
line:86
name:AvoidTileClassConstraint
totals:{interp:168
mjit:7
mjit_calls:6
mjit_code:1611
mjit_pics:68
infer_poly:3
infer_nobarrier:1
observe_int32:2
observe_object:1
prop_other:2}}
{file:maps/random/rmgen/constraint.js
line:92
name:AvoidTileClassConstraint.allows
totals:{interp:26
mjit:792488
mjit_calls:8
mjit_code:280441691
mjit_pics:6934200
infer_poly:495305
infer_nobarrier:297183
observe_int32:296979
observe_double:204
observe_object:198122
prop_other:297183
arith_double:99061}}
{file:maps/random/alpine_lakes.js
line:0
totals:{mjit:1201
mjit_calls:223
mjit_code:282326
mjit_pics:56601
infer_poly:466
infer_nobarrier:466
observe_int32:195
observe_object:271
arith_double:90
arith_unknown:30}}
{file:maps/random/rmgen/area.js
line:10
name:Area
totals:{interp:112}}
{file:maps/random/rmgen/area.js
line:16
name:Area.getID
totals:{interp:42
mjit:4
mjit_calls:2
mjit_code:1162
infer_poly:2
infer_nobarrier:2
observe_int32:2
prop_other:2}}"

[Yves]

Please read to the end, there's an important decision to take and I need some feedback!

I've found this article which is about a new baseline JIT compiler being introduced in version 22 of Spidermonkey.

The baseline compiler has landed

Some interesting quotes from the article:

"If type information for a function changes, then any existing JITcode (both Jaeger’s and Ion’s) is thrown away, ... "

"Baseline jitcode never becomes invalid, and never requires recompilation. It tracks and reacts to dynamic changes, adding new stubs to its IC chains as necessary. "

I think this could be our biggest performance problem.

This output could mean that this function is recompiled with JaegerMonkey nearly 13 million times (while generating the random map Alpine Lakes with a size of 256 if I remember correctly)

mjit_calls:12'801'440

I've checked how often the function is called (44'811'319 times), so it would compile it and then run the compiled version 3.5 times in average and then already recompile it. That can't be good but I'm not sure if this interpretation is correct or if the number means something slightly (or completely) different.

Anyway I think the best decision is now to switch to v22 instead of esr17.

Some pros and cons:

+ If I upgrade to V17 now we have to upgrade to a newer version later, but we have to do it at some point. If I already make the changes for the newer API, some of the work is already done.

+ The performance problem of V17 seems to be an internal problem of Spidermonkey. If that's true,the only way to solve it is to upgrade to a newer version. Spending a lot of time on troubleshooting an old version is a waste of time. Especially if it's likely that the main problem is solved in a newer version.

+ Even if this doesn't bring a huge improvement it should be faster because newer versions are always faster... erm...

+ Hopefully the Mozilla guys will be more interested in helping with performance issues if we use the current version instead of an old one.

+ Adding something that was mainly meant to be a performance improvement and actually making the game slower feels bad and demotivating.

- Linux distributions won't like us because they have to bundle v22 with the game. V17 is officially released by Mozilla as a standalone version and most distributions will package that anyway. On the other hand 0 A.D. is an alpha version and we shouldn't yet worry too much about release packaging.

- It's bleeding edge and probably buggier than v17.

- The whole upgrade takes longer. V17 brings some improvements even if the performance is worse

- We don't really support the efforts put into releasing a standalone Spidermonkey vesion (esr17)

Any comment on that? Do you guys think that's the right decision?

[historic_bruno]

Any comment on that? Do you guys think that's the right decision?

If we're going to upgrade SM in the first place, we need a justification. If there's no performance benefit, no GC benefit, why should we take the trouble of upgrading and losing compatibility with the 1.8.5 packages out there? So I'm fine with looking for a version that offers one or more significant benefits, I think it's worth investigating. Can you also summarize the non-performance improvements we would get from V17+?

[wraitii]

I'd agree with historic Bruno. If it seems like we can't really get more out of v17, then we should not upgrade at all. But if we can get more from v22, then it's interesting, even of right now potentially buggy. At the very least, your work wouldn't be most and could serve a a framework for a future upgrade once it's stable

[Yves]

Can you also summarize the non-performance improvements we would get from V17+?

• I think the main benefit is that it should make it easier for us to implement multi-threading support for the AI. I've tried it with 1.8.5 but there were a lot random crashes in Spidermonkey I couldn't find a reason for. V17 forces you to be more careful with compartments and triggers assertions earlier if something's wrong instead of crashing later. I've also red something about improved threading support, but I don't know exactly what was improved.
  
• Basic lifecycle. I don't know how long distributions will keep the 1.8.5 packages. But that's a weak argument if we force them to use a non-standard version instead.
  
• If we find a problem that can't be solved with 1.8.5 (localization maybe or whatever) then we also have to upgrade
  
• The strict-mode validation of js code is better. It gave hundreds of errors and warnings when I first ran it. Many of these warnings pointed to potentially buggy or ambiguous code that could be avoided in the future.
  

Granted, the main reason was/is performance.

At the very least, your work wouldn't be most and could serve a a framework for a future upgrade once it's stable

It looks like they plan to release the next bundled Spidermonkey version with esr24 this autumn/winter.

[Yves]

This output could mean that this function is recompiled with JaegerMonkey nearly 13 million times (while generating the random map Alpine Lakes with a size of 256 if I remember correctly)

mjit_calls:12'801'440

I've checked how often the function is called (44'811'319 times), so it would compile it and then run the compiled version 3.5 times in average and then already recompile it. That can't be good but I'm not sure if this interpretation is correct or if the number means something slightly (or completely) different.

I've met bhackett (the guy who wrote large parts of JIT Inspector) on the #jsapi channel. My interpretation was wrong.

bhackett

Yves: it means the jitcode either called another jit compiled function, or made a VM call into C++ to perform an operation rather than being able to do it in jitcode

bhackett

Yves: programs with a lot of mjit_calls will not perform very well

Another guy called h4writer pointed me to this release schedule: https://wiki.mozilla...elease/Calendar

He suggested aiming for esr24 which will be the next stable release and should be released on the 17th of September.

I think that makes sense

[wraitii]

I think that's a fair aim. If there is any indication that esr24 will not be too different from v22, I say go for it. Multithreading and stricter compiling are two very good points imo.

[tuan kuranes]

The strict-mode validation of js code is better. It gave hundreds of errors and warnings when I first ran it. Many of these warnings pointed to potentially buggy or ambiguous code that could be avoided in the future.

That adds other good point for upgrading:

- latest sm version will support sourcemaps (allows eaiser use of js "flavors" or any other language that can be transpiled to js)

- asm.js support in future sm release (which means real faster typed vars)

Both point, plus the current "c++ like" orientation of current js code could leads to either easier js code production, using transpilers like lljs (would recommend that, because it can transpile to asm.js, and handle memory C like in a very efficient way and is very strict), or just directly asm.js (but that have to wait for sm upgrade to asm.js supported version).

On a side note, current js code could benefits for addition/usage of js code quality tools. (jsvalidate, jshint, qunit, plato, benchmarkjs, etc.). Some nice things can be done/automated using gruntjs (like setting a "grunt watch" task which run in background and lint against any js tools any changes while you edit js files)

(from a few js code reading, there's lot of room for js optimisation)

Edited June 1, 2013 by tuan kuranes

[fabio]

Mozilla plans to release mozjs24 snapshot this month:

https://bugzilla.moz...i?id=735599#c57

When 24 moves from Nightly to Aurora (around June 24), I'll work on putting out

a version. This obviously cannot be considered a release candidate, but the API

should be stable between Aurora and release, and I'll track any major changes.

Release candidates can start appearing after 24 is out of beta, around late

September.

[Yves]

Thanks, that's good to know.

At the moment I'm just building it inside the Firefox source tree because I haven't yet figured out which directories and files it exactly needs.

[fabio]

The scripts used for extracting mozjs17 from FF is here:

https://github.com/sstangl/js-packaging

package.sh lists the needed directory, maybe it still applies for 24 also (the patches may break).

[stwf]

ok, I checked my fixes for this upgrade into main trunk. It just makes things so much easier. I did incorporate the suggestions you made on the first batch.