Hi
Are we sure that the processing threads in created by Tracktion_Graph (using the thread pools) are running with max priority and QOS on Apple Silicon?
When testing the threads seem to be moved to Efficiency Cores very often, giving performance drops.
Reading up on it now it seems that the pthread_getschedparam called used are a bit dated and that there are other ways this should be handled on the latest apple hardware.
Can anyone please verify that we are using best practices here?
No, it doesn’t use that stuff, it was introduced (at least in JUCE) after I wrote it.
The problem is that tracktion::graph tries to not depend on JUCE so I can’t just swap out the std::threads for juce::Threads.
There’s also another question about how many threads it should use…
If there are only 4 performance cores, are 4 RT threads better than all cores running threads?
Has anyone benchmarked that kind of thing?
Hi @dave96
Thank you for getting back to me.
I have not benchmarked it, but from observation and from user feedback, being pushed over to the efficiency cores is creating performance issues. First, running with slightly fewer threads than cores seems to be better overall. Second, there are issues when the OS decides to move the threads from the P cores to the E cores. I would say running with threads = P cores would be the most logical, as most other processes are moved to the E cores.
I can see two ways forward here, either we have to implement the new API in the Tracktion threads, or maybe it is possible to create an optional Thread Pool that spawns Juce Threads?
I agree, do you know how to find that number though?
I can probably add a customisation point (e.g. in EngineBehaviour) to provide the ThreadPoolCreator function. You’d then create your own LockFreeMultiThreadedNodePlayer::ThreadPool which can create juce::Threads.
Would that work for you?
I can probably ultimately add a juce::Thread version to the library as tracktion::engine very much does depend on juce but I probably wont’ have time for a month or so. So it might be quicker for you to roll your own if I add the capability to do so?
Hi @dave96
Would that work for you?
I think this is a very good start. I will can use this to experiment on my end. Then, down the line, you can probably do a much better job of integrating it.
Hmm, let me think a little more on this. It’s really only the virtual methods in that class I want to expose. I don’t want to make LockFreeMultiThreadedNodePlayer public as it may well change in the future. But the virtual functions are probably what’s required to process the graph.
I’ve logged an issue to keep track of it:
1 Like