You guys probably talked about it quite a while ago, but I still don't
get a good answer. To my understanding, hyperthreading is the ability
to make use of ALU and FPU simutaneously in a CPU - totally different
from a dual CPU set-up. The ALU performs integers and logical
(or/and/xor) operations, and FPU is for floating points. To me the
answer lies on what audio application does:

- recording single/multi-tracks : integer and/or floating-point?
- playback of multi-tracks : integer and/or floating-point?
- playback with effects : integer and/or floating-point?
- mix-down : integer and/or floating-point?

Aside from the computing technical stuff, I'm sure some of you guys
actually used a hyperthreading system and may have some empericial
data for answering the question if HT helps or hurts audio
applications.

To me, the only time when HT helps is the running process involves
both integer and floating point operations simultaneously.

Regards,
Ernest

"Ernest Siu" wrote in message
om...
You guys probably talked about it quite a while ago, but I still don't
get a good answer. To my understanding, hyperthreading is the ability
to make use of ALU and FPU simutaneously in a CPU - totally different
from a dual CPU set-up. The ALU performs integers and logical
(or/and/xor) operations, and FPU is for floating points. To me the
answer lies on what audio application does:

- recording single/multi-tracks : integer and/or floating-point?
- playback of multi-tracks : integer and/or floating-point?
- playback with effects : integer and/or floating-point?
- mix-down : integer and/or floating-point?

Aside from the computing technical stuff, I'm sure some of you guys
actually used a hyperthreading system and may have some empericial
data for answering the question if HT helps or hurts audio
applications.

To me, the only time when HT helps is the running process involves
both integer and floating point operations simultaneously.

Regards,
Ernest

I am afraid you do not have the slightest idea what hyperthreading really
is. See this article:
http://www.intel.com/technology/itj/...1_abstract.htm

The P4 and XEON CPUs have two integer processing units and one FPU. This has
been the case since the Pentium-II CPU. The microcode decode portion of the
chip would try to take advantage of the two integer units by predicting
instructions similar to how the L1 & L2 cache engines worked. However, this
was not very efficient and typically one of the integer units was inactive
50% of the time. So, with one of the P4 chip upgrades they introduced
hyperthreading which allowed the OS and codewriters to explicitly take
advantage of the dual Integer units by presenting them as virtual CPUs to
the OS.

So, it is possible to have three instructions take place in one clock
cycle - Integer 1, Integer 2 and FPU.

Isn't that amazing????

If the application is written to be expressly paralleled (supporting out of
order execution and dual CPUs), Hyperthreading can accelerate performance by
as much as 30%. However, if the applications are not written that way, the
OS can do some of it for you and offer improved performance of about 5% to
15%. In a worse case situation, some applications will actually run slower
on a hyperthreaded machine -specifically applications that require
absolutely sequential execution of all commands.

I do not have specific results for any particular audio application's
performance, so I cannot comment on whether Hyperthreading will improve
things or not. But it is easy to test with Windows XP Pro. Simply turn
Hyperthreading on in the BIOS and time an automated mix on the application
then reboot and turn off Hyperthreading and perform the same mix.

- Flint

Ernest Siu wrote:
You guys probably talked about it quite a while ago, but I still don't
get a good answer. To my understanding, hyperthreading is the ability
to make use of ALU and FPU simutaneously in a CPU - totally different
from a dual CPU set-up. The ALU performs integers and logical
(or/and/xor) operations, and FPU is for floating points. To me the
answer lies on what audio application does:

- recording single/multi-tracks : integer and/or floating-point?
- playback of multi-tracks : integer and/or floating-point?
- playback with effects : integer and/or floating-point?
- mix-down : integer and/or floating-point?

Aside from the computing technical stuff, I'm sure some of you guys
actually used a hyperthreading system and may have some empericial
data for answering the question if HT helps or hurts audio
applications.

To me, the only time when HT helps is the running process involves
both integer and floating point operations simultaneously.


Some informed posts on this subject too, at
. Especially from Dave Haynie .

geoff

(Ernest Siu) wrote:

To me the
answer lies on what audio application does:

- recording single/multi-tracks : integer and/or floating-point?
- playback of multi-tracks : integer and/or floating-point?

The audio application gets/sends buffers with interger numbers
from/to the sound card. With mit AMD CPU @ 1400 MHz the system
load is less than 10% during both recording and playback.

- playback with effects : integer and/or floating-point?
- mix-down : integer and/or floating-point?

This is in control of the audio application software. Adobe Audition
uses floating point procedures for all kind of processing.

Norbert

flint wrote:
The P4 and XEON CPUs have two integer processing units and one FPU. This has
been the case since the Pentium-II CPU. The microcode decode portion of the
chip would try to take advantage of the two integer units by predicting
instructions similar to how the L1 & L2 cache engines worked. However, this
was not very efficient and typically one of the integer units was inactive
50% of the time. So, with one of the P4 chip upgrades they introduced
hyperthreading which allowed the OS and codewriters to explicitly take
advantage of the dual Integer units by presenting them as virtual CPUs to
the OS.

So, it is possible to have three instructions take place in one clock
cycle - Integer 1, Integer 2 and FPU.

Isn't that amazing????

It's nice, but since CDC did it in 1964, I can't find it all that amazing
or innovative.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."