Re: ULE vs. 4BSD in RELENG_7

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
_______________________________________________
freebsd-performance@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscribe@xxxxxxxxxxx"