DSP Robotics Support

So I read this about Ruby's Thread class:
"Traditional programs have a single thread of execution: the statements or instructions that comprise the program are executed sequentially until the program terminates.

A multithreaded program has more than one thread of execution. Within each thread, statements are executed sequentially, but the threads themselves may be executed in parallel on a multicore CPU, for example. Often on a single CPU machine, multiple threads are not actually executed in parallel, but parallelism is simulated by interleaving the execution of the threads.

Ruby makes it easy to write multi-threaded programs with the Thread class. Ruby threads are a lightweight and efficient way to achieve concurrency in your code."
Multicore CPUs make effective use of threads? Cool, I thought. I made a little example to test it. At least on my multicore PC the additional thread isn't executed in parallel, but just as described simulated by interleaving. Has anyone else played with the Thread class? Is there something wrong in my schematic?

tulamide wrote:So I read this about Ruby's Thread class:
"Traditional programs have a single thread of execution: the statements or instructions that comprise the program are executed sequentially until the program terminates.

A multithreaded program has more than one thread of execution. Within each thread, statements are executed sequentially, but the threads themselves may be executed in parallel on a multicore CPU, for example. Often on a single CPU machine, multiple threads are not actually executed in parallel, but parallelism is simulated by interleaving the execution of the threads.

Ruby makes it easy to write multi-threaded programs with the Thread class. Ruby threads are a lightweight and efficient way to achieve concurrency in your code."
Multicore CPUs make effective use of threads? Cool, I thought. I made a little example to test it. At least on my multicore PC the additional thread isn't executed in parallel, but just as described simulated by interleaving. Has anyone else played with the Thread class? Is there something wrong in my schematic?

the thread parallelism was first introduced to allow multitasking (running multiple programs on a single computer at the same time). However one thread can run only on a single core - I have noticed this myself. I have quadcore computer and windows meter shows 25% while Flowstone shows 100% and crackles like crazy (because the thing is running the thread on a single core, so only quarter of potential is usable). With multithread processing Windows manages the threads so, that it saves energy. That means if you have multiple CPU cheap Threads it opts to execute them on the same core (turning off the rest of the cores), instead of melting the ice caps with all of your 8 overclocked CPUs.
This video of FL studio shows it in action - FL studio is a multithreaded program, yet when CPU load is low, computer opts to turn off some of the cores. http://www.youtube.com/watch?v=DgOV21oi06Q

KG_is_back wrote:That means if you have multiple CPU cheap Threads it opts to execute them on the same core (turning off the rest of the cores), instead of melting the ice caps with all of your 8 overclocked CPUs.

I see. Screw you, Microsoft. I was just about to dream of a multicore-enabled vst. But hey, maybe if the load is too heavy it might wake up more cores! Hooray, I can still dream of it

Use multiple and simpler VST plugins instead.

Microsoft isn't that bad, if you look around for alternatives.

Basically, keep in mind also this. What is single-core, are streamy operations. I noticed, that green calculations (I guess specifically related to gui processing) - since they are handled by windows surface - they use other cores as well.

I'm not sure, but maybe (just maybe) - it's possible, that external dll's designed for processing something and giving back the feedback information - would work on other cores too, whole the FS plugin core will stay on single core. I might be wrong, but these seem to me to be separate units.

tester wrote:I'm not sure, but maybe (just maybe) - it's possible, that external dll's designed for processing something and giving back the feedback information - would work on other cores too, whole the FS plugin core will stay on single core. I might be wrong, but these seem to me to be separate units.

tulamide wrote:I see. Screw you, Microsoft. I was just about to dream of a multicore-enabled vst. But hey, maybe if the load is too heavy it might wake up more cores! Hooray, I can still dream of it

"Multithread program"="multicore when needed". There is no point of running the program on 2cores when one is capable of doing it with same efficiency. The whole point of multithread processing is to enable the operating system to have option to spread CPU load to more cores when situation requires. If you push your CPU harder, then naturally one thread will be moved to different core, to ease the load on the first one. Operating system reserves the amount of RAM and maximal CPU load for each thread and moves the threads between cores to execute them with maximum efficiency.

So to make story short. When you have Two threads they may be executed separately, and windows manages them where and when are they executed, be it on a single core when CPU load is low or two cores, when one core is pushed harder and need more cycle headroom. I can see this in FL studio too - when I have my battery mode to "powersaving mode" The CPU load on FL meter rises rapidly, but when it reaches 90% it suddenly jumps down to 50% - Windows enables more CPU cycles for FL studio and turns on second core.