Prior to this commit, the timers for counting elapsed time and CPU usage
were begun when a job's first output appears. For jobs that write only
to stdout, this will typically mean after a block of output is filled.
This can yield inaccurate results. The worst case is if there is heavy
computation at the beginning of the test being run, before any output is
done.
This commit changes so that the timers are started soon after the job is
created.
As an example of the detrimental effect these inaccurate results could
have is that I found this bug as a result of figuring out why the core
perl test suite was not behaving as expected when changing things around
to increase parallel CPU utilization. The scheduling algorithm depended
on these results; and since they were wrong, it scheduled things
inefficiently.
This commit, and another to the perl core that takes advantage of this
one, shave 5% to 10% off the time the perl core test suite takes to run.
On slow many-core systems, it is can be 20%. I also tested this on a
slow single core system, running two parallel jobs. The savings were 3%
from this commit alone, but that added up to 3 minutes.
Can you update this so that it doesn't change the version of every file? (I'll do that in a separate commit, and probably a different version because I'll do a development release).
Prior to this commit, the timers for counting elapsed time and CPU usage were begun when a job's first output appears. For jobs that write only to stdout, this will typically mean after a block of output is filled. This can yield inaccurate results. The worst case is if there is heavy computation at the beginning of the test being run, before any output is done.
This commit changes so that the timers are started soon after the job is created.
As an example of the detrimental effect these inaccurate results could have is that I found this bug as a result of figuring out why the core perl test suite was not behaving as expected when changing things around to increase parallel CPU utilization. The scheduling algorithm depended on these results; and since they were wrong, it scheduled things inefficiently.
This commit, and another to the perl core that takes advantage of this one, shave 5% to 10% off the time the perl core test suite takes to run. On slow many-core systems, it is can be 20%. I also tested this on a slow single core system, running two parallel jobs. The savings were 3% from this commit alone, but that added up to 3 minutes.