Re: hyper-threading info - (long)

[Luke Kaven]

"ar3a" > wrote:

>> 1. It's really a feature of the CPU - not the platform. The only one that
>I
>> know first-hand that offers hyper-threading is the Intel P4 Xeon. If you
>> have a non-Xeon P4 it does not offer hyper-threading.
>
>Uhh...aren't those 2 completely different processors?? the P4 is one and
>the Xeon is another?? And, BOTH offer Hyperthreading in certain speeds.

The P4 is a family of processors involving a lot of additions over the
last few years. The Xeon started with the Pentium II and didn't have
hyperthreading. The Xeon has always had a Pentium core. The vanilla
P4 had the hyperthreading circuitry long before it was actually
unlocked, and it was first unlocked in the Xeon 2200 which was built
on a P4 core.

>> 2. What it does is allow the OS to operate the CPU as a dual CPU, with
>each
>> CPU running at half of the normal speed (e.g. a 2.4G CPU will look like
>two
>> 1.2G CPUs). It should be completely transparent to the running
>applications.
>> The ones that are make good use of multi-threading will benefit and the
>ones
>> that don't will not, or may even suffer.
>
>Which, at the moment...there are very few (if any) that support this
>technology very well.

Like any incremental measures to increase speed, it only works in
restricted contexts. In this case, it works best when one is rapidly
switching threads. The time savings comes from not having to flush
the pipelines & stack, among other things, in a context switch.

>> 3. Even if the CPU offers it, you still need an OS that supports it. The
>> Linux platform I've been building up supports it nicely, but I haven't
>> looked into which versions of Windows supports it, or how effectively.
>
>Are you sure it's OS dependant?? As long as your Processor utilizes
>Hyperthreading and your Motherboard supports your processor...I don't
>believe the OS is involved what so ever.

The idea of a thread is in part an OS-level construct in the first
place, though support for those constructs were subsequently imported
into hardware. So the handling of threads is somewhat distributed in
practice, and includes some software issues. Compiler support for HT
is dependent upon OS services. But then a certain amoutn of it is
transparent to the OS. So in a sense, you're both right.

http://www.tomshardware.com/cpu/20021227/index.html

[ar3a]

"Luke Kaven" > wrote in message
...
> "ar3a" > wrote:
>
> >> 1. It's really a feature of the CPU - not the platform. The only one
that
> >I
> >> know first-hand that offers hyper-threading is the Intel P4 Xeon. If
you
> >> have a non-Xeon P4 it does not offer hyper-threading.
> >
> >Uhh...aren't those 2 completely different processors?? the P4 is one and
> >the Xeon is another?? And, BOTH offer Hyperthreading in certain speeds.
>
> The P4 is a family of processors involving a lot of additions over the
> last few years. The Xeon started with the Pentium II and didn't have
> hyperthreading. The Xeon has always had a Pentium core. The vanilla
> P4 had the hyperthreading circuitry long before it was actually
> unlocked, and it was first unlocked in the Xeon 2200 which was built
> on a P4 core.

Ahh...OK, thanks for clarfying.

> >> 2. What it does is allow the OS to operate the CPU as a dual CPU, with
> >each
> >> CPU running at half of the normal speed (e.g. a 2.4G CPU will look like
> >two
> >> 1.2G CPUs). It should be completely transparent to the running
> >applications.
> >> The ones that are make good use of multi-threading will benefit and the
> >ones
> >> that don't will not, or may even suffer.
> >
> >Which, at the moment...there are very few (if any) that support this
> >technology very well.
>
> Like any incremental measures to increase speed, it only works in
> restricted contexts. In this case, it works best when one is rapidly
> switching threads. The time savings comes from not having to flush
> the pipelines & stack, among other things, in a context switch.

True.

> >> 3. Even if the CPU offers it, you still need an OS that supports it.
The
> >> Linux platform I've been building up supports it nicely, but I haven't
> >> looked into which versions of Windows supports it, or how effectively.
> >
> >Are you sure it's OS dependant?? As long as your Processor utilizes
> >Hyperthreading and your Motherboard supports your processor...I don't
> >believe the OS is involved what so ever.
>
> The idea of a thread is in part an OS-level construct in the first
> place, though support for those constructs were subsequently imported
> into hardware. So the handling of threads is somewhat distributed in
> practice, and includes some software issues. Compiler support for HT
> is dependent upon OS services. But then a certain amoutn of it is
> transparent to the OS. So in a sense, you're both right.
>
> http://www.tomshardware.com/cpu/20021227/index.html

I see. Thanks again for the clarification.

[Gary]

I have a somewhat related question - I've been thinking about a
motherboard/OS upgrade - my main reason for doing so would be to
improve video rendering speed, but after much thought I am leaning
towards putting a HT P4 on my second system which mostly just sits
there doing nothing unless I want to run GigaStudio or Retro AS-1 soft
synth. My primary DAW system is based on a Athlon XP 1800 - and it
seems plenty fast except for video rendering which is grbllllllggghhhh
molasses time.

