From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from alt.b-painless.mh.aa.net.uk ([81.187.30.55]) by ewsd; Thu Mar 12 08:14:47 EDT 2020 Received: from 132.198.187.81.in-addr.arpa ([81.187.198.132] helo=quintile.net) by b-painless.mh.aa.net.uk with esmtp (Exim 4.92) (envelope-from ) id 1jCMjE-0002mt-Ar for 9front@9front.org; Thu, 12 Mar 2020 12:14:25 +0000 Received: from [172.24.208.48] ([83.219.41.164]) by quintile.net; Thu Mar 12 12:14:18 GMT 2020 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Steve Simon Mime-Version: 1.0 (1.0) Subject: Re: [9front] Some SMP performance measurements. Date: Thu, 12 Mar 2020 12:14:18 +0000 Message-Id: References: <03e5fb90-cee6-8c3a-3700-e547a2959e1e@qs.co.nz> In-Reply-To: <03e5fb90-cee6-8c3a-3700-e547a2959e1e@qs.co.nz> To: 9front@9front.org X-Mailer: iPhone Mail (17D50) List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: leveraged encrypted strategy deep-learning layer hi, out of interest what are you building, the kernel? also, remember the caches in the file servers so try repeating the build sev= eral times on a quiet machine. personally i find plan9=E2=80=99s linker is the bottleneck when doing builds= , and i have always found builds to be cpu bound. -Steve > On 12 Mar 2020, at 2:40 am, Trevor Higgins wro= te: >=20 > =EF=BB=BFUsing 'mk' just because it is there and manages the multitasking= for me. I used timing of a build to measure performance. > Comparing a standard build from ramfs with both source objects files in th= e same file service , and a build where the source and object files were spl= it between 8 ramfs mount points. >=20 > I have found that the Fileservices are a significant source of throttling o= f performance. Performance using hjfs shows ramfs is not causing unexpected d= elay and ramfs always shows significant increase in performance over hjfs. >=20 > Splitting the build directories showed a 4 fold decrease in real build tim= e with fewer processors/threads. > For a build with a single FS serving the source and a single FS serving th= e object storage, there is no real saving in time after 4 threads. The build= process is completely IO bound with 6 threads. >=20 > The split build is IO bound with 8 threads but with better utilization res= ulting in substantially lower build times. >=20 > No criticism of Plan9 or anything or anyone, just looking at the numbers t= o help figure out how to design some software I am writing. SMP may not be m= uch use to me in my application. >=20 >=20 > --=20 >=20 > We need another plan