lkml.org 
[lkml]   [2008]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Hyperthreading performance oddities
    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


    \
     
     \ /
      Last update: 2008-03-07 20:13    [W:7.722 / U:0.124 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site