Advantages of P4 for MPEG encoding are said to be SSE2 instructions
(as long as the program supports them, I think Vegas does this) and to
a greater/lesser extent the actual hyperthreading. I'm guessing that
MPEG encoding in and of itself is probably just a single thread.
Yes/no? I don't do animation rendering.

However lots of people have mentioned that certain design aspects of
the P4 (long pipeline e.g.) make other typical uses less efficient.
But if my other uses were limited to running single apps like my soft
synths, would it still suffer? Right now these are running on a "1.2
GHz" Athlon - I have a hard time imagining that a 2.4 GHz HT P4 would
be SLOWER.... but... ehhh...????

[Aaron C Borgman]

Sean Conolly > wrote:
> "Aaron C Borgman" > wrote in message
> ...
>> Sean Conolly > wrote:
>> > 2. What it does is allow the OS to operate the CPU as a dual CPU, with
> each
>> > CPU running at half of the normal speed (e.g. a 2.4G CPU will look like
> two
>> > 1.2G CPUs). It should be completely transparent to the running
> applications.
>> > The ones that are make good use of multi-threading will benefit and the
> ones
>> > that don't will not, or may even suffer.
>>
>> This is also completely incorrect.

> Well, since this is the core of the feature, maybe you could be a bit more
> specific. It certainly works this way with our server applications on Linux,
> and we haven't had to touch a line of code to take advantage of it.

"It should be completely transparent to the running applications. The ones
that are make good use of multi-threading will benefit and the ones that
don't will not, or may even suffer."

Is actually completely correct.

"What it does is allow the OS to operate the CPU as a dual CPU, with each
CPU running at half of the normal speed (e.g. a 2.4G CPU will look like two
1.2G CPUs)."

Is not. A 2.4GHz HT will look like 2x2.4GHz to the OS. It's performance will
range theoretically from twice as fast to considerably slower depending on
the composition of the code.

--
Aaron Borgman HE Design Engineer

JF4-4-C5
phone: 971-214-8380

Disclaimer: All above opinions are mine... not Intel's

[Aaron C Borgman]

Arny Krueger > wrote:
> "Sean Conolly" > wrote in message
>
>> "Aaron C Borgman" > wrote in message
>> ...
>>> Sean Conolly > wrote:
>>>> 2. What it does is allow the OS to operate the CPU as a dual CPU,
>>>> with each CPU running at half of the normal speed (e.g. a 2.4G CPU
>>>> will look like two
>>>> 1.2G CPUs). It should be completely transparent to the running
>>>> applications. The ones that are make good use of multi-threading
>>>> will benefit and the ones that don't will not, or may even suffer.
>>>
>>> This is also completely incorrect.
>>
>> Well, since this is the core of the feature, maybe you could be a bit
>> more specific. It certainly works this way with our server
>> applications on Linux, and we haven't had to touch a line of code to
>> take advantage of it.

> Don't worry about it. Borgman's post denies that your comments have one tiny
> bit of truth, and then his summary basically re-iterates what you said.
> Probably language-challenged.

His summary was correct, it was a number of the details which he got
incorrect.

--
Aaron Borgman HE Design Engineer

JF4-4-C5
phone: 971-214-8380

Disclaimer: All above opinions are mine... not Intel's

[Aaron C Borgman]

Sean Conolly > wrote:
> "Arny Krueger" > wrote in message
> ...
>> "Sean Conolly" > wrote in message
>>
>> > "Aaron C Borgman" > wrote in message
>> > ...
>> >> Sean Conolly > wrote:
>> >>> 2. What it does is allow the OS to operate the CPU as a dual CPU,
>> >>> with each CPU running at half of the normal speed (e.g. a 2.4G CPU
>> >>> will look like two
>> >>> 1.2G CPUs). It should be completely transparent to the running
>> >>> applications. The ones that are make good use of multi-threading
>> >>> will benefit and the ones that don't will not, or may even suffer.
>> >>
>> >> This is also completely incorrect.
>> >
>> > Well, since this is the core of the feature, maybe you could be a bit
>> > more specific. It certainly works this way with our server
>> > applications on Linux, and we haven't had to touch a line of code to
>> > take advantage of it.
>>
>> Don't worry about it. Borgman's post denies that your comments have one
> tiny
>> bit of truth, and then his summary basically re-iterates what you said.
>> Probably language-challenged.

> I find that people are much more willing to correct mis-information than to
> offer up the right information in the first place, so I fully expect that
> when I offer up what I know others who wouldn't respond to the original
> question will step up to correct me. That's OK, because it still gets the
> information out there. But there's a difference between "no, you're wrong"
> and "you're wrong, and here's why".

I would have answered he post had I seen it earlier. There is a reason why I
haven't made a more detailed answer to what you stated incorrectly -

1) I'm not sure may people here are really interested in the dirty details,
most probably just want a high level understanding,

