For audio in general the more physical cores the better, for VCV a good dedicated GPU will help tremendously for rendering vector graphics, this is because it takes the load off the CPU leaving the physical and threaded cores to work on the audio.
3 Likes
I like the 9th comment by Lars from this old post where he talks about 3 things you need in a laptop to run Rack well. He also links benchmarks of cpu’s. Please Help! Extremely glitchy on MBP
I have a desktop, so I can’t speak to the whole fan issue of owning a laptop, but i got my desktop probably almost 2 years ago after seeking advice from the community, and it still runs Rack perfectly. My cpu/gpu specs are:
8th Generation Intel® Core™ i7-8700 6-Core Processor (12M Cache, up to 4.6 GHz)
NVIDIA® GeForce® GTX 1050Ti with 4GB GDDR5 Graphics Memory
So something with these specs or better and nice laptop cooling and you will probably be good. Also, Omri Cohen lists his computer specs on his youtube video descriptions, and he seems to have good luck with integrating VCV with a other software & hardware using a 4 core i7-7700k & a GTX 1070.
2 Likes
I’m not sure that 45 W is enough, if you want to spend more than half an hour on a big patch. You should be aware that you won’t be able to do the same things just with the battery than with the power supply… I guess🤔
Thanks Adi, yeah, it’s this link:
If we had a good wiki we could make the canonical page for performance things, but perhaps starting a dedicated topic here would do, hmm…
2 Likes
Why is that? As it supports multiple cores. Does the audio part use GPU or is it only for the visuals? Would offloading the graphics to another machine help (X11)?
GPU just renders graphics
Because, although Rack has gained multithreading support, the overhead of that is quite large. The way to use number of threads/cores in Rack is:
Start with 1 thread. If the audio starts to break up, and only then, even with a suitable audio buffer size, then increase the thread count to two, etc.
Try and load a modest patch in Rack, with threads = 1. Now open the performance monitor in your operating system and note the CPU consumption. Now increase to threads = 2 (or higher) and notice the jump upwards for CPU consumption in your performance monitor. That’s the CPU overhead of threading kicking in.
So, especially if you have a laptop with the limitations of its cooling system, the name of the game is to squeeze as much as possible out of 1 thread, which means - single core performance very much matters.
It’s great to have the option of multi threading, because it raises the ceiling for how big a patch you can run, but the cooling system needs to be up for it, because it burns a lot of CPU cycles.
No, but if the GPU is too weak the graphics will start to use CPU for rendering, making things worse for an underpowered system.
boiled from the inside
in my dungeon
lives that noisy monstrum
24/7 it traces ray
many processors
many cores
I feed it code
every day
yet now and then
and more often
bits go astray
1 Like
Just tested what you wrote,
a simple scene in POV-Ray on this old 6 core machine, 1 thread 22.3% 9309 pixels/second. 6 threads 98% 43885 pixels per second.
Rack, just the template that comes with it, 3.8% with 1 thread, ~30% with 6 threads.
Now the frightening part, when deleting everything, audio-8 as last load rises to 86%. Does this sound right? (win10). When I add audio-8 back it stays high until I select an audio-driver. With 3 thread in an empty rack it idles at ~45%. Time for a bug-report?
1 Like
No one likes this answer, but the best thing is to use any tower computer and avoid all laptops. Except for super high end gaming laptops. It seem the thermal issues make rack and laptops a bad combo.
1 Like
This used to be working as designed, and a non issue. Not sure it that’s still true. Do some searching before posting a bug.
Thanks for the replies everyone. I’ve ordered a Dell G7 with an i7-9750H CPU, 8Gb RAM and GTX 1650 graphics. I’ll report how it performs after I’ve picked it up and installed Rack. I’ve got a desktop I can upgrade if I ever get time to build patches that need even more oomph - needed a new laptop anyway and got one through my job where I pay it monthly so it kind of made sense.
3 Likes
Sounds good but… 8 GB RAM, ouch! I would have definately gone for 16 GB for any new machine. Won’t be a problem for just using Rack but you’ll soon hit the roof doing combinations of other things. Let us know how the machine performs with Rack, so we can build up a bit of a knowledge base.
1 Like
Yup, that’s exactly the illustration of what I was talking about, the overhead of multithreading.
Don’t worry about that artificial situation. As I recall Andrew’s answers to that, it’s simply an artifact of how the Rack audio engine works. You need an audio module connected to some audio interface, and the audio module needs some audio to process. So, not a bug.
Well, not so artificial here as I often just fiddle with something simple and a scope, guess I’ll leave the audio-8 running then.
Thanks,
Ingo
1 Like
Perhaps I’m reading too much into what you mean by “overhead”, but I do not see a significant multithreading performance penalty (i.e. an “overhead”) in Rack.
For example, on one thread, I can hook up 19 instances of Vult Freak (in Vortex mode) between a VCO and a mixer before the thread runs out of resources.
Enabling a second thread, I can add 19 more instances before hitting the limit. Enabling a third thread gets me 18 more, with 19 being slightly out of reach
Rack actually appears to be extremely efficient when utilising multiple cores but as you’ve said, one should only open up additional threads when the patch requires it, as extra threads have the potential to actively waste CPU resources if they don’t have enough work to do. But for me at least, that wastage almost completely goes away if you then add further modules.
Yeah, interesting observation. I guess we can expand this further, leaving all non-techies way behind…
So - If you’re not completely using the full capacity of 1 thread, then engaging further threads without strictly needing to, is definately not free (see Ingo’s measurement above), and incurs quite the overhead.
But - As you point out, if you max. out 1 thread with the load of X, then the next thread you engage can also be loaded with X, and the next, and the next, which means that the “total patch capacity” of Rack seemingly scales very nicely with the thread count. Which is very good to know if you have a beefy computer with great cooling, and would like to run really big patches.
That, however, does not make the overhead on the total load on your computer’s CPU go away. If you have a monster computer that doesn’t matter at all, but with a more modest/normal computer, and especially a laptop, the overhead definately counts, because what matters is how your computer copes with the total load you put on it’s CPU, especially where cooling is concerned.
So I will still say: Single core performance matters a great deal, particularly on low/mid-range computers and especially on laptops, because the better a single core performs, the bigger the patch you can run on just 1 thread, before you have to engage the next thread, and pay the overhead cost of multithreading on your CPU.
Yeah thermal management is a key factor, which is why desktops generally perform better. The gaming laptop is pretty good though. Haven’t stress tested it much yet, and it jittered a bit until I changed the power profile but it’s running pretty smooth now and will handle patches that would crap out on my i5 desktop. Fairly pleased so far.
3 Likes