Bug in time cmd?

Bug in time cmd?

[Trevor Higgins]

Doing some timing tests with mk I got these sort of figures?

14.28u  6.14s 5.92r

 From my *nix understanding the 'u' time is way off. Actual elapsed time 
was approx 6seconds.


-- 
We need another plan

Re: [9front] Bug in time cmd?

[Ethan Gardener]

On Tue, Mar 10, 2020, at 11:39 PM, Trevor Higgins wrote:
> Doing some timing tests with mk I got these sort of figures?
> 
> 14.28u  6.14s 5.92r
> 
>  From my *nix understanding the 'u' time is way off. Actual elapsed time 
> was approx 6seconds.

Haha! I wonder, could it be counting CPU time per core?

Re: [9front] Bug in time cmd?

[Alex Musolino]

These figures come from the Waitmsg structure returned by wait(2).  The
'u' time is the total user time of the child process *and descendants*.
Given that you likely have a multiprocessor and mk will parallelise its
work according to the NPROC environemnt variable, that ought to explain
how you are able to achieve 14s of user time in only 6s real time.

Re: [9front] Bug in time cmd?

[Trevor Higgins]

On 03/11/2020 01:11 PM, Alex Musolino wrote:

> These figures come from the Waitmsg structure returned by wait(2).  The
> 'u' time is the total user time of the child process *and descendants*.
> Given that you likely have a multiprocessor and mk will parallelise its
> work according to the NPROC environemnt variable, that ought to explain
> how you are able to achieve 14s of user time in only 6s real time.
Ok, setting NROC=1 verifies the result I am seeing.
While I understand the info, I have to think what this actually means as 
a measurement.
I guess it is telling me that 16 threads only makes a 2x speed 
improvement. Which seems to correlate
with the fact that the load on the CPU never gets very high. Utilization 
is poor.

Thanks for setting me straight.

-- 
We need another plan

Re: [9front] Bug in time cmd?

[ori]

> On 03/11/2020 01:11 PM, Alex Musolino wrote:
> 
>> These figures come from the Waitmsg structure returned by wait(2).  The
>> 'u' time is the total user time of the child process *and descendants*.
>> Given that you likely have a multiprocessor and mk will parallelise its
>> work according to the NPROC environemnt variable, that ought to explain
>> how you are able to achieve 14s of user time in only 6s real time.
> Ok, setting NROC=1 verifies the result I am seeing.
> While I understand the info, I have to think what this actually means as 
> a measurement.
> I guess it is telling me that 16 threads only makes a 2x speed 
> improvement. Which seems to correlate
> with the fact that the load on the CPU never gets very high. Utilization 
> is poor.
> 

out of curiosity, are you running on a machine with 16 physical cores?

Re: [9front] Bug in time cmd?

[Trevor Higgins]

On 03/11/2020 03:33 PM, ori@eigenstate.org wrote:
>> On 03/11/2020 01:11 PM, Alex Musolino wrote:
>>
>>> These figures come from the Waitmsg structure returned by wait(2).  The
>>> 'u' time is the total user time of the child process *and descendants*.
>>> Given that you likely have a multiprocessor and mk will parallelise its
>>> work according to the NPROC environemnt variable, that ought to explain
>>> how you are able to achieve 14s of user time in only 6s real time.
>> Ok, setting NROC=1 verifies the result I am seeing.
>> While I understand the info, I have to think what this actually means as
>> a measurement.
>> I guess it is telling me that 16 threads only makes a 2x speed
>> improvement. Which seems to correlate
>> with the fact that the load on the CPU never gets very high. Utilization
>> is poor.
>>
> out of curiosity, are you running on a machine with 16 physical cores?
>
Only across two cpus. I only have one cpu running plan9. So it is 8cores 
16 threads. How you count cores  I stopped trying to figure out long 
ago. Even assuming threads added no time saving, then 8 -> 2 is still 
poor utilization. Under Linux , core threads make a measurable 
difference to performance.



-- 
We need another plan

Re: [9front] Bug in time cmd?

[ori]

> Only across two cpus. I only have one cpu running plan9. So it is 8cores 
> 16 threads. How you count cores  I stopped trying to figure out long 
> ago. Even assuming threads added no time saving, then 8 -> 2 is still 
> poor utilization. Under Linux , core threads make a measurable 
> difference to performance.

Sure. It's not surprising that there's room for improvement,
though only a 2x speedup on a 8 core/16 thread machine is
mildly surprising.

You said you were using ramfs. Ramfs is dead simple, mostly
for private/scratch storage, not for performance. The kernel
itself likely has some highly contendend locks, like malloc
and runqueue locks.