Date: Tue, 23 Oct 2007 15:57:45 -0400 From: "Josh Carroll" <josh.carroll@gmail.com> To: "Kip Macy" <kip.macy@gmail.com> Cc: freebsd-performance@freebsd.org Subject: Re: ULE vs. 4BSD in RELENG_7 Message-ID: <8cb6106e0710231257k154e9c6ev4b4ba8c3692206fb@mail.gmail.com> In-Reply-To: <b1fa29170710231047i50859fa7gde2904985a7a8c20@mail.gmail.com> References: <8cb6106e0710230902x4edf2c8eu2d912d5de1f5d4a2@mail.gmail.com> <b1fa29170710231047i50859fa7gde2904985a7a8c20@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8cb6106e0710231257k154e9c6ev4b4ba8c3692206fb>