Hyperthreading and application response time

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

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

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??

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/pra...
280.asp

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

- aap

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

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