All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Andi Kleen <andi@firstfloor.org>
Cc: Chris Snook <csnook@redhat.com>,
	Andrew Buehler <abuehler.kernel@gmail.com>,
	Frederik Deweerdt <deweerdt@free.fr>,
	belcampo <belcampo@zonnet.nl>,
	linux-kernel@vger.kernel.org
Subject: Re: Hyperthreading performance oddities
Date: Sat, 8 Mar 2008 08:30:01 +0100	[thread overview]
Message-ID: <20080308073000.GH8953@1wt.eu> (raw)
In-Reply-To: <87zltae3y7.fsf@basil.nowhere.org>

Hi Andi,

On Fri, Mar 07, 2008 at 08:20:32PM +0100, Andi Kleen wrote:
> Chris Snook <csnook@redhat.com> writes:
> > 
> > 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.
> 
> When the two cores are in the same address space (as in being two
> threads of the same process) L1 cache will be shared on P4. I think
> for the other cases the cache management is also a little more
> sophisticated than a simple split, depending on which HT generation
> you're talking about (Intel had at least 4 generations out, each with
> improvements over the earlier ones)

Oh that's quite interesting to know.

> BTW your argument would be in theory true also for multi core with
> shared L2 or L3, but even there the CPUs tend to be more sophisticated.
> e.g. Core2 has a mechanism called "adaptive cache" which allows one
> Core to use significantly more of the L2 in some cases.
>
> >  Number-crunching applications that utilize the
> > cache effectively generally don't benefit from hyperthreading,
> > particularly floating-point-intensive ones.
> 
> That sounds like a far too broad over generalization to me.
> 
> -Andi (who personally always liked HT)

Well, in my experience, except for compiling, HT has always caused
massive slowdowns, especially on network-intensive applications.
Basically, network perf took a 20-30% hit, while compiling took
20-30% boost. But I must admit that I never tried HT on anything
more recent than a P4, maybe things have changed since.

regards,
willy


  parent reply	other threads:[~2008-03-08  7:30 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-22  9:36 Hyperthreading performance oddities belcampo
2008-02-22 10:06 ` Frederik Deweerdt
2008-03-07 13:37   ` Andrew Buehler
2008-03-07 19:08     ` Chris Snook
2008-03-07 19:20       ` Andi Kleen
2008-03-08  7:12         ` belcampo
2008-03-08  7:30         ` Willy Tarreau [this message]
2008-03-08 11:46           ` Andi Kleen
2008-03-08 12:34             ` Willy Tarreau
2008-03-08 12:43               ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080308073000.GH8953@1wt.eu \
    --to=w@1wt.eu \
    --cc=abuehler.kernel@gmail.com \
    --cc=andi@firstfloor.org \
    --cc=belcampo@zonnet.nl \
    --cc=csnook@redhat.com \
    --cc=deweerdt@free.fr \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.