From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mimir.eigenstate.org ([206.124.132.107]) by ewsd; Wed Mar 11 00:45:46 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 ca9d1e6b (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO); Tue, 10 Mar 2020 21:45:38 -0700 (PDT) Message-ID: To: plan9fullfrontal@qs.co.nz, 9front@9front.org Subject: Re: [9front] Bug in time cmd? Date: Tue, 10 Mar 2020 21:45:37 -0700 From: ori@eigenstate.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: webscale scripting NoSQL map/reduce property-based layer > 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.