Some SMP performance measurements.

Some SMP performance measurements.

[Trevor Higgins]

Using '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 
the same file service , and a build where the source and object files 
were split between 8 ramfs mount points.

I have found that the Fileservices are a significant source of 
throttling of performance. Performance using hjfs shows ramfs is not 
causing unexpected delay and ramfs always shows significant increase in 
performance over hjfs.

Splitting the build directories showed a 4 fold decrease in real build 
time with fewer processors/threads.
For a build with a single FS serving the source and a single FS serving 
the object storage, there is no real saving in time after 4 threads. The 
build process is completely IO bound with 6 threads.

The split build is IO bound with 8 threads but with better utilization 
resulting in substantially lower build times.

No criticism of Plan9 or anything or anyone, just looking at the numbers 
to help figure out how to design some software I am writing. SMP may not 
be much use to me in my application.


-- 

We need another plan

Re: [9front] Some SMP performance measurements.

[Steve Simon]

hi,

out of interest what are you building, the kernel?

also, remember the caches in the file servers so try repeating the build several times on a quiet machine.

personally i find plan9’s 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 <plan9fullfrontal@qs.co.nz> wrote:
> 
> Using '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 the same file service , and a build where the source and object files were split between 8 ramfs mount points.
> 
> I have found that the Fileservices are a significant source of throttling of performance. Performance using hjfs shows ramfs is not causing unexpected delay and ramfs always shows significant increase in performance over hjfs.
> 
> Splitting the build directories showed a 4 fold decrease in real build time with fewer processors/threads.
> For a build with a single FS serving the source and a single FS serving the object storage, there is no real saving in time after 4 threads. The build process is completely IO bound with 6 threads.
> 
> The split build is IO bound with 8 threads but with better utilization resulting in substantially lower build times.
> 
> No criticism of Plan9 or anything or anyone, just looking at the numbers to help figure out how to design some software I am writing. SMP may not be much use to me in my application.
> 
> 
> -- 
> 
> We need another plan

Re: [9front] Some SMP performance measurements.

[hiro]

i compared ramfs and cwfs, and performance was kinda same.
though ramfs might be slower than cwfs in some cases bec. ramfs is
single-threaded.

On 3/12/20, Steve Simon <steve@quintile.net> wrote:
> hi,
>
> out of interest what are you building, the kernel?
>
> also, remember the caches in the file servers so try repeating the build
> several times on a quiet machine.
>
> personally i find plan9’s 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 <plan9fullfrontal@qs.co.nz>
>> wrote:
>>
>> Using '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
>> the same file service , and a build where the source and object files were
>> split between 8 ramfs mount points.
>>
>> I have found that the Fileservices are a significant source of throttling
>> of performance. Performance using hjfs shows ramfs is not causing
>> unexpected delay and ramfs always shows significant increase in
>> performance over hjfs.
>>
>> Splitting the build directories showed a 4 fold decrease in real build
>> time with fewer processors/threads.
>> For a build with a single FS serving the source and a single FS serving
>> the object storage, there is no real saving in time after 4 threads. The
>> build process is completely IO bound with 6 threads.
>>
>> The split build is IO bound with 8 threads but with better utilization
>> resulting in substantially lower build times.
>>
>> No criticism of Plan9 or anything or anyone, just looking at the numbers
>> to help figure out how to design some software I am writing. SMP may not
>> be much use to me in my application.
>>
>>
>> --
>>
>> We need another plan
>
>

Re: [9front] Some SMP performance measurements.

[Ethan Gardener]

Just for comparison, SMP is known to be good for rc-httpd & werc which make heavy use of pipes. I don't know about using many cores for them, but >1 makes a huge difference.