The test suite (aeneas test or test/all.bash) is mostly serial. That makes little use of the many cores available today. It could be made faster by introducing parallelism at several different granularities.
Each test suite, e.g. test/core is run in serial with other test suites.
Within a test suite, each step, e.g. "compile tests to target X", is serial.
Within each step, all files in a suite are processed sequentially.
Each of these steps could benefit from parallelism, potentially. The only conceptual blocker has been organizing the test output of multiple running suites and making sure the runner is robust to crashes and hangs by any of the test steps.
For (3) I recently added batching because some suites like test/gc need to compile hundreds of tests, but each of them needs the runtime. Compiling them all in one v3c invocation typically runs out of memory, and running each individually is too slow when running on the JVM due to its abysmal startup. So the solution was to batch them into groups of 100 or so. Batching them also introduces the possibility to run batches in parallel.
I'd welcome any help in parallelizing the suite. I'd prefer to keep it shell scripts (rather than moving to Python), and adding utilities in C or Virgil (e.g. to manage many forked processes).
The test suite (
aeneas testortest/all.bash) is mostly serial. That makes little use of the many cores available today. It could be made faster by introducing parallelism at several different granularities.test/coreis run in serial with other test suites.Each of these steps could benefit from parallelism, potentially. The only conceptual blocker has been organizing the test output of multiple running suites and making sure the runner is robust to crashes and hangs by any of the test steps.
For (3) I recently added batching because some suites like
test/gcneed to compile hundreds of tests, but each of them needs the runtime. Compiling them all in onev3cinvocation typically runs out of memory, and running each individually is too slow when running on the JVM due to its abysmal startup. So the solution was to batch them into groups of 100 or so. Batching them also introduces the possibility to run batches in parallel.I'd welcome any help in parallelizing the suite. I'd prefer to keep it shell scripts (rather than moving to Python), and adding utilities in C or Virgil (e.g. to manage many forked processes).