CT Test Results

    3 files    143 suites   55m 27s ⏱️
1 583 tests 1 533 ✅ 50 💤 0 ❌
2 682 runs  2 610 ✅ 72 💤 0 ❌

Results for commit 7e66483.

♻️ This comment has been updated with latest results.

To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass.

See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally.

Artifacts

• Complete CT logs (Download Logs)
• HTML Documentation (Download HTML Docs)
• Windows Installer

// Erlang/OTP Github Action Bot

Rebased onto OTP-23.3.4 + 184634a which is mergeable to all newer release branches.

Also tweaked solution with a global atomic to get some "randomness".

The sample I attached to #8208 (and now it is actually attached!) includes a rudimentary benchmark. There's a lot of variance in the results but they seem to consistently be a few % slower with Sverker's tweak. And in that simple test there is also no contention for the new atomic which I imagine would further degrade performance.
So how important is that "randomness"?

What if you change erts_sched_local_random_nosched_state to an Uint and just do

rand_state = erts_sched_local_random_nosched_state++;

If something like this was what you had in mind then it was about the same.

Given that the random number is used to pick a random pivot element in quicksort, performance is expected to vary as a result of this change, and the consistently worse performance might just be bad luck (or rather, very good luck with the original implementation always returning a good constant).