2017/03/20 14:09:48
Jim Roseberry
Now that some other quality X370 motherboards have become available, I wanted to go back and re-test the Ryzen 1800x... to see if it's low-latency (audio) performance had improved.
 
Unlike the first build (used an Asus X370 motherboard), the ASRock X370 motherboard wasn't flakey in any way.
Even the first revision BIOS was solid (no flakey behavior like with the Asus - where SMT disappeared).
I'll attribute this to the motherboard not being rushed out... to meet the Ryzen release deadline.
 
On to stress-testing:
 
Decided to use DAW Bench since many folks are familiar with it.
Audio interface was a RME Fireface UFX set to a 48-sample ASIO buffer size.
 
Loaded the DAW Bench test into Reaper (using their multi-band compressor plugin to create CPU load).
The 1800x was able to playback the stress-test (glitch-free) with 170 instances of the multi-band compressor.
Idle CPU use was 89%.  With the transport running, CPU use was 93%.
 
The same stress-test with the I7-6850k (also a $500 CPU):
The 6850k could run 223 instances of the multi-band compressor... and audio was glitch-free.
Idle CPU use was 98%.  With the transport running, CPU use was 99%.
 
Nowadays, $500 buys a lot of CPU.
If your primary purpose is working with low-latency audio, you're definitely better off with the 6850k.
You can run more DSP at a given percentage load... and you can push the overall load higher.
 
Passmark CPU benchmarks:
                             1800x          6850k
Floating Point:        16,126          12,212
Integer Math:         43,898          29,468
Single Thread:        2,104             2,335
 
If you just take the generic CPU benchmarks as gospel, you'd think the 1800x would smoke the 6850k.
Low-latency specific audio benchmark testing is important.  
2017/03/20 23:59:32
Bhav
In the UK the 6850k is £50+ more than the 1800x, so the latter could still be worth it as the performance isnt too far off, plus it has two extra cores but those arent useful until a programme uses them all.
 
Id say if the Ryzens were £100 less than the nearest Intel chip instead, then they would be seriously good value.
 
At least the Ryzens werent good enough to induce buyers remorse as I upgraded to the 6850k and my expensive mobo right when they came out.
2017/03/21 00:59:20
mettelus
Which ASRock board did you run Jim? The Taichi or Fatal1ty? I am assuming one or the other, but didn't see one posted. It is heartening to see that some of the issues may be MB related. If true to form, it will take 6 months or so to get the MB and BIOS hammered out.
2017/03/21 03:41:09
Jim Roseberry
It was the Fatal1ty.
Much better motherboard than the Asus.
There was no trace of flaky behavior.
 
$500 isn't a budget CPU.
If you're working with low-latency audio, the 6850k offers significant performance benefit.
 
I'll post results from the 7700k tomorrow.  
2017/03/21 13:52:51
mettelus
Thanks Jim. Here is another question for you, perhaps it should be in its own thread, but this is a good spot.
 
One thing that always bothers me is that the CPUBenchmark listing does not show a normalized listing as well. The reason I say this is that architecture aside (which is playing into the overall score), the load on a single physical core is really "what matters" (because a thread will most often be locked to one-core performance), with the assumption that the architecture can support it. Example:
 
i7-2600K (mine) benches at 8479   which is 2119.8 per physical core (4)
i7-6850K           benches at 14495 which is 2415.8 per physical core (6), but...
Ryzen 7 1800x  benches at 15419 which is 1927.4 per physical core (8), and the kicker...
Xeon E5-2679 V4 (the TOP DOG) benches at 25236 which is 1261.8 per phisical core (20)
 
That normalization is not done, so that list gets messy now with 4/6/8/+ core CPUs listed together. Power consumption per core could be the same way. Although the aggregate does carry a lot of weight (combined processing power, supporting architecture, etc.), there are very often situations where 1 physical core is required to do the grunt work all by itself. This is actually by thread, but for calculations I used cores.
 
Video and encryption softwares are written to max out the use of all available resources, so they will always do higher with more exposed cores, but the programs not written this way will be limited to the perfomance of the single cores if "isolated," as it were.
 
Food for thought anyway, but the architecture is a lot of the "speed" and the CPUs themselves are not gaining ground at even the rate Intel claims when normalized. (i.e., *if* my lowly 2600K CPU had 6 cores with supporting architecture, it would only bench 12% less than the 6850K, which is 5 years newer).
 
2017/03/21 14:16:56
Jim Roseberry
Passmark does have a Single-Thread test option.
In that test, the 6850k is faster than the 1800x.
 
Another factor is how well the CPU performs at low-latency.
This is a particularly weak area for Ryzen.
If you just looked at generic benchmarks, you'd expect the 1800x to smoke the 6850k.
It beats the 6850k handily at Floating Point and stomps it at Integer Math.
This is why audio specific stress-testing is important.
 
Image Line posted on KVR recently... and that post is relevant to this conversation.
 
From that Image Line post:
Interesting conversation, and one we often have with our customers in conjunction with system vs DAW CPU load...two issues to consider:

Time-scales

