Xeon vs i7/i9...which CPU when?
-
- KVRAF
- Topic Starter
- 1586 posts since 7 Jun, 2007
Hi guys,
Apologies if this seems lazy, but sometimes asking is quickest. I need some clarity as to when a Xeon processor is more beneficial for digital media production than a fast i7 processor.
I'm looking at these scenarios:
- composing with heavyweight polyphonic softsynths (not samplers) such as Diva (my assumption here is that polyphony requires/works better with multi-core/hyperthreading support)
- mixing audio tracks using vst effects (ie: synth parts already bounced to audio)
- video editing and rendering
- 3D modelling and rendering (in blender)
My understanding so far is that (broadly speaking) Xeons work better for non-realtime number crunching, such as rendering video, but i7's are better for intensive realtime processing, such as music production.
Any correction, clarification, and insights are welcome. Thanks!
Apologies if this seems lazy, but sometimes asking is quickest. I need some clarity as to when a Xeon processor is more beneficial for digital media production than a fast i7 processor.
I'm looking at these scenarios:
- composing with heavyweight polyphonic softsynths (not samplers) such as Diva (my assumption here is that polyphony requires/works better with multi-core/hyperthreading support)
- mixing audio tracks using vst effects (ie: synth parts already bounced to audio)
- video editing and rendering
- 3D modelling and rendering (in blender)
My understanding so far is that (broadly speaking) Xeons work better for non-realtime number crunching, such as rendering video, but i7's are better for intensive realtime processing, such as music production.
Any correction, clarification, and insights are welcome. Thanks!
Last edited by xalama qo on Thu Jun 01, 2017 12:19 pm, edited 1 time in total.
- KVRAF
- 2338 posts since 28 Feb, 2015
I can say for rendering (Blender), no CPU can beat a 1080 Ti as far as I know. I have 3x780 today, and it's far superior to my i7 6 core CPU.
I will let others answer regarding music production, but I believe an i7/i9 will always be the better choice over Xeon, which often have more cores, but works at a lower frequency.
Not many plugins have the multi-core support that i.e. the u-he plugins have.
I will let others answer regarding music production, but I believe an i7/i9 will always be the better choice over Xeon, which often have more cores, but works at a lower frequency.
Not many plugins have the multi-core support that i.e. the u-he plugins have.
i9-10900K | 128GB DDR4 | RTX 3090 | Arturia AudioFuse/KeyLab mkII/SparkLE | PreSonus ATOM/ATOM SQ | Studio One | Reason | Bitwig Studio | Reaper | Renoise | FL Studio | ~900 VSTs | 300+ REs
- KVRist
- 251 posts since 7 Feb, 2017
I think the multi-core gains occur even before the plugin-level as most DAWs have multi-threading support and will load the plugins / process stems from a thread-pool.starflakeprj wrote: Not many plugins have the multi-core support that i.e. the u-he plugins have.
- KVRAF
- 4590 posts since 7 Jun, 2012 from Warsaw
DAWs and (some) plugins can easily adapt a large number of cores. Just look at actual performance in benchmarks to get a clue. Xeon or i7 models can vary a lot between generations.
Now I use 8-core Ryzen and all the cores are occupied equally. However, project rendering in Ableton still utilizes only one thread, which is a bottleneck in my case You might consider single-thread performance as well if that's you use case.
Now I use 8-core Ryzen and all the cores are occupied equally. However, project rendering in Ableton still utilizes only one thread, which is a bottleneck in my case You might consider single-thread performance as well if that's you use case.
Blog ------------- YouTube channel
Tricky-Loops wrote: (...)someone like Armin van Buuren who claims to make a track in half an hour and all his songs sound somewhat boring(...)
Tricky-Loops wrote: (...)someone like Armin van Buuren who claims to make a track in half an hour and all his songs sound somewhat boring(...)
-
- KVRAF
- 1929 posts since 4 Nov, 2004 from Manchester
The Xeons are as efficient as the i7's if you are using a single chip, after all the is very little difference between them other than more QPI lanes. It's when you have multiple chips that you run in to hard NUMA addressing overheads that start to make the Xeons less efficient.
If the is an i7 with the sames specs as the Xeon and it's cheaper, get the i7. If the xeon is cheaper for a single chip (rare, but it does happen) get the Xeon (assuming you don't wish to overclock).
If you feel you want to dual xeon, be aware that you might lose anything up to 20% of the processing overhead and the extra cost of the board and ecc memory normally means you'd have to spend a sizeable chunk more only to receive less performance.
If the is an i7 with the sames specs as the Xeon and it's cheaper, get the i7. If the xeon is cheaper for a single chip (rare, but it does happen) get the Xeon (assuming you don't wish to overclock).
If you feel you want to dual xeon, be aware that you might lose anything up to 20% of the processing overhead and the extra cost of the board and ecc memory normally means you'd have to spend a sizeable chunk more only to receive less performance.
-
- Banned
- 411 posts since 17 Jan, 2007
Thanks for that, Pete. Sage advice, as per usual.Kaine wrote:The Xeons are as efficient as the i7's if you are using a single chip, after all the is very little difference between them other than more QPI lanes. It's when you have multiple chips that you run in to hard NUMA addressing overheads that start to make the Xeons less efficient.
If the is an i7 with the sames specs as the Xeon and it's cheaper, get the i7. If the xeon is cheaper for a single chip (rare, but it does happen) get the Xeon (assuming you don't wish to overclock).
If you feel you want to dual xeon, be aware that you might lose anything up to 20% of the processing overhead and the extra cost of the board and ecc memory normally means you'd have to spend a sizeable chunk more only to receive less performance.
-
- KVRAF
- 3318 posts since 16 Jan, 2005 from Ottawa, Ontario
Kaine wrote:
...
If you feel you want to dual xeon, be aware that you might lose anything up to 20% of the processing overhead and the extra cost of the board and ecc memory normally means you'd have to spend a sizeable chunk more only to receive less performance.
Why would this be if your sequencer can use all the cores available? ...you said it yourself, they're mostly alike apart from qpi lanes, so if you can access two 8 cores, instead of one, I would have thought there was only a little more latency to deal with. What's the thing...here??
http://www.dawbench.com/dawbenchdsp-i7part1.htm
-
- KVRAF
- 3318 posts since 16 Jan, 2005 from Ottawa, Ontario
Kaine wrote:
...
If you feel you want to dual xeon, be aware that you might lose anything up to 20% of the processing overhead and the extra cost of the board and ecc memory normally means you'd have to spend a sizeable chunk more only to receive less performance.
Why would this be if your sequencer can use all the cores available? ...you said it yourself, they're mostly alike apart from qpi lanes, so if you can access two 8 cores, instead of one, I would have thought there was only a little more latency to deal with. What's the thing...here??
http://www.dawbench.com/dawbenchdsp-i7part1.htm
Last edited by Debutante on Sun Jun 04, 2017 6:30 am, edited 2 times in total.
- KVRian
- 652 posts since 2 Mar, 2015 from UK
The thing that worries me about too many cores is from the others produced the Mhz gets lower as they add more cores. In Ableton live each track is given its own core to run on some tracks will hardly tax the core while others the core will struggle. The trick is buying a CPU with more cores + each core is far more powerful than any in the CPU you have now.
-
- KVRAF
- 1929 posts since 4 Nov, 2004 from Manchester
It's not the processor that's the problem in this scenario.Debutante wrote:Why would this be if your sequencer can use all the cores available? ...you said it yourself, they're mostly alike apart from qpi lanes, so if you can access two 8 cores, instead of one, I would have thought there was only a little more latency to deal with. What's the thing...here??Kaine wrote: If you feel you want to dual xeon, be aware that you might lose anything up to 20% of the processing overhead and the extra cost of the board and ecc memory normally means you'd have to spend a sizeable chunk more only to receive less performance.
http://www.dawbench.com/dawbenchdsp-i7part1.htm
If you want the long explanation on NUMA arrangement : http://queue.acm.org/detail.cfm?id=2852078
Tl;dr
I'm going to compare the enthusiast range (X99 i7) against the Xeon.
Both are quad channel in this instance but the Xeon configuration has twice as many banks with the total figure being split between the two CPU's.
In the ideal world CPU 0 would use Banks 1 + 2 and CPU 1 would use Banks 3 + 4.
These would be arranged so that the cores had the shortest possible distance to cover when sending and recalling data.
When the CPU's address their own optimized cores and ONLY their own optimized cores we see the most efficient level of throughput.
However memory channels get full up and start to overload as a project get busier and as soon as one maxes out, it'll start to load balance onto the least used bank. If that bank is attached to the same CPU, then the performance drop is minimal (if any), but if that data is then shifted to another bank completely then the outcome is that the latency time to recall may double or even triple due to the distance it has to cover when recalling it.
Ultimately this is fraction of a microsecond, but if that happens 1000's of times a microsecond (which it does) then the cores that have already actioned have to wait for the lagged data to catch up or it has to dispose of it. One of those equals overhead loss where the other equals audio drop outs.
This isn't the sequencer, this is the OS and a problem that all platforms have been trying to optimize for, for years. It's not such a big deal when it comes servers and databases with no need for real time handling, but for audio where buffers have strict time limits on how quickly they process the data it can be a little more problematic.
-
- KVRAF
- 3318 posts since 16 Jan, 2005 from Ottawa, Ontario
This is why KVR is great sometimes. Fully understood and a great link t boot. Thanks!!Kaine wrote:It's not the processor that's the problem in this scenario.Debutante wrote:Why would this be if your sequencer can use all the cores available? ...you said it yourself, they're mostly alike apart from qpi lanes, so if you can access two 8 cores, instead of one, I would have thought there was only a little more latency to deal with. What's the thing...here??Kaine wrote: If you feel you want to dual xeon, be aware that you might lose anything up to 20% of the processing overhead and the extra cost of the board and ecc memory normally means you'd have to spend a sizeable chunk more only to receive less performance.
http://www.dawbench.com/dawbenchdsp-i7part1.htm
If you want the long explanation on NUMA arrangement : http://queue.acm.org/detail.cfm?id=2852078
Tl;dr
I'm going to compare the enthusiast range (X99 i7) against the Xeon.
Both are quad channel in this instance but the Xeon configuration has twice as many banks with the total figure being split between the two CPU's.
In the ideal world CPU 0 would use Banks 1 + 2 and CPU 1 would use Banks 3 + 4.
These would be arranged so that the cores had the shortest possible distance to cover when sending and recalling data.
When the CPU's address their own optimized cores and ONLY their own optimized cores we see the most efficient level of throughput.
However memory channels get full up and start to overload as a project get busier and as soon as one maxes out, it'll start to load balance onto the least used bank. If that bank is attached to the same CPU, then the performance drop is minimal (if any), but if that data is then shifted to another bank completely then the outcome is that the latency time to recall may double or even triple due to the distance it has to cover when recalling it.
Ultimately this is fraction of a microsecond, but if that happens 1000's of times a microsecond (which it does) then the cores that have already actioned have to wait for the lagged data to catch up or it has to dispose of it. One of those equals overhead loss where the other equals audio drop outs.
This isn't the sequencer, this is the OS and a problem that all platforms have been trying to optimize for, for years. It's not such a big deal when it comes servers and databases with no need for real time handling, but for audio where buffers have strict time limits on how quickly they process the data it can be a little more problematic.