View Single Post
  #26  
Old 2012-11-21, 12:01
jengstrom jengstrom is offline
Propellerhead
 
Join Date: Jan 2005
Posts: 931
Quote:
Originally Posted by PsyTale View Post
1. Is reason not utilizing the cpu to the max?
2. Is reason not utilizing all the cores in my system?
3. Is the DSP meter a meter that measures capability of a sound interface?
4. Is this a posible harddisk problem (disk to slow or something?) im using 2 western digital black edition disks in raid 0.
5. Is is my ram, do i need more ?!
Me and BMFH did respond about hyper-threading in this thread: https://www.propellerheads.se/forum/...d.php?t=169546

Except for the audio rendering work, everything in Reason uses hyper-threading.
Examples of tasks that use hyper-threading are GUI drawing, high quality stretch+resample and disk I/O.

Answer to 1. and 2: The Windows Task Manager CPU usage number shows the percentage of real time Windows considers a processor core working rather than idle. 100% CPU usage on a core signifies that Windows thinks that core is sustaining execution without pause.

I don't know how Windows measures the percentage of physical core execution time given to each logical core in a HT-processor.

On multi-core processors, Reason dedicates all except one of the available physical CPU cores for audio rendering. It must leave one core non-dedicated, to have computational power available for the less urgent tasks mentioned above.

When two threads are running on two logical cores which share a single physical core, the execution speed (intructions per second) of each thread varies hugely. At best, it will be about 30 % faster than traditional (non-HyperThreading) switching between two threads on a single core.
(The two HT-threads only run some instructions in parallel, under some conditions, but most are executed sequentially.)

Reason audio rendering threads can not work reliably on threads with such varying execution speed.
When two threads are running in parallel on two physical cores, the execution speed varies much less, and only because of memory, caches and such.
I.e. the way Reason dedicates threads to cores is only reliable with physical cores, and not with logical cores that execute using HyperThreading.

If Reason would dedicate all your cores to audio rendering, including logical cores, it would be much less reliable and responsive.
Unlimited CPU core dedication could have been made a option in Reason Preferences, but would be difficult to support due to different interpretations of what it does.


Answer to 3. Yes, the DSP meter measures the percentage of real time left between deliveries of audio to/from the interface driver.

If it shows 0%, almost no time is spent in Reason to deliver audio to/from the interface driver.
If it shows 100%, the interface driver wants more audio before Reason has finished rendering the previous batch.


Answer to 4. and 5. I don't think memory or hard-disk are big factors in this case.


How are you routing in your example?
Since Reason allows free routing, if you have long effect chains and/or feedback, multi-core rendering is less effective, since interconnected processing can't be done in parallel.