The audio buffer size, 1 ~ 50 ms. While the operating systems CPU meter may show 30% utilization, over the last 1000 ms (system meters are around 1 sec integration), there may have been multiple occasions during that period where real-time audio processing experienced interruptions. Why? If real-time audio 'Mixer threads' (packages of work for the CPU), have to wait on other threads to finish, because they can't be multi-threaded (processed at the same time), the DAW may experience audio underruns, or at least very high internal CPU meter readings. At the same time, the OS may report low overall and or individual CPU utilization. The CPU could have done a lot more work than it did, if it had something else to do at the same time. The reality for audio processing is the CPU must often wait for program and system related tasks to complete before it can continue, and so, may struggle to keep up with the very high demands of realtime audio output (generating 44100 samples per second, on an ongoing basis, without an interruption of a single sample, 0.02 ms). Just why the CPU must 'wait' is all to do with logic:

The logic of audio processing

There are long lists of tasks that must be processed in sequence, and this means logically can't be simultaneously multithreaded. For example: Plugins must wait for instructions from the Piano roll and Playlist before they make sound. Effects must wait for the audio stream from upstream instrument plugins before they can process it. Further, it's not possible to parallel-process (multithread) instruments and FX that are on the same Mixer channel (their audio is mixed together), or even in the same Mixer routing pipe-line (when one Mixer track is linked to another and another, even FX processing has an order from top to bottom in the FX stack). Then, the Master Mixer track must wait for every instrument > mixer track > effect to be processed before it can process the audio through the Master effects. Logically, there is a lot of waiting, that is a natural and unavoidable fact of DAW music processing. 

Think of a production line. This means the CPU may not be particularly busy, using all its cores and processing slots, yet it runs out of time to fill that tiny 5 ms audio-buffer because there was a lot of waiting for things that needed to be processed in sequence. It should be clear that fast processing is very important and this is not the same thing as multi-core processing. The best CPU is one that has enough cores to spread the work around AND can do the most work on a single core during each buffer time-slice. Which leads to our TIP: When comparing CPUs, look for the fastest single-core performance scores in a package with at least 4 physical cores. Most CPU benchmarks list single core performance. For example, the CPU Benchmark website lists the single core scores.
 
 
2017/03/21 14:34:19
Jim Roseberry
My posts are being removed.
Bizarre...
2017/03/21 14:34:58
Jim Roseberry
Passmark does have a Single-Thread test option.
In that test, the 6850k is faster than the 1800x.
 
Another factor is how well the CPU performs at low-latency.
This is a particularly weak area for Ryzen.
If you just looked at generic benchmarks, you'd expect the 1800x to smoke the 6850k.
It beats the 6850k handily at Floating Point and stomps it at Integer Math.
This is why audio specific stress-testing is important.
2017/03/21 14:35:23
Jim Roseberry
Image Line posted on KVR recently... and that post is relevant to this conversation.
 
From that Image Line post:
"Interesting conversation, and one we often have with our customers in conjunction with system vs DAW CPU load...two issues to consider:

Time-scales

The audio buffer size, 1 ~ 50 ms. While the operating systems CPU meter may show 30% utilization, over the last 1000 ms (system meters are around 1 sec integration), there may have been multiple occasions during that period where real-time audio processing experienced interruptions. Why? If real-time audio 'Mixer threads' (packages of work for the CPU), have to wait on other threads to finish, because they can't be multi-threaded (processed at the same time), the DAW may experience audio underruns, or at least very high internal CPU meter readings. At the same time, the OS may report low overall and or individual CPU utilization. The CPU could have done a lot more work than it did, if it had something else to do at the same time. The reality for audio processing is the CPU must often wait for program and system related tasks to complete before it can continue, and so, may struggle to keep up with the very high demands of realtime audio output (generating 44100 samples per second, on an ongoing basis, without an interruption of a single sample, 0.02 ms). Just why the CPU must 'wait' is all to do with logic:

The logic of audio processing

There are long lists of tasks that must be processed in sequence, and this means logically can't be simultaneously multithreaded. For example: Plugins must wait for instructions from the Piano roll and Playlist before they make sound. Effects must wait for the audio stream from upstream instrument plugins before they can process it. Further, it's not possible to parallel-process (multithread) instruments and FX that are on the same Mixer channel (their audio is mixed together), or even in the same Mixer routing pipe-line (when one Mixer track is linked to another and another, even FX processing has an order from top to bottom in the FX stack). Then, the Master Mixer track must wait for every instrument > mixer track > effect to be processed before it can process the audio through the Master effects. Logically, there is a lot of waiting, that is a natural and unavoidable fact of DAW music processing. 

Think of a production line. This means the CPU may not be particularly busy, using all its cores and processing slots, yet it runs out of time to fill that tiny 5 ms audio-buffer because there was a lot of waiting for things that needed to be processed in sequence. It should be clear that fast processing is very important and this is not the same thing as multi-core processing. The best CPU is one that has enough cores to spread the work around AND can do the most work on a single core during each buffer time-slice. Which leads to our TIP: When comparing CPUs, look for the fastest single-core performance scores in a package with at least 4 physical cores. Most CPU benchmarks list single core performance. For example, the CPU Benchmark website lists the single core scores."
2017/03/22 10:19:30
Karyn
Akismet was having a bad day Jim,  I've restored the first "lost" post.
12
© 2024 APG vNext Commercial Version 5.1

Use My Existing Forum Account

Use My Social Media Account