Latest News: Bitwig updates Bitwig Studio to v5.1
[feature request] turn off hyperthreading
- Banned
- Topic Starter
- 11467 posts since 4 Jan, 2017 from Warsaw, Poland
I don't think this option is exposed in Bitwig, right?
Normally, one would think having this ON is good, since you're using your CPU to its full potential. However:
- splitting of clocks and allocation of jobs across 'weaker' threads (and management of job queues, interlocks, etc.) is a job in itself, so there's a tangible processing overhead, which means that sum of throughput of twice as many threads is always smaller compared to the sum of throughput of real hardware cores working at full clock and with less job scheduling,
- I tried (in Excel ) to work out some examples of audio processing, where more threads would be better than half the cores with no hyperthreading and at full clock - no matter how many tracks and how long each one of them would take to process, the no-threading setup was always on top,
- I did some testing in Reason 10 where this setting is exposed and - surprisingly enough - my CPU was showing 10-20pp less utilisation, which was enough to ensure glitch-less playback
I suspect this might be less of an issue for projects that only replay audio clips with few mixing inserts on top of each channel and few mastering plugins on the Master, because that lends itself well to parallel processing.
But I think it can make a huge difference in complex, modular setups like Bitwig, Live or Reason are encouraging, where CPU has to "wait" for signals coming from other tracks, busses, nested effects, cross-track sidechaining and signal routing, etc. In such cases, having many "weaker" threads with no space left to add one more big-sized job (because it can't be split to different jobs) is inferior to few, much faster physical cores where such bottleneck is less likely. This results in a confusion I see quite often on FB or here: why is my DSP full, when CPU monitor shows 50% utilisation. That's exactly because none of the threads is able to accommodate yet another track/plugin in full, whereas it would be more likely that a "full" core would, because - simplifying - it would have double the processing headroom.
So, I'd love to see such an option exposed in Bitwig (unless it is buried somewhere?)
Normally, one would think having this ON is good, since you're using your CPU to its full potential. However:
- splitting of clocks and allocation of jobs across 'weaker' threads (and management of job queues, interlocks, etc.) is a job in itself, so there's a tangible processing overhead, which means that sum of throughput of twice as many threads is always smaller compared to the sum of throughput of real hardware cores working at full clock and with less job scheduling,
- I tried (in Excel ) to work out some examples of audio processing, where more threads would be better than half the cores with no hyperthreading and at full clock - no matter how many tracks and how long each one of them would take to process, the no-threading setup was always on top,
- I did some testing in Reason 10 where this setting is exposed and - surprisingly enough - my CPU was showing 10-20pp less utilisation, which was enough to ensure glitch-less playback
I suspect this might be less of an issue for projects that only replay audio clips with few mixing inserts on top of each channel and few mastering plugins on the Master, because that lends itself well to parallel processing.
But I think it can make a huge difference in complex, modular setups like Bitwig, Live or Reason are encouraging, where CPU has to "wait" for signals coming from other tracks, busses, nested effects, cross-track sidechaining and signal routing, etc. In such cases, having many "weaker" threads with no space left to add one more big-sized job (because it can't be split to different jobs) is inferior to few, much faster physical cores where such bottleneck is less likely. This results in a confusion I see quite often on FB or here: why is my DSP full, when CPU monitor shows 50% utilisation. That's exactly because none of the threads is able to accommodate yet another track/plugin in full, whereas it would be more likely that a "full" core would, because - simplifying - it would have double the processing headroom.
So, I'd love to see such an option exposed in Bitwig (unless it is buried somewhere?)
- Banned
- Topic Starter
- 11467 posts since 4 Jan, 2017 from Warsaw, Poland
BTW, here's more approachable illustration of what I mean (obviously, on a severely simplified example):
Now add to that, that with more cores - due to scheduling overhead - it might not be possible to *effectively* get the same processing power (so, 2 cores would effectively run at 7.95GHz each, 4 cores at 3.9GHz each, etc.) and we would start hearing the glitches even sooner.
Does that mean multi-core CPUs is a hoax? No, because there are physical and thermal limits to clocks at which they can run, so it's better to have 2 cores at 3.5GHz each, than 1 core at 6GHz
So is hyperthreading a hoax, then? Well, here I can't really see the benefits other than marketing ones, since obviously more is better, right
Now add to that, that with more cores - due to scheduling overhead - it might not be possible to *effectively* get the same processing power (so, 2 cores would effectively run at 7.95GHz each, 4 cores at 3.9GHz each, etc.) and we would start hearing the glitches even sooner.
Does that mean multi-core CPUs is a hoax? No, because there are physical and thermal limits to clocks at which they can run, so it's better to have 2 cores at 3.5GHz each, than 1 core at 6GHz
So is hyperthreading a hoax, then? Well, here I can't really see the benefits other than marketing ones, since obviously more is better, right
- KVRAF
- 8823 posts since 6 Jan, 2017 from Outer Space
I am not an expert in these questions, but two things regarding your images. Hyperthreading would only double the cores, at least on all processors I know. Then there are usually many more threads than cores on a complex running system. I guess hyperthreading allows to get your demanding application like Bitwig into the last core, which might elsewise be blocked by a less demanding process of the operating system...
When I look at my processor load in activity monitor, it seems hyperthreading is off already... (with 10 real cores it might not be necessary anyway...; - )
When I look at my processor load in activity monitor, it seems hyperthreading is off already... (with 10 real cores it might not be necessary anyway...; - )
- Banned
- Topic Starter
- 11467 posts since 4 Jan, 2017 from Warsaw, Poland
It's important to make distinction between multi-core systems, where there are real multiple cores running at max clock vs. hyperthreading systems, where real cores are split artificially into smaller logical cores, running at half the clock.Tj Shredder wrote:...there are usually many more threads than cores on a complex running system. I guess hyperthreading allows to get your demanding application like Bitwig into the last core, which might elsewise be blocked by a less demanding process of the operating system...
One could say - I have 4 independent calculations to make and only 2 real cores, so let's split them into 4 and we'll have the results faster, because they will be run in parallel, right? What I'm saying is that it's not true, because a) each of 4 cores will run at half the speed that the 2 'full' cores would run at, b) there's some overhead needed to manage that split and scheduling of the tasks, which could result in even worse performance. So - at best - results of all 4 calculations in 4 logical cores hyperthreaded system will be available exactly at the same moment they would with 2 'full' cores.
So, as I said - I don't really see any benefit of using hyperthreading and my testing shows, that (at least in Reason) disabling it improves performance. I'm not saying this will be the case for all projects and/or all CPUs, but - if this option was exposed - we could at least test it ON and OFF and use accordingly.
-
- KVRist
- 364 posts since 29 Mar, 2017
Maybe this is a dumb question, but is it even possible for a program to enable/disable hyperthreading? I never thought about it much, but it seemed like something taken care of in BIOS.
-
- KVRist
- 46 posts since 28 Mar, 2014
The advice from the Linux realtime devs is to avoid hyperthreading, or at least have it turned off in the BIOS. Hyperthreading making scheduling a far more complex task than it would otherwise be - you in effect have the kernel attempting to guarantee cycles to a real-time process, but also have the CPU deciding, independent of the kernel, to switch between processes. Hyperthreading might give you better throughput in some benchmarks, but at the expense of far less deterministic latency.
-
- KVRist
- 303 posts since 9 Mar, 2017
Indeed hyperthreading-aware scheduling is a very complicated topic as in fact even among minor steps in the same CPU you may get different results latency-wise. Not to speak about differences between CPU models/architectures. Also, some plugins may benefit from it some others not.
So IMHO it is easier for Bitwig to remain agnostic and disable it BIOS-wise or in the OS if you really need it.
So IMHO it is easier for Bitwig to remain agnostic and disable it BIOS-wise or in the OS if you really need it.
- Banned
- Topic Starter
- 11467 posts since 4 Jan, 2017 from Warsaw, Poland
Apparently yes, because Reason has that option and it doesn't even require quitting the DAW. The effect is almost immediate and I can see it in Task Manager (i7-6650 4 logical cores running with it ON, 2 physical with it OFF).PhilipVasta wrote:Maybe this is a dumb question, but is it even possible for a program to enable/disable hyperthreading? I never thought about it much, but it seemed like something taken care of in BIOS.
- KVRist
- 76 posts since 28 Mar, 2014 from Poland
doesn't "auto-suspend" (right mouse click on instrument) make it? I mean this function should off the instruments without signal but I don't know if it works correctly
- Banned
- Topic Starter
- 11467 posts since 4 Jan, 2017 from Warsaw, Poland
Are you in the right thread (no pun intended)?_TLG_ wrote:doesn't "auto-suspend" (right mouse click on instrument) make it? I mean this function should off the instruments without signal but I don't know if it works correctly
- KVRist
- 76 posts since 28 Mar, 2014 from Poland
I thought I was, but sorry, maybe I didn't understand the problem. I read it while standing in a jam
-
- KVRer
- 25 posts since 25 May, 2014
You can do this yourself by changing the cpu affinity of the Bitwig audio engine process in the task manager and limiting it only to the "real" cores. On Windows 10 its Ctrl-Shift-Esc -> Details tab -> right click the process and select "Set Affinity".antic604 wrote:Apparently yes, because Reason has that option and it doesn't even require quitting the DAW. The effect is almost immediate and I can see it in Task Manager (i7-6650 4 logical cores running with it ON, 2 physical with it OFF).
On the topic of "HyperThreading does not bring benefits and only makes scheduling more complicated" - this used to be the case before the Haswell architecture. The cores did not have the execution units to really process two threads concurrently. It used to be only a gain if one of the threads on a core had to wait and blocked for something like memory access.
However, with the Haswell architecture Intel added two execution engines (called ports) for the µOps: one integer/branch port and one store port. This makes it possible for the second thread on a core to really do integer calculations and not block the calculations of the first thread.
Since interrupting a thread to schedule a different one is really expensive in terms of CPU cycles, it's in most cases better to let background and management tasks (especially those of your operating system) to run on those HyperThreading cores while your workload thread doesn't have to be interrrupted hard. Just don't expect double the performance.
Here's an article on the CPU architecture changes made with Haswell if you're interested:
https://www.anandtech.com/show/6355/int ... itecture/8
- Banned
- Topic Starter
- 11467 posts since 4 Jan, 2017 from Warsaw, Poland
Thank you, that's a lot of awesome info (most of it flying over my head, though...)jervis wrote:You can do this yourself by changing the cpu affinity of the Bitwig audio engine process in the task manager and limiting it only to the "real" cores. On Windows 10 its Ctrl-Shift-Esc -> Details tab -> right click the process and select "Set Affinity".antic604 wrote:Apparently yes, because Reason has that option and it doesn't even require quitting the DAW. The effect is almost immediate and I can see it in Task Manager (i7-6650 4 logical cores running with it ON, 2 physical with it OFF).
On the topic of "HyperThreading does not bring benefits and only makes scheduling more complicated" - this used to be the case before the Haswell architecture. The cores did not have the execution units to really process two threads concurrently. It used to be only a gain if one of the threads on a core had to wait and blocked for something like memory access.
However, with the Haswell architecture Intel added two execution engines (called ports) for the µOps: one integer/branch port and one store port. This makes it possible for the second thread on a core to really do integer calculations and not block the calculations of the first thread.
Since interrupting a thread to schedule a different one is really expensive in terms of CPU cycles, it's in most cases better to let background and management tasks (especially those of your operating system) to run on those HyperThreading cores while your workload thread doesn't have to be interrrupted hard. Just don't expect double the performance.
Here's an article on the CPU architecture changes made with Haswell if you're interested:
https://www.anandtech.com/show/6355/int ... itecture/8
- Banned
- Topic Starter
- 11467 posts since 4 Jan, 2017 from Warsaw, Poland
I don't think anyone thinks this? Actually, the whole point of this topic was to find out if turning the HT on doesn't bring the overall performance to below 100% of equivalent non-HT CPU, which was the case in my Reason-based test.jervis wrote:Just don't expect double the performance.
So far, here & elsewhere, I heard testimonies in both ways - for some projects / DAWs it improves performance, for others it makes it worse.
-
- KVRer
- 25 posts since 25 May, 2014
You'd be amazed what bullshit marketing people fall for. And back in the day Intel marketing implied performance gains with HyperThreading without actually guaranteeing it. Once software has been optimized for it.antic604 wrote:I don't think anyone thinks this?
But Reason can't disable HyperThreading from an application while the system is running, and can't modify the behaviour of the scheduler or the CPU affinity of system processes and threads. These would get scheduled to the second threads on the cores Reason uses.antic604 wrote:Actually, the whole point of this topic was to find out if turning the HT on doesn't bring the overall performance to below 100% of equivalent non-HT CPU, which was the case in my Reason-based test.
Last edited by jervis on Thu Mar 15, 2018 2:51 pm, edited 2 times in total.