I agree, it does seem somewhat counter-intuitive to limit the cores available to VCV so drastically. And it was a little disappointing to find this out after I’d bought the new system. But like I said, it’s not really had any practical impact for my usage
Just to clarify the performance hit when going cross-CCX - when running the above patch on 2 CCXs instead of 1, the CPU hit on both CCXs actually goes up by about 15% despite having twice as many cores! i.e. 1 CCX = ~70% usage, 2 CCXs = ~85% usage on both
As far as I’ve been able to tell, this is all to do with inter-core data latency. This diagram should show you all you need to know:
…so while, within a CCX, data latency is extremely low, almost twice as good as the Intel example (Coffee Lake Refresh), between CCXs it flies up, almost three times worse. And it indicates, to me at least, that any multithreaded application with intensive real-time non-block-processing DSP (e.g. VCV) should be restricted to running inside a single CCX on Zen 2 processors.
Whether Intel offer anything that gives you an increase in overall capacity (perhaps at a lower overall efficiency) with their newest HEDT chips is something you’d probably want to look into if you’re going for a pure-VCV system. Personally, VCV is only 1 part of my setup and I’m happy keeping it locked to a quarter of the CPU. It can still handle literally hundreds of modules.
The competing architectures are different enough now that you really have to go into a lot of detail about the nature of the applications you want to run - how they process and move data around, what processor extensions they leverage, how much power they need for a given scenario, how they spread load - before you can make the best decision on what to invest your money in. VCV, in my experience, is a very peculiar scenario to work with - normal, block-processing VST plugins don’t suffer this cross-CCX performance drop nearly as badly, having tried the likes of Diva and other multithreaded VSTs…
edit:
I meant to add - I don’t think there is a way to run multiple instances of VCV on a single machine - the program stops you from doing this
Whether that changes when VCV runs under a VST host, I’m not sure, and perhaps more specifically, if it’s possible to tie instances of VCV running under a VST host to specific CCXs, also remains to be seen. Or even whether such a thing is necessary, as they will be processing in blocks (presumably)