I agree that multi-threading should work on all supported platforms, so if it doesn’t work on M1 mac, then something is wrong.
By “work” I mean that the ability to make bigger patches goes up as you throw more cores at at. And for sure that it not get significantly worse when you use more cores, no matter what.
Is it a problem in VCV or the M1? Don’t know for sure. Truthfully, I haven’t looked at how VCV works inside in ages. Is it related to “The M1 has four high-performance “Firestorm” and four energy-efficient “Icestorm” cores”? I don’t know…
I know that when I worked at a DAW company it was very difficult to get multithreading to work well on new macs, in general (this was long before M1), and to not regress when the OS was updated. I just say that to point out it’s a very difficult problem.
I was never good with computers and building them, so I always went for a gaming PC. As far as I understand it, VCV needs good GPU capabilities, so I went for a dedicated strong graphics card.
These are the specs I have experience with, and I work with VCV almost on a daily basis:
I would not avoid getting a laptop, but I just think that you would get more value with a desktop. The laptop I got is quite powerful, but because of it, it’s huge, heavy, and gets warm quickly. It’s also more expensive than a good desktop, and yes, you can tweak a desktop computer much more, upgrade it, and switch parts when needed. Also, the chances are, you will want a larger screen anyway, so you will anyway get a dedicated monitor. The same with a good audio interface. You will probably not want to use the one that comes with the desktop.
I got my laptop because I wanted it for situations where I want to be mobile, but it was as an addition to my main desktop computer.
Rack is exceptionally sensitive to core-to-core latency. Far more so than any other audio software I know of.
The probable reason for this is that many typical Rack modules are so simple, computationally (e.g. adders, gain scaling etc.), that the overriding factor when observing performance is not how fast cores can process data (i.e. clock speed and core capabilities), rather it’s how quickly cores hosting modules can talk to other cores hosting other modules.
It’s not easy to find core-to-core latency measurements for Apple Silicon. I have found a set of measurements for M1 Pro, though:
This should show you why multithreading Rack is difficult on this platform. If you cross the implied boundaries (from the ~40ns cores to the ~150ns cores) then your patch performance will tank.
These rules apply to all kinds of CPUs. The page hosting the above measurement has many other measurements, from recent Intel and AMD topologies to weird and wonderful massively-parallel server CPUs, some of which are not even available for sale to the public:
In the absence of Rack’s own ability to control core affinities to naturally performant groupings, additional tools are required.
For Windows, there is Process Lasso. With this, for any given application, one can build rules restricting core affinity to groupings of your choice. I don’t know if there is an equivalent on MacOS.
On any BIG.little architecture (such as Apple Silicon), where you have a mix of efficiency cores and performance cores, the operating system should assign cores optimally to the various tasks according to their observed needs. Would be interesting to find credible measurements of how well different OS’s do that when running on BIG.little. Because the whole stack is developed in-house at Apple, and they have a long history with ARM BIG.little (on iPhone and now Mac), I would expect them to be very good at that, but measurements would be cool.
The core latency result diagram above for M1 Pro shows that not only are there problems between little and BIG cores (the little cores clearly being 1 and 2), there are problems between the BIG core groups too (3-5 and 6-8)
If the Apple stack prevents a 3-core Rack patch from spreading across both BIG groups, that would be impressive. But the problem would remain (theoretically!) that it would not be sensible to run Rack on more than 3 cores on this CPU.
So… It would be wonderful to see core latency measurements for newer iterations of Apple Silicon, to see whether these groupings have been improved, or even swept away…
The link above is actually for the tool that measures this (I’m simply referencing results that have been submitted by users). If anyone running a shiny new M4, M3 etc fancies having a go at this, please report your findings!
And if anyone knows of an equivalent to Process Lasso for MacOS, or even techniques to control core affinity using the OS itself, that could be great information to know for Apple users… though it doesn’t look promising, reading this thread…
The specific model is not stated, though it appears (from the core count) to be a base-level M2, not Pro, Max etc.
The form of the presentation is different from the earlier post, though if I’m reading it correctly, it means that M2 (at least in this configuration) eliminated all variable latency groupings, and all cores can talk to each other with approximately consistent and low latency.
Bear in mind that here (if the CPU is a base-level M2), there are 4 P cores and 4 E cores. But if Rack is able to reliably keep its work on the P cores (using QOS), there would be a viable route to using a 4-core Rack patch without performance tanking.
I think that’s too strong a conclusion. But yes, if we assume that the OS is optimal at scheduling to the CPU it runs on, and given that on this specific chip the performance cores seem to be grouped in two clusters, then you can say that for certain workloads there would be a penalty for a process to use more than 3 performance cores. How much that will be percieved in real life is another matter. We are entirely in the realm of micro-benchmarks now.
The multi-threading penalty for Rack exists on all operating systems. If you would claim that it’s much worse on macOS I think some serious real-life measuring is in order.
Seems they have improved on the core interconnect in the chip which is good. It’s also been my vague impression that the fairly rapid iteration of the M* generations have been about polishing that SOC design, taking out the rough edges, and then gluing on a lot of GPU’s of course.
About the TouchBar: a few months ago I discovered that by using the scrub bar in the TouchBar (on a MacBook Pro 2019, Sonoma) you could skip through ads on YouTube. “Wow!” I thought, “I wish I had learned this before”.
Then a few weeks ago it stopped working. There was no OS update around that time, so Youtube probably plugged that hole.
btw, no Rack coder (yet?) but my 5/6 years old win 10 pro laptop (Dell Precision 7710) still works like a tank. of course the battery should be replaced but I don’t know if I will do it.
bought refurbished 5 years ago for 1500€
have worked a LOT in these years, mostly for CAD/CAM
Intel(R) Core™ i7-6920HQ CPU @ 2.90GHz
48 GB of RAM
2 SSDs
NVIDIA Quadro M5000M with 8 GB of RAM
the best (17.3") display I have put my eyes on. period.
no problem whatsoever with audio or video stuff.
do the fans run crazy? no, they will run crazy only if I open X-Plane, and for music if I hear them it means that I’m listening to music not loud enough
After almost 15 years, my desktop has slowly said goodbye. Instead of replacing component after component, I opted for a notebook. This has also had a very positive impact on the power consumption of my system. My choice fell - after ‘approval’ from my finance minister - on a gaming notebook (no, I’m not advertising now ;-), just so much:
Intel(R) Core™ i7-12650H, 4.7GHz
32GB RAM
2 SSDs (1TB, 4TB)
NVIDIA GeForce RTX 4060, 8GB RAM
4x USB 3.2 Gen 1
I’m using Linux in the form of Ubuntu Studio 24.04 as my operating system and am actually quite happy with it. I decided to use Linux after several system crashes following the infamous Windows updates. Once is enough
Although Linux is not officially supported by the notebook manufacturer, it runs perfectly after a few adjustments.
On the one hand, I solved the annoying fan noise with a base (self-made designer piece). Raising the 4 corner feet of the notebook has brought some peace and quiet. I drown out the rest of the fan noise - as @ale47p also wrote - by turning up the music volume
I switched to Brave as my browser nearly 2 years ago. Designed for security, privacy and thwarting advertisers out of the box. Haven’t wanted to use anything else since (nor have I used the root of all evil, Google, for search).
