we found that the Variable $NUM_CPU_JOBS is calculated as cpu_core_count() + 1 in pts-functions_system_cpu.php. In our opinion this doesn't make much sense. Basically it should either be userconfigurable for each test or set to cpu_core_count() * x
For compiling-Benchmarks like Built-linux-kernel x=2 is practicable. Why? Look at the following values:
Our work while composing kcbench (which does basically the same) showed, that compiling with less jobs than twice the number of cores doesn't keep the Cores busy, because there happens lot of I/O-Stuff when starting the compilation of a new file. In the example above the CPU-utilization for
9 Jobs hardly hits 80%.
Last edited by mephisto42; 06-11-2008 at 12:40 PM.
I'll look at it again and see what should be done about it. That policy of total cores plus one was established back by us when there were all single, single with Hyper-Threading, or dual core systems, so it normally would be double. Since then that policy hasn't been re-evaluated. This probably won't be changed in a 1.0.x point release but will be held off until 1.2. Thanks for pointing this out.
The number of threads is application dependant. A lot of variables like disk access, memory latency, cache coherence, etc. can change the optimal number of threads / cpu.
I think that scaling information is more relevant in a multi cpu environment. It tells more about the software / hardware tested than a single run of a program with a certain amount of thread / fork / mpi calls.
As most of actual PCs now have at least two CPU-cores, Quad-Core-CPUs are becomming popular and CPUs with virtually 8 Cores (Nehalem with hyperthreading) are not far away (Q4/08) I think Multi-CPU/-core tests become important for everyone.
I agree, that the number of forked instances ist application dependant, so I would suggest to move the Declaration of $NUM_CPU_JOBS into the individual test-config. At the moment the compiling-tests don't give meaningfull results. Maybe that is also th case with different tests.