wanted: run regression tests in parallel

[Roman Marynchak]

Change the testing infrastructure to support running tests in parallel. Most test files are independent, so it is possible to launch three (or two, or four) SBCL processes, each working on it's own portion. In case people have quad or even six-core CPUs, it will speed up the development/testing cycle. The high-level interface should be something like this:

sh run-tests.sh -threads 4

[Josh Elsasser (josh-elsasser)]

If this is supported then the user shouldn't have to specify a number, it should be automatic based on the number of CPUs. Something like sysctl -n hw.ncpu on a BSD system or cat /proc/whatever on Linux will give you a useful number.

[Roman Marynchak (roman-marynchak)]

This is still in progress (not ready to commit), but here is some early working model.

Current notes:

1) run-tests.sh is damaged for the time measurement's sake.
2) the number of additional threads should be CPUCORES - 1, because the main thread runs pure tests too. To adjust this number, code it in run-tests.sh or change the default in run-tests.lisp (yes, this is ugly, but let us finish the main functionality first).
3) TODO: synchronize the failures reporting.
4) maybe get rid of TAGBODY+GO.
5) rename threads.impure.lisp to be all-threads.impure.lisp.

Running it: sh run-tests.sh --parallel

More notes and reviews are welcome. The purpose of this diff is to let the other people to try it and measure the performance. Once I finish with TODO and FIXME, there will be the final patch.

[Paul F. Dietz (paul-f-dietz)]

I'll also suggest making it possible to run the regression tests repeatedly, in random order. This can show up state-dependent bugs.

[Douglas Katzman (dougk)]

I wasn't aware of this bug at the time I wrote the parallel-exec.sh script but it's pretty much working. To me it seemed preferable grafting more features onto run-tests.sh
parallel-exec also has the ability to pound on a single test file using N different processes.