Yves

Historic_bruno expresses exactly what I was thinking. Your explanation of the problem makes sense but I haven't seen any benchmarks yet that show how much effect memory fragmentation has on performance for 0 A.D. Do you see any possibilities how this could be measured before implementing complex changes? It's similar to the problem I had with Spidermonkey. There are a lot of benchmarks showing how much the browser performance was improved but there's no way to tell in advance how much it will improve performance for 0 A.D. and if it's worth the efforts. EDIT: I'll definitely test Spidermonkey's jemalloc flag

Awesome song and even better lyrics. What he sings not only applies to the music industry but also to the game industry. Hopefully nobody will ever "strip away personality" and "wash off the mark that wasis unique" from 0 A.D. Lyrics

@fabio Thanks for updating the GamePerformance wiki page. I didn't know they already have a page for Spidermonkey24. I found a good description of the issues with changed integer types and conflicts with our typedefs/defines there. http://whereswalden....mes-to-mozilla/ Thanks.

That would be awesome. I think it would be our first animal that can walk on land and swim in water. Is that even possible at the moment? I think we don't have a sophisticated animal AI yet. I also like how crocodiles tend to sit on a stone for hours without moving a bit and looking just like the stone while they are such an agile predator in the water (or if a prey moves too close).

Very interesting and well written article!

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.

I think it's the "bigscreenshot" which should be Shift+F2 by default. hotkey.screenshot = F2 ; Take PNG screenshot hotkey.bigscreenshot = "Shift+F2" ; Take large BMP screenshot

Nice video! I think a commented multiplayer match would be even more ineresting and would show how playable the game already is. Playing against AI works somehow but is still far away from being as fun as multiplayer games. In many let's play videos I've seen people wondering if the multiplayer even works or assuming it can't work because it's an alpha. There are also some weird (and obviously wrong) statements that the multiplayer is limited to 1vs1 or similar nonsense.

I've met bhackett (the guy who wrote large parts of JIT Inspector) on the #jsapi channel. My interpretation was wrong. 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

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. It looks like they plan to release the next bundled Spidermonkey version with esr24 this autumn/winter.

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: 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?

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).

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.

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. With TypeInference disabled for Spidermonkey 17:

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.

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.

I've compared v1.8.5 and v17 using sunspider. How I did the tests (also the same for the sunspider-1.0 suite): The results of the sunspider-1.0 benchmark: And the v8-v6 benchmark: My conclusions are: V17 is generally faster and these are my own builds, so it can't simply be a problem of wrong build settings 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. 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.

All kind of behaviour that isn't visible/audible for the player is bad design IMO. If the archers start shooting straight up into the air to hit targets behind walls/buildings and if that's a clearly visible difference then it shouldn't be a problem.

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. Yes the docs are a problem but I've already used APIs that were a lot worse in that regard. 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.

Record a video please!

I've tested those options that look suspicious and I don't think that I've missed an important one, but It's still possible because there are quite a lot options and I don't completely understand the meaning of every option.

I have another idea what I could try. I'm going to write a simple example program that uses Spidermonkey and executes a simple script with a large loop or something. Then I'm going to test this with both 1.85 and 17. That should narrow the problem down. Either we can see a performance boost for v17 there and I can start figuring out where the difference is or the situation is the same, which would mean that the problem must be very closely related to Spidermonkey and there's no need to look at the details about how our code uses Spidermonkey.

Non-Visual replay with qbot: ./pyrogenesis -quickstart -autostart="Oasis 04" -autostart-ai=1:qbot -autostart-ai=2:qbot -autostart-ai=3:qbot -autostart-ai=4:qbot Random map generation: ./pyrogenesis -autostart=alpine_lakes -autostart-random=123 -autostart-size=256 Spidermonkey 1.85 (3 runs) TIMER| LoadRMS: 35.2256 s TIMER| LoadRMS: 35.5012 s TIMER| LoadRMS: 35.4555 s Spidermonkey 17: (3 runs) TIMER| Load RMS: 36.8751 s TIMER| Load RMS: 37.1415 s TIMER| Load RMS: 36.8051 s ... I start considering that it really simply is slower Maybe I should just try V18.

I haven't found the problem yet. First I thought it could be caused by JIT code being thrown away by the garbage collector and then being regenerated over and over again. I found a switch that apparently turns off gargabe collection of JITed code completely. It increased performance a bit, but that's barely visible on the graph (total_keepjit/bright blue). Another Idea I had was that the wrapper values for sharedAI and gamestate passed to the AI cause overhead each time they are accessed. The new Spidermonkey doesn't support multiple global objects per compartment or per runtime anymore, so the gamestate and the sharedAI object can't be passed directly to each AIPlayer as we did with 1.85. This means we have to pass wrapper objects that allow them to be accessed through compartment boundaries. For testing I changed the code to copy the gamestate to each AIPlayer's compartment at the beginning of the AI computations. My theory was that this would cause overhead at the beginning of the simulation turn but If the wrapper acces made a significant difference, it should speed up those turns that contain a lot of wrapper access and therefore the pieks on graph should become smaller. As you can see (total_copy_state/red) the performance decrease is relatively even accross all turns. My conclusion is that wrapping doesn't have a significant impact on performance. I also tested how fast it is with methodJIT completely disabled (total_nojit/yellow). If you compare it to the previous graph (total_new/green), you see that methodJIT improves the overall simulation performance by about 20-35% in this case (I just picked 3 points in the graph). This at least proves that JS execution performance can make a difference and motivates me to try V18 with IonMonkey. I also played a bit with valgrind but didn't really come to a conclusion there. The next test will be with qbot because it doesn't use the shared API and therefore needs less compartment switching/wrapping. Yes you can copy it to the wiki if you want. There's already an outdated profiling wiki page. Thanks for the hint. For the moment I focus on my changes that could have caused the measurable performance difference. Most of what I changed is in the GUI where it doesn't affect the graph I posted and I didn't touch the simulation. But that's something I will also check when this problem is solved. A guy on the Mozilla #jsapi channel posted this recently: https://gist.github....idereit/5616961 He also describes some situations where moving code to JS actually improves performance. The only way to figure it out is probably testing.