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