hyperthreading on audio processing

Archived from groups: rec.audio.pro (More info?)

"Ernest Siu" <ernestsiu@yahoo.com> wrote in message
news:2833144d.0407211454.53ef97d3@posting.google.com...
> 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/it [...] stract.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

Archived from groups: rec.audio.pro (More info?)

ernestsiu@yahoo.com (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

Archived from groups: rec.audio.pro (More info?)

> I am afraid you do not have the slightest idea what hyperthreading really
> is. See this article:
> http://www.intel.com/technology/it [...] stract.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


Thanks.. I didn't know the chips as 2 ALU.

For performance, based on what you say HT seems to improve
multi-tasking as they are seperate threads and independent. Also
based on your description, previous system already attempts to make
use of the 2nd ALU, then this HT thing is an enhancement, but also
present to the developer/user that it can submit multi-processor code?

Ernest

Archived from groups: rec.audio.pro (More info?)

philicorda wrote:
> On the other hand, if the work load contains a mixture of math operations
> and memory operations, then the HT design helps, because one virtual
> processor can be accessing the math sub-unit, while another accesses the
> memory sub-unit.

This is kind of a backwards way, in my opinion, of looking at
hyperthreading. The whole point of hyperthreading is this: the
internals of processors can be made faster and faster, but the
memory access cannot. In fact, there is a little issue called
the speed of light to deal with: if the memory is 6 inches
away on the motherboard from the processor (which is necessary
because of things like heatsinks), then the very shortest possible
memory access would take at least 1 ns. It takes at least that
long just for the electrical signal to propogate. In practice,
it's several times that much because the memory has to have logic
to decode the address and ready the information to travel out
its bus. It depends on memory technology, but it's probably
around 25 ns these days to access memory.

Anyway, with a 2 GHz processor, the processor's internal clock
is ticking twice per nanosecond. If a memory access takes 25 ns,
then you are talking about 50 processor clock ticks. Worse yet,
a modern superscalar processor has a pipeline and multiple
integer and floating point units within it. With careful design,
the processor can on average complete more than one instruction
per clock. I don't know specifics of Pentium 4 or Athlon, but
let's say they average 2 instructions per clock. So, if a memory
access takes 50 clocks and you normally do 2 instructions per
clock, then you're going to miss out on doing 100 instructions.
That's a huge penalty, and it happens every time you have a
L2 cache miss. You're just letting the processor sit idle
while it waits on memory, and as processors get internally
faster and faster while memory doesn't improve much, this gets
to be more and more of a bottleneck.

One solution is hyperthreading. When instructions from the
current thread can't be run because of memory, immediately
switch over to the other thread and let the processor do
some work instead of sitting idle. You're not getting two
processors for the price of one. Instead, what you're doing
is finding a way to not have that expensive, complicated
processor just sit there and do nothing while it waits on
memory. Hyperthreading is a way to make better use of one
processor. The only reason it shows up as two processors
to the OS is that this is the easiest way to make the OS
understand that two threads should be put into the runnable
state and context-switched onto the processor so that the
processor has (when possible) two active threads to try and
chew on instead of one.

- Logan