Hyperthreading and application response time

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Greetings,

Intel has put out a blurb about the effects of hyperthreading on
response time when performing multiple tasks:

http://www.intel.com/update/contents/dt09042.htm

Since the scenarios are described, if not in tremendous detail, one
could imagine trying to duplicate (or question) the results by
performing measurements of one's own. With 50-65% claimed improvement,
one imagines the effect would be noticeable, and they are somewhat
larger than the throughput improvement one might optimistically hope for
from hyperthreading (0-40%), but not so much larger that any but the
most fanatic wouldn't feel that there are probably more interesting
benchmarks to try to look into in detail.

The hyperthreading vs. no hyperthreading is a much cleaner question, of
course, than the AMD vs. Intel comparison that was recently discussed at
such length in these forums.

A more decisive study (if not to many engineers) would be to compare
user perceptions of system responsiveness with and without
hyperthreading (and against AMD) in a double blind study.

RM
6 answers Last reply
More about hyperthreading application response time
  1. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    "Robert Myers" <rmyers1400@comcast.net> wrote in message
    news:1Ep0d.169256$mD.48659@attbi_s02...
    > Greetings,
    <SNIP>
    >
    > A more decisive study (if not to many engineers) would be to compare user
    > perceptions of system responsiveness with and without hyperthreading (and
    > against AMD) in a double blind study.
    >
    > RM
    >

    Interesting idea, I'd love to know the results of such a study!

    Carlo
  2. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    "alexi" <apredtechenski@austin.rr.com> wrote in message
    news:JYO1d.9225$If2.8052@fe2.texas.rr.com...
    >
    > The result of "response speedup" is solely dependent on how sloppy
    > your main application interface is written. For example, in very
    > popular Microsoft language "Visual Basic", there is a call "DoEvents()".
    > If you forget to insert this call within some heavy data processing
    > loop, forget "interactivity" at all if you are running it on a
    > uniprocessor Windows.
    >
    > IMHO of course,
    >
    > - aap
    >
    >

    Not being familiar with VB I'm assuming from the description this function
    is akin to a "realease()" type function you would find on a coopertive
    multi-tasking system? If so wouldn't the pre-emptive multi-tasking nature of
    moder windows help to mitigate this? Or does the VB run time a high enough
    priority that it would kill the system?

    Carlo
  3. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    On Fri, 10 Sep 2004 22:11:09 GMT, Robert Myers <rmyers1400@comcast.net>
    wrote:

    >Greetings,
    >
    >Intel has put out a blurb about the effects of hyperthreading on
    >response time when performing multiple tasks:
    >
    >http://www.intel.com/update/contents/dt09042.htm
    >
    >Since the scenarios are described, if not in tremendous detail, one
    >could imagine trying to duplicate (or question) the results by
    >performing measurements of one's own. With 50-65% claimed improvement,
    >one imagines the effect would be noticeable, and they are somewhat
    >larger than the throughput improvement one might optimistically hope for
    >from hyperthreading (0-40%), but not so much larger that any but the
    >most fanatic wouldn't feel that there are probably more interesting
    >benchmarks to try to look into in detail.
    >
    >The hyperthreading vs. no hyperthreading is a much cleaner question, of
    >course, than the AMD vs. Intel comparison that was recently discussed at
    >such length in these forums.
    >
    >A more decisive study (if not to many engineers) would be to compare
    >user perceptions of system responsiveness with and without
    >hyperthreading (and against AMD) in a double blind study.

    Hmm, well alexi's response intrigued me and maybe somebody else already
    noticed this but it seems that www.principledtechnologies.com, which is
    passworded access only, is registered to a law firm, www.wcsr.com, called
    Womble, Carlyle, Sandridge & Rice. What the hell is Intel up to here? Is
    Randall Kennedy involved here... again? Are lawyers a required entity for
    the publishing of benchmarks now?

    Rgds, George Macdonald

    "Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
  4. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    "George Macdonald" <fammacd=!SPAM^nothanks@tellurian.com> wrote in message
    news:qqcgk0lgf4hshpuu6elbdn7fakp2qb6vb0@4ax.com...
    > On Fri, 10 Sep 2004 22:11:09 GMT, Robert Myers <rmyers1400@comcast.net>
    > wrote:
    >
    > >Greetings,
    > >
    > >Intel has put out a blurb about the effects of hyperthreading on
    > >response time when performing multiple tasks:
    > >
    > >http://www.intel.com/update/contents/dt09042.htm
    > >
    > >Since the scenarios are described, if not in tremendous detail, one
    > >could imagine trying to duplicate (or question) the results by
    > >performing measurements of one's own. With 50-65% claimed improvement,
    > >one imagines the effect would be noticeable, and they are somewhat
    > >larger than the throughput improvement one might optimistically hope for
    > >from hyperthreading (0-40%), but not so much larger that any but the
    > >most fanatic wouldn't feel that there are probably more interesting
    > >benchmarks to try to look into in detail.
    > >
    > >The hyperthreading vs. no hyperthreading is a much cleaner question, of
    > >course, than the AMD vs. Intel comparison that was recently discussed at
    > >such length in these forums.
    > >
    > >A more decisive study (if not to many engineers) would be to compare
    > >user perceptions of system responsiveness with and without
    > >hyperthreading (and against AMD) in a double blind study.
    >
    > Hmm, well alexi's response intrigued me and maybe somebody else already
    > noticed this but it seems that www.principledtechnologies.com, which is
    > passworded access only, is registered to a law firm, www.wcsr.com, called
    > Womble, Carlyle, Sandridge & Rice. What the hell is Intel up to here? Is
    > Randall Kennedy involved here... again? Are lawyers a required entity for
    > the publishing of benchmarks now?
    >

    Interesting observation indeed. Upon following your link, I noticed that
    one of the firm specialty is "Product Liability Litigation",

    http://www.wcsr.com/FSL5CS/practiceareadescriptions/practiceareadescriptions
    280.asp

    Maybe this is the key? All bases covered? :-)

    - aap
  5. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    "Bill Davidsen" <davidsen@darkstar.prodigy.com> wrote in message
    news:iN72d.8677$j51.4706@newssvr31.news.prodigy.com...

    [snip]
    >
    > Unless MS is lying (would they do THAT?) there should be affinity in
    > recent releases.

    The affinity might be there and likely is, but there is no
    corresponding system call in applications compiled before
    "recent releases." Which probably includes pretty-much every
    off-shelf application :-(

    > ....... And the point I was making is that even well-written
    > applications should see a benefit.


    And my counter-point was that even if an application is well-written
    (well-written by uniprocessor standards of course) and should see
    benefits, but in reality it doesn't, for reasons I stated in
    my previous post. Couple years back I tried the single-P-compiled
    SPEC_CPU benchmark suite on a dual-P system in hope that any
    system and other bookkeeping OS activity would be served by the
    second processor and not thrash my main thread. I was wrong
    - there was no measurable improvement in scores. Only when the
    KAI parallelizing pre-processor was employed I was able to see
    some shift in performance. Unfortunately, the shift was in
    both directions in different individual benchmarks, and the net
    was only slightly positive. As you might already know, the
    KAI is now an integral part of Intel compiler technology, and
    I am much sure there were vast improvements over the years.

    -aap
  6. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    alexi wrote:
    > "Bill Davidsen" <davidsen@darkstar.prodigy.com> wrote in message
    > news:iN72d.8677$j51.4706@newssvr31.news.prodigy.com...
    >
    > [snip]
    >
    >>Unless MS is lying (would they do THAT?) there should be affinity in
    >>recent releases.
    >
    >
    > The affinity might be there and likely is, but there is no
    > corresponding system call in applications compiled before
    > "recent releases." Which probably includes pretty-much every
    > off-shelf application :-(

    I didn't realize it had to be set, Linux tracks it and uses the same CPU
    where practical. You can set it by hand, but don't need to in most
    cases. Linux (recent) knows enough to handle SMT and SMP in any mix as well.

    --
    bill davidsen (davidsen@darkstar.prodigy.com)
    SBC/Prodigy Yorktown Heights NY data center
    Project Leader, USENET news
    http://newsgroups.news.prodigy.com
Ask a new question

Read More

CPUs Hardware Intel