public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Gordan Bobic <gordan@bobich.net>
To: kvm@vger.kernel.org
Subject: Re: Virtualization Performance: Intel vs. AMD
Date: Sun, 15 Nov 2009 23:50:08 +0000	[thread overview]
Message-ID: <4B0093B0.2070503@bobich.net> (raw)
In-Reply-To: <200911151603.40453.tfjellstrom@shaw.ca>

Thomas Fjellstrom wrote:

>>>>> The Core i7 has hyperthreading, so you see 8 logical CPUs.
>>>> Are you saying the AMD processors do not have hyperthreading?
>>> Course not. Hyperthreading is dubious at best.
>> That's a rather questionable answer to a rather broad issue. SMT is
>> useful, especially on processors with deep pipelines (think Pentium 4 -
>> and in general, deeper pipelines tend to be required for higher clock
>> speeds), because it reduces the number of context switches. Context
>> switches are certainly one of the most expensive operations if not the
>> most expensive operation you can do on a processor, and typically
>> requires flushing the pipelines. Double the number of hardware threads,
>> and you halve the number of context switches.
> 
> Hardware context switches aren't free either. And while it really has 
> nothing to do with this discussion, the P4 arch was far from perfect (many 
> would say, far from GOOD).

I actually disagree with a lot of criticism of P4. The reason why it's 
performance _appeared_ to be poor was because it was more reliant on 
compilers doing their job well. Unfortunately, most compilers generate 
very poor code, and most programmers aren't even aware of the 
improvements that can be had in this area with a bit of extra work and a 
decent compiler. Performance differences of 7+ times (700%) aren't 
unheard of on Pentium 4 between, say, ICC and GCC generated code.

P4 wasn't a bad design - the compilers just weren't good enough to 
leverage it to anywhere near it's potential.

>> This typically isn't useful if your CPU is processing one
>> single-threaded application 99% of the time, but on a loaded server it
>> can make a significant difference to throughput.
> 
> I'll buy that. Though you'll have to agree that the initial Hyperthread 
> implementation in intel cpus was really bad. I hear good things about the 
> latest version though.

As measured by what? A single-threaded desktop benchmark?

> But hey, if you can stick more cores in, or do what AMD is doing with its 
> upcoming line, why not do that? Hyperthreading seems like more of a gimmick 
> than anything.

If there weren't clear and quantifiable benefits then IBM wouldn't be 
putting it in it's Power series of high end processors, it wouldn't be 
in the X-Box 360's Xenon (PPC970 variant), and Sun wouldn't be going 
massively SMT in the Niagara SPARCs. Silicon die space is _expensive_ - 
it wouldn't be getting wasted on gimmicks.

> What seems to help the most with the new Intel arch is the 
> auto overclocking when some cores are idle. Far more of a performance 
> improvement than Hyperthreading will ever be it seems.

Which is targeted at gamers and desktop enthusiasts who think that FPS 
in Crysis is a meaningful measure of performance for most applications. 
Server load profile is a whole different ball game.

Anyway, let's get this back on topic for the list before we get told off 
(of course, I'm more than happy to continue the discussion off list).

Gordan

  reply	other threads:[~2009-11-15 23:50 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-15 12:22 Virtualization Performance: Intel vs. AMD Andreas Winkelbauer
2009-11-15 13:05 ` Neil Aggarwal
2009-11-15 15:55   ` Thomas Treutner
2009-11-16 10:12     ` Avi Kivity
2009-11-17 10:23       ` Thomas Treutner
2009-11-15 15:56 ` Thomas Treutner
2009-11-15 17:33   ` Neil Aggarwal
2009-11-15 17:54     ` Thomas Fjellstrom
2009-11-15 17:59       ` Neil Aggarwal
2009-11-15 22:29       ` Gordan Bobic
2009-11-15 23:03         ` Thomas Fjellstrom
2009-11-15 23:50           ` Gordan Bobic [this message]
2009-11-16 12:02           ` Andi Kleen
2009-11-16 12:10         ` Avi Kivity

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=4B0093B0.2070503@bobich.net \
    --to=gordan@bobich.net \
    --cc=kvm@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox