Re: How long do render callbacks have to execute?
Re: How long do render callbacks have to execute?
- Subject: Re: How long do render callbacks have to execute?
- From: Brian Willoughby <email@hidden>
- Date: Fri, 19 Aug 2011 12:39:20 -0700
On Aug 19, 2011, at 07:25, Jean-Daniel Dupas wrote:
Le 19 août 2011 à 16:00, philippe wicker a écrit :
2011/8/13 Brian Willoughby <email@hidden>:
On Aug 12, 2011, at 15:39, Jonathan wrote:
Okay, that makes sense, but are the callbacks called in
parallel? In other
words, is only one callback firing at a time? In the example
with two
inputs into the mixer, does it fire one right after another
even though from
a graph perspective they are peers?
In general, a processor cannot carry out any operations in
parallel.
There is however one situation where a single core can execute 2
threads simultaneously, in "parallel" in a way. This is when hyper-
threading is enabled. For those of you who may not know what is
"hyper-threading" the basic idea behind it is to design the
silicon in such a way that a second thread of instruction can be
processed by filling the "holes" in the pipeline left by the 1st
thread of instruction.
At some point any instruction you can write needs the result of
some other preceding instructions (a "good" example of this is an
IIR filter). Because of this dependency the pipeline is not fully
used, the hardware has to insert "stall" cycles - some sort of
"NOP" cycles - needed for a result N to be actually available as
input of instruction N+1. These "NOP" cycles can be filled with
instructions from the 2nd thread.
I don't know if Apple uses or not this feature - I remember having
read some time ago that the gains in performance were not always
as good as expected - but if it is enabled the OS may choose to
assign 2 threads to the same core.
The reason the gains in performance were not as good as expected is
that hyper-threading shares resources between the two threads, and
one thread will frequently trip over the other when they both need
the same resource. Whenever there is a conflict, one thread must
wait for the other to finish with the shared resource. This waiting
occurs frequently enough that the speed gains by "filling in the
holes" is nowhere near twice as fast. Two independent cores would
actually run twice as fast.
One important issue to consider with respect to OSX is that it is an
SMP system. SMP stands for Symmetric MultiProcessing, with the key
word being symmetric. Hyper-threading is not fully successful
because it does not create symmetric processors. If you have two
hyper-threaded processors in a computer, then the OSX scheduler
cannot place a second thread without repercussions. Using the second
hyper-thread on a chip will run more slowly than using the first
hyper-thread on the second chip. Thus, the OS would need to track
too many dependencies for general multiprocessing to be useful. The
bottom line is that OSX cannot take advantage of hyper-threading.
Hyper-threading was more useful with Windows, a system that was not
designed very well. OSX, with its Mach underpinnings, is going to
need fully-independent processing units. If more than one core
exists in the same chip, then each core must be capable of running at
full speed without tripping over shared resources needed by the other
cores (the one exception to the shared resources is external memory,
which basically must always be shared in all multiprocessing systems).
Brian Willoughby
Sound Consulting
The performance was bad on pentium IV implementation of
HyperThreading, but it is far better on modern implementations.
On OS X, each core count as a physical CPU.
If a core is able to process 2 threads at the same time (it
supports Simultaneous multithreading, aka hyper-threading on Intel
processors) then the system will see it as 2 logical CPU.
On a dual core Corei7 machine, sysctl reports 4 physical CPU, and 8
logical CPU.
Anyway, it does not mean that callbacks are executed in parallel -
in the sense of running at the same time in 2 different threads.
For what I'v seen so far, the callbacks to a given AU instance
always originate from the same thread.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden