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: Jean-Daniel Dupas <email@hidden>
- Date: Mon, 22 Aug 2011 09:55:16 +0200
Le 19 août 2011 à 21:39, Brian Willoughby a écrit :
>
> 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.
So why the Activity Monitor display 8 processors on a single Quad Core, Corei7 ?
-- Jean-Daniel
_______________________________________________
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