At least, this version is out. As I said previously, this version is mainly about simplifying the internals of SimGrid to prepare for future, more user-visible change.
We gain about 5% on speed on the way, which is not bad actually. Here are some more detailed values obtained on linux/amd64/context (the bob host). That's the good old master/slaves example, with 1000 slaves (since we know that the amount of slaves do not impact the performance anymore):
| tasks | v3.3.2 | v3.3.1 | speedup |
|---|---|---|---|
| 100 | 0.097 | 0.137 | 29.27% |
| 500 | 0.107 | 0.160 | 33.33% |
| 1000 | 0.127 | 0.167 | 24.00% |
| 5000 | 0.237 | 0.293 | 19.32% |
| 10000 | 0.403 | 0.457 | 11.68% |
| 50000 | 1.570 | 1.687 | 6.92% |
| 100000 | 3.033 | 3.223 | 5.89% |
| 500000 | 14.860 | 15.793 | 5.91% |
| 1000000 | 29.620 | 31.367 | 5.57% |
| 5000000 | 147.880 | 156.780 | 5.68% |
That's not quite as much as we (Cristian and me) would have expected given the amount of simplification we did in the code, but that's not bad afterall. 5-6% speed gain by just doing software level optimization is even good, given the amount of optimizations that this code already received.
As for the future, Pedro and Bruno are already almost done with the partial update feature, so there may well be another release before the end of the week. They just have to merge their code into the main branch, run the portability tests, and that should be it. This should give a huge speedup, and not only thanks to software engineering this time. The idea is that each time we ask the simulation kernel for the next event to occure, it recomputes a quite large max-min system, even if only some parts changed. After this change, this won't be true anymore. With that, you can get arbitrary large speedups on some scenarios. When simulating desktop grid applications for example, every CPU is independent and there is almost no network simulation cost (because of the simplicity of the network you want to simulate).