ULE vs. 4BSD in RELENG_7

[Josh Paetzel]

On Tuesday 23 October 2007, Josh Carroll wrote:
> > ULE is tuned towards providing cpu affinity compilation and
> > evidently encoding are workloads that do not benefit from
> > affinity. Before we conclude that it is slower, try building with
> > -j5, -j6, j7.
>
> Here are the results of running ffmpeg with 4 through 8 threads on
> both schedulers:
>
> 4 threads 4bsd:      117.21
> 5 threads 4bsd:       95.75
> 6 threads 4bsd:       93.10
> 7 threads 4bsd:       92.19
> 8 threads 4bsd:       92.38
>
> 4 threads ule:      122.19
> 5 threads ule:      107.26
> 6 threads ule:      101.40
> 7 threads ule:       98.72
> 8 threads ule:       96.38
>
> 4 threads difference: 4.25 %
> 5 threads difference: 12.02 %
> 6 threads difference: 8.92 %
> 7 threads difference: 7.08 %
> 8 threads difference: 4.33 %
>
> I'm not sure why the performance differential is not consistent
> (probably something very technical a scheduler developer could
> explain) :)
>
> Do these results help at all? When running with 9 or more threads,
> ffmpeg spits out a lot of errors, so 8 was as high as I could go:
>
> Error while decoding stream #0.0
> [h264 @ 0x264ae180]too many threads
> [h264 @ 0x264ae180]decode_slice_header error
> [h264 @ 0x264ae180]no frame!
>
> My next step is to run some transcodes with mencoder to see if it
> has similar performance between the two schedulers. When I have
> those results, I'll post them to this thread.
>
> Thanks for the attention,
> Josh

Just curious, but are these results obtained while you are 
overclocking your 2.4ghz CPU to  3.4ghz?  That might be a useful 
datapoint.

It also might be useful to know what sort of disks you are using.  
SATA is notoriously bad at parallel access, and compiling is of 
course horribly disk bound to begin with.

make buildworld also was never designed for massive parallelism at 
all, and slows down considerably as you try to scale it up with more 
cpus and increasing -j past a certain point.  I don't know where the 
break is, but it defintely has been hit at 16 cores.

-- 
Thanks,

Josh Paetzel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-performance/attachments/20071023/f0786a5f/attachment.pgp