Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > * Jim Meyering wrote on Fri, Jun 13, 2008 at 10:17:36AM CEST: >> Ralf Wildenhues <[EMAIL PROTECTED]> wrote: >> > Just ordering the build of some huge objects in GCC allowed to shave 30% >> > build time off a parallel build: >> >> Yes, I did the same with coreutils/tests, and it made a big difference, >> since there were some long-running tests near the end of the initial list. >> Here it was the first thing I tried, once parallelized. However, in >> this case it gave less than 1 second decrease. No big surprise, though, >> since even removing the top 4-5 longest-running tests shaves only ~8 >> seconds off the total (~11s) run time, now that they're run in parallel. > > IIRC most of the coreutils tests are pretty I/O bound. Running them in > parallel won't help much, with all of them competing for the same kernel > resp. disk resources. I guess the proposed parallel Autotest patches > are thus limited, too. I found testing them on tmpfs (/dev/shm) to show > much more favorable speedup than disk or NFS. You probably may want to > ensure to have a recent kernel, too (although I have no idea whether > there were significant improvements in in-kernel parallelism recently).
I've been talking about two groups of tests: coreutils/tests (300+, they've been parallelized for a couple months, takes ~75s), and those that coreutils automatically pulls in from gnulib, coreutils/gnulib-tests, and for which "make check" (in that subdirectory) takes only 11s on a fast dual-core system. Not worth any more tuning, there, imho ;-) FYI, I'm using a range of kernels, but always test at least on the latest ones from rawhide, one of which is currently 2.6.25.4-30.fc9.x86_64.
