Date: Sun, 05 Oct 2003 03:47:36 +0200 From: Marcin Dalecki <mdcki@gmx.net> To: richardcoleman@mindspring.com Cc: Kris Kennaway <kris@obsecurity.org> Subject: Re: Hyperthreading slowdown Message-ID: <3F7F7838.4070707@gmx.net> In-Reply-To: <3F7F41A5.7020202@mindspring.com> References: <Pine.LNX.4.58.0310041623250.6065@artax.karlin.mff.cuni.cz> <20031004190251.GA60026@rot13.obsecurity.org> <3F7F1D63.2010703@mindspring.com> <20031004200435.GA60432@rot13.obsecurity.org> <3F7F41A5.7020202@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Richard Coleman wrote: > Kris Kennaway wrote: > >> On Sat, Oct 04, 2003 at 03:20:03PM -0400, Richard Coleman wrote: >> >>> Kris Kennaway wrote: >>> >>>> On Sat, Oct 04, 2003 at 04:39:03PM +0200, Mikulas Patocka wrote: >>>> >>>>> I installed FreeBSD 4.9RC1 on P4 3GHz with hyperthreading and I see >>>>> drastic slowdown when kernel with hyperthreading is booted. For >>>>> example >>>>> program compilation took this time: >>>>> >>>>> hyperthreading kernel, make -j 1 --- 1:09 >>>>> hyperthreading kernel, make -j 2 --- 0:42 >>>>> singlethreading kernel, make -j 1 --- 0:45 >>>>> singlethreading kernel, make -j 2 --- 0:41 >>>>> >>>>> Compilation does very few system calls so when I compile with only one >>>>> process (-j 1), it should be as fast as with singlethreading >>>>> kernel. Do >>>>> you have any idea why is it so slow? >>>> >>>> >>>> Do you realise that hyperthreading != a secret extra CPU in your >>>> system? >>>> >>>> Kris >>> >>> >>> I didn't see anywhere in the message where he implied that. To me, >>> the interesting thing is that there is such a larger difference >>> between the compile time for -j1 and -j2 when using hyperthreading as >>> compared to the difference between -j1 and -j2 for a single threaded >>> kernel. It's over a 50% slowdown. >> >> >> >> Yes, that's because (as discussed in the archives) the kernel treats >> it like an extra, completely decoupled physical CPU and schedules >> processes on it without further consideration. This is presumably the >> cause of the slowdown, because it's only efficient to use the virtual >> CPU under certain workload patterns. HTT is not magic performance >> beans. >> >> Kris > > > Sigh. No one is claiming HTT is magic performance beans. The 50% > slowdown I'm talking about is between -j1 and -j2 BOTH ARE WHICH ARE > USING HTT. > > It's just an interesting observation. That's all. It's not interresting. It is to be expected. The only gains one could exepect are in the case where sufficently differrent execution units of the CPU would be used. Like for example doing floating point vers. integer calculations. But exen then Amdahl will bite you by the incurrend synchronisation verhead anyway..
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F7F7838.4070707>