Re: [9front] Some SMP performance measurements.

[hiro <23hiro@gmail.com>]

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