From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from kate-mail.whsl206.com ([49.50.249.113]) by ewsd; Wed Mar 11 00:15:59 EDT 2020 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qs.co.nz; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=JYcCF1D51oCFOLEIWH8mTpDoOkm5KMQuX8TFMWKF7rc=; b=ajYaMLhJHmECssAM8jcJClVta0 WVBCr6H+WJdELcFV9+8ndk7df+FdNxDwtxN4QCKvgioHJ1ZCX8Pgtk1y2t7Bhswaf4DoeGLszoGNc Ln/YtGus4zbhPMj4p1soXV6eboHx9NEWC0SV1OgSrKiR5WBmIYlK4hAcLJ3F5a1FdfvUzuj/V6e+t YQojDry50V1RHsdAJjPeUDN1lhDW82qcOH4um86zPFORy69Qhoe31bqceVBLyX2o5Jrih/7cSsALY zT7DpLvazBoL9a2K2XY08E3D3+w6TemdHtO8Sp27c5zlyIZw0o5hiflqNggN8ECQCi0WUQhIFsNC2 5gj+mAcw==; Received: from [118.149.145.145] (port=1958 helo=[192.168.43.110]) by kate.whsl206.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1jBslu-003afX-9L for 9front@9front.org; Wed, 11 Mar 2020 17:15:06 +1300 Subject: Re: [9front] Bug in time cmd? To: 9front@9front.org References: <218E628908F4F406572E19D8F6D873AA@eigenstate.org> From: Trevor Higgins Message-ID: Date: Wed, 11 Mar 2020 17:15:02 +1300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <218E628908F4F406572E19D8F6D873AA@eigenstate.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - kate.whsl206.com X-AntiAbuse: Original Domain - 9front.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - qs.co.nz X-Get-Message-Sender-Via: kate.whsl206.com: authenticated_id: phil@qs.co.nz X-Authenticated-Sender: kate.whsl206.com: phil@qs.co.nz X-Source: X-Source-Args: X-Source-Dir: List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: module interface-aware HTML blockchain-based pipelining interface 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