From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mimir.eigenstate.org ([206.124.132.107]) by ewsd; Tue Mar 10 22:33:41 EDT 2020
Received: from stockyard.bk.recurse-network.net (gateway.bk.recurse-network.net [185.230.222.2])
	by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id 3e3c5b61 (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO);
	Tue, 10 Mar 2020 19:33:33 -0700 (PDT)
Message-ID: <218E628908F4F406572E19D8F6D873AA@eigenstate.org>
To: plan9fullfrontal@qs.co.nz, 9front@9front.org
Subject: Re: [9front] Bug in time cmd?
Date: Tue, 10 Mar 2020 19:33:30 -0700
From: ori@eigenstate.org
In-Reply-To: <e1a905b2-fc9a-7666-e380-fbe4f875d4b1@qs.co.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: converged SVG over AJAX cache software 

> 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?