gasche
commented
2 weeks ago (Of course your review of #12579 is also very nice and possibly even more impactful, thanks!)
Closed damiendoligez closed 2 weeks ago
gasche
commented
2 weeks ago (Of course your review of #12579 is also very nice and possibly even more impactful, thanks!)
INRIA CI is failing for Mac M1 because of
tests/parallel/domain_parallel_spawn_burn_gc_set.ml. I'll explain why by looking at a very similar test that is more convenient to study because it takes less time to run.Timings for
tests/parallel/domain_parallel_spawn_burn.ml:(trunk is at commit eabbb4002a0dabdbcf708f52a1db1d7a11618119)
As you can see, #12579 is a big improvement for this test. The improvement comes from commit 2992d123f7e76252355bb299de670a82911cfcdf which implements some fairness in the runtime.
The problem is that the test assumes fairness in the scheduler, which is not guaranteed by the language. The amount of work done by the test varies according to the decisions made by the scheduler, which explains the wide variations in timings.
To show this, I modified the program to print out the number of times it has requested minor and major GCs.
minor loops / major loops :
Note that these numbers are subject to large random variations.
The test is composed of two parts, one that does a bounded amount of work (allocations and spawning/joining threads) and the other does an unbounded amount of work (allocations and calling
Gc.set) and stops when the first one is finished.To solve this problem I propose to run both parts with no bounds, and stop everything after 3 seconds. This way we don't waste our time waiting for tests to run for a random number of minutes.
The following tests all have the same problem and are fixed by this PR:
tests/parallel/domain_parallel_spawn_burn.mltests/parallel/domain_parallel_spawn_burn_gc_set.mltests/parallel/domain_serial_spawn_burn.ml