ULE vs. 4BSD in RELENG_7
josh at tcbug.org
Tue Oct 23 14:02:42 PDT 2007
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,
Just curious, but are these results obtained while you are
overclocking your 2.4ghz CPU to 3.4ghz? That might be a useful
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-performance/attachments/20071023/f0786a5f/attachment.pgp
More information about the freebsd-performance