Re: Hyperthreading performance oddities

[Chris Snook]

Andrew Buehler wrote:
> (I'm aware that this could be considered thread necromancy, but I
> haven't yet seen any indication that that is considered a bad thing in
> these here parts; if it is, then I apologize, and upon being informed of
> the fact will undertake to not commit such again.)
>
> On 2/22/2008 5:06 AM, Frederik Deweerdt wrote:
>
> > Hello Henk,
> >
> > On Fri, Feb 22, 2008 at 10:36:01AM +0100, belcampo wrote:
> >
> > > Kernel 2.6.22.9 smp hyperthreading
> > > BENCHMARKs: VC: 334.042s VO:   0.053s A:   0.000s Sys:   4.049s =  
> > > 338.143s
> > > Kernel 2.6.22.9 nonsmp/hyperthreading
> > > BENCHMARKs: VC: 262.008s VO:   0.031s A:   0.000s Sys:   3.528s =  
> > > 265.567s
> > > with 2.6.17 kernel smp/hyperthreading pentium-pro as CPU
> > > BENCHMARKs: VC: 245.175s VO:   0.050s A:   0.000s Sys:   2.479s =  
> > > 247.704s
> > > with 2.6.17 kernel smp/hyperthreading pentium4 optimized kernel
> > > BENCHMARKs: VC: 227.992s VO:   0.051s A:   0.000s Sys:   2.551s =  
> > > 230.594s
> >
> > I'm not familiar with mplayer benchmarks, what do they actually measure?
>
> I don't know if this discussion got continued privately, but on the
> assumption that it didn't, I think I can give at least a basic answer to
> this.
>
> The VC: value is the amount of time spent in the video-codec code during
> that run, the VO: value is the amount of time spent in the video-output
> code, the A: is the amount of time spent in (ISTR) audio processing -
> though whether codec or audio-output or audio filters etc. is unclear, I
> remember there being separate values for those rather than their being
> lumped under one header- and the Sys: value is I believe the amount of
> time spent in system calls.
>
> (For the record: I'm a long-time lurker and occasional, largely
> non-code, contributor on the MPlayer development lists, but I've never
> had occasion to look at the code behind or the logic involved in the
> -benchmark output.)

Turning on hyperthreading effectively halves the amount of cache 
available for each logical CPU when both are doing work, which can do 
more harm than good.  Number-crunching applications that utilize the 
cache effectively generally don't benefit from hyperthreading, 
particularly floating-point-intensive ones.

On the other hand, hyperthreading is excellent for streaming integer 
work, like compiling.  Whether or not you should use it depends entirely 
on your workload.

-- Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/