2) BeforeI write up aything extensive I'll have to go back and figure out
which things I can actually say in public.


> FWIW I just spent some time looking over the white papers at
> developer.intel.com, and what I've presented is pretty close to what they
> have published.

Your overall assesment was a good high level description. Details were a bit
off. If anyone has any interest in a more technical discussion, we can do
that.

--
Aaron Borgman HE Design Engineer

JF4-4-C5
phone: 971-214-8380

Disclaimer: All above opinions are mine... not Intel's

[Keith Clark]

Gary wrote:

> I have a somewhat related question - I've been thinking about a
> motherboard/OS upgrade - my main reason for doing so would be to
> improve video rendering speed, but after much thought I am leaning
> towards putting a HT P4 on my second system which mostly just sits
> there doing nothing unless I want to run GigaStudio or Retro AS-1 soft
> synth. My primary DAW system is based on a Athlon XP 1800 - and it
> seems plenty fast except for video rendering which is grbllllllggghhhh
> molasses time.
>
> Advantages of P4 for MPEG encoding are said to be SSE2 instructions
> (as long as the program supports them, I think Vegas does this) and to
> a greater/lesser extent the actual hyperthreading. I'm guessing that
> MPEG encoding in and of itself is probably just a single thread.
> Yes/no? I don't do animation rendering.
>
> However lots of people have mentioned that certain design aspects of
> the P4 (long pipeline e.g.) make other typical uses less efficient.
> But if my other uses were limited to running single apps like my soft
> synths, would it still suffer? Right now these are running on a "1.2
> GHz" Athlon - I have a hard time imagining that a 2.4 GHz HT P4 would
> be SLOWER.... but... ehhh...????

In the old days, the longer pipeline may have been an issue.

But with today's clock speeds, 800 MHz FSB, dual-channel DDR, I pretty
much guarantee a hyperthreaded P4 won't disappoint (running one at 3.2 GHz
myself).

--Keith

[Brian Takei]

Aaron C Borgman )
in article > wrote:
> Sean Conolly > wrote:
>
> > I find that people are much more willing to correct mis-information than to
> > offer up the right information in the first place, so I fully expect that
> > when I offer up what I know others who wouldn't respond to the original
> > question will step up to correct me. That's OK, because it still gets the
> > information out there. But there's a difference between "no, you're wrong"
> > and "you're wrong, and here's why".
>
> I would have answered he post had I seen it earlier. There is a reason why I
> haven't made a more detailed answer to what you stated incorrectly -
>
> 1) I'm not sure may people here are really interested in the dirty details,
> most probably just want a high level understanding,
>
> 2) BeforeI write up aything extensive I'll have to go back and figure out
> which things I can actually say in public.
>
>
> > FWIW I just spent some time looking over the white papers at
> > developer.intel.com, and what I've presented is pretty close to what they
> > have published.
>
> Your overall assesment was a good high level description. Details were a bit
> off. If anyone has any interest in a more technical discussion, we can do
> that.

Fair enough. Thanks for publically contributing what you have, which,
personally, I prefer to no contribution at all given the conditions.

- Brian

[Aaron C Borgman]

In rec.audio.pro Gary > wrote:
> I have a somewhat related question - I've been thinking about a
> motherboard/OS upgrade - my main reason for doing so would be to
> improve video rendering speed, but after much thought I am leaning
> towards putting a HT P4 on my second system which mostly just sits
> there doing nothing unless I want to run GigaStudio or Retro AS-1 soft
> synth. My primary DAW system is based on a Athlon XP 1800 - and it
> seems plenty fast except for video rendering which is grbllllllggghhhh
> molasses time.

> Advantages of P4 for MPEG encoding are said to be SSE2 instructions
> (as long as the program supports them, I think Vegas does this) and to
> a greater/lesser extent the actual hyperthreading. I'm guessing that
> MPEG encoding in and of itself is probably just a single thread.
> Yes/no?

It is difficult to say. MPEG encoding could possily be multi-threaded (it's
an application that actually lends itself to such) but it dependson the
application. SSE2 coding can help dramatically (on some data-sets/software
groups it can be 5-10x as fast).

> However lots of people have mentioned that certain design aspects of
> the P4 (long pipeline e.g.) make other typical uses less efficient.
> But if my other uses were limited to running single apps like my soft
> synths, would it still suffer? Right now these are running on a "1.2
> GHz" Athlon - I have a hard time imagining that a 2.4 GHz HT P4 would
> be SLOWER.... but... ehhh...????

I doubt you'll findanything where a 2.4GHz P4 is slower than an Athlon
1.2GHz. Will it be twice as fast? Depends on the software. Things like MS
Word and other office apps will probably be faster, but not a
lot. Things that are coded for HT, or SSE2, or depend on large amounts of
pre-fetchable data (encoding falls into a number of these categories) could
show major speedups (>2x).

--
Aaron Borgman HE Design Engineer

JF4-4-C5
phone: 971-214-8380

Disclaimer: All above opinions are mine... not Intel's