Threadripper Resolve 15 Performance test from Puget Systems.

Hi.

AMD Threadripper 2990WX, 2950X, 1950X and 1920X in DaVinci Resolve 15 Performance test from Puget Systems. Here is a link:

https://www.pugetsystems.com/labs/artic ... ance-1219/

Regards Carsten.

The results are as I expected, Resolve can't fully utilize the High core count cpus. Thus save your money and invest it some place else.

Yep, except 8K RED where 32 cores does help.

Yep, except 8K RED where 32 cores does help.

Even then, it looks more like you're still GPU bound then CPU bound!

Actually, you re right. Look like 16 cores is already enough to decode 8K RED at 25p. Rest is GPUs limitation.

I was going to get a 2950 for my Threadripper build but with the drop in price of the 1920 have that on order. At less than half the price looks like that was a good decision from the test results. They did not specifically mention the RAM used unless I missed that as I know Threadripper is dependent on RAM speed a lot. Most feel the G.Skill3200Cl14 is the best for the Threadripper. Also they may have been better using the cheap Arctic 33TR air cooler than the Corsair cooler too.

Amazed a the Fusion scores as I assumed it needed GPU power.
No significant difference between single and three GPUs?
The humble 6 core 8700K beat everything from 8 to 32 cores?

Would have been interesting to see how dual Xeons compared to new multicore CPUs.

What allows RED to benefit from many cores vs other formats?

They did not specifically mention the RAM used unless I missed that as I know Threadripper is dependent on RAM speed a lot.

Hi.

In the 'Test Setup & Methodology' part in the top do I read that they use 8x DDR4-2666 16GB for (128GB total).

So they don't use DDR4-3200 recommended by the DaVinci Resolve 15 configuration guide and they choose to fill all 8 DIMM sockets up.

Here is a link for Ryzen 7, how important speed wise not to use more than the half of the DIMM sockets.
Ryzen 7 have a two memory channels, and the Threadripper use quad memory channels. But Threadripper is actually two Ryzen 7 dies glued together so I will expect the same reduced memory speed as in the tabke in this link:

https://community.amd.com/community/gam ... zen-system

Regards Carsten.

As much as I appreciate the test of Puget Systems it doesn't tell us that much about the power of the threadripper 2990WX.

First of all both windows and linux still have the do some work to unleash the power of this 32 core beast.

Second they used the 8k.R3D 9:1 25 fps which is the lowest on CPU resources (8k.R3D 5:1 24 fps or 8k.R3D 12:1 60 fps are a lot heavier and cripple a tr1950x). 8k.R3D 9:1 25 fps runs in real-time on an 8k time-line with a TR1950x.

Third the GTX1080ti is limited by it's memory bandwidth (484 GB/s) when it's not limited by it's compute bandwidth (so I hope they will do this test again with TitanV or GTX2080ti or one of the new Quadro's).

Fourth they persist on using DDR4-2666-CL19 while everybody who is buying threadripper knows that he or she needs DDR4-3200-CL14 to unleash the threadrippers potential.

Fifth they used a UHD(4k) time-line, while this makes a lot of sense because almost nobody has an SUHD(8k) monitor, it doesn't show when the tr2990wx get crippled.

Sadly Puget System is the only one doing (and publishing) serious tests concerning resolve and therefore we owe them a big thank you.

What allows RED to benefit from many cores vs other formats?

Good quality programming?

Canseled

The results are as I expected, Resolve can't fully utilize the High core count cpus. Thus save your money and invest it some place else.

I don't think it is that simple as blaming Resolve.

The Windows 10 thread scheduler needs updates to fully work with the Threaripper 2 memory model.

Threadripper 2 benchmarks have been disappointing on Windows 10 across the board compared to Linux.

The results are as I expected, Resolve can't fully utilize the High core count cpus. Thus save your money and invest it some place else.

Not only Resolve - there was little benefit from high core counts on the Puget Premiere Pro benchmarks too. Single apps generally have limited multi-threading capabilities. CPU prices increase with more cores but performance rarely increases proportionally.
https://www.pugetsystems.com/labs/articles/Premiere-Pro-CC-2018-AMD-Threadripper-2990WX-2950X-Performance-1218/

The results are as I expected, Resolve can't fully utilize the High core count cpus. Thus save your money and invest it some place else.

Not only Resolve - there was little benefit from high core counts on the Puget Premiere Pro benchmarks too. Single apps generally have limited multi-threading capabilities. CPU prices increase with more cores but performance rarely increases proportionally.
https://www.pugetsystems.com/labs/articles/Premiere-Pro-CC-2018-AMD-Threadripper-2990WX-2950X-Performance-1218/

Adobe software works best on max 6 core. It's just crap software for modern multi-core computers (not even mentioning the stability of it's software).

Almost all rendersoftware runs significantly fast on the TR2990WX than on any other consumer hardware.
Same counts for many other Linux apps.

https://www.phoronix.com/scan.php?page=article&item=2990wx-linux-scaling&num=1

https://www.phoronix.com/scan.php?page=article&item=2990wx-linwin-scale&num=1

https://www.phoronix.com/scan.php?page=article&item=2990wx-clang-gcc&num=1

Both Microsoft and some of the Linux venders have some work to do on their schedulers.
The GHz race is about over so they have no other choice.

The results are as I expected, Resolve can't fully utilize the High core count cpus. Thus save your money and invest it some place else.

I don't think it is that simple as blaming Resolve.

The Windows 10 thread scheduler needs updates to fully work with the Threaripper 2 memory model.

Threadripper 2 benchmarks have been disappointing on Windows 10 across the board compared to Linux.

I'm not blaming resolve, it's a limitation of the type of work being done.

Parallelization can only be taken so far, at a certain point it doesn't matter how many more cores you throw at it, it won't get any faster. You can actually make a process slower by over parallelizing it.

You need a blend of cores and frequency to move the ball forward!

As much as I appreciate the test of Puget Systems it doesn't tell us that much about the power of the threadripper 2990WX.

Indeed, I could have told you it will decode those files in real time, on that system. I posted in the comments asking for a followup with more difficult media.

The results are as I expected, Resolve can't fully utilize the High core count cpus. Thus save your money and invest it some place else.

I don't think it is that simple as blaming Resolve.

The Windows 10 thread scheduler needs updates to fully work with the Threaripper 2 memory model.

Threadripper 2 benchmarks have been disappointing on Windows 10 across the board compared to Linux.

I'm not blaming resolve, it's a limitation of the type of work being done.

Parallelization can only be taken so far, at a certain point it doesn't matter how many more cores you throw at it, it won't get any faster. You can actually make a process slower by over parallelizing it.

You need a blend of cores and frequency to move the ball forward!

Resolve was not the problem, Resolve scaled perfect upto 64(max for windows 10) cores until DR 14.0.1. After that something happened in Resolve or Windows that it doesn't anymore. I no for sure that the current windows thread scheduler has big problems. I don't know who paid them to cripple the scheduler above 32 threads.
Resolve works almost like a render program like blender, cinema4d etc.. and should be able to scale upto 128 threads and probably even more threads without to many problems.

You are simplifying it a lot.
Fact that a software can saturate 32 cores it still only half of the success. There are apps which can do it, but you gaining eg. 10% of performance compared to eg. 16 cores. What you want is near linear performance scaling with number of cores. If you can do it for 32 cores than your app is good, really good.

You are simplifying it a lot.
Fact that a software can saturate 32 cores it still only half of the success. There are apps which can do it, but you gaining eg. 10% of performance compared to eg. 16 cores. What you want is near linear performance scaling with number of cores. If you can do it for 32 cores than your app is good, really good.

Just look at a lot of render programs, they scale really good, and DR is for a big part a render program that upto 14.0.1 scaled really good.

https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=70646

Render programs are very specific group, which in most cases freely divide frame into as many chunks as they want. They are about the only group (out of video image/related) which can uses many cores well.
You have to add all elements- first load source data (render apps quite often read nothing), decode source (again- not really happening in render apps), do processing (quite often temporal in Resolve), optionally send data to external preview (which is very specific and require data to be pushed from GPU), export (in most cases compressed format which has limited parallelisation). Sorry, but Resolve is far form typical render app.
Resolve will NEVER scale as well as rendering apps. Fact that rendering apps spent a lot of time doing single frame (days sometimes ) is one of the key elements (in such a case even if you have to read/write data those processes are totally "covered" by time which takes to "generate" frame).

Maybe Resolve v15 got worse, I'm not arguing with this. I don't think Resolve code is very optimal, but it will never match render apps for sure, even if you spent a lot of time and money on it.

Andrew,

When software will never scale(much) better than currently possible we have a huge problem, the GHz race is over and the only way left to speed up things is doing them in parallel.

You have to change approach then. Re-think, re-desing or find other technology which can operate at higher GHz. There I still few GHz left.

Biggest problem is that most apps still run on engines made many years ago. Adobe use to be crap with patching their code instead of writing new one. Then when you have complex app it's to expensive to re-write it every 3 years

Adobe use to be crap with patching their code instead of writing new one. Then when you have complex app it's to expensive to re-write it every 3 years

Used to be crap, huh?

Well still is, but at least it's slightly better. Use to be really crap.

Some more info about Linux TR2990WX

You can go on all you want about this operating system or that operating system, but I went to school for this type of thing. Specifically computational physics and mathematics, I worked on these types of problems at a fundamental level.

Nothing scales linearly, and I mean nothing.

• Some tasks can't be parallelized at all.
• some task drastically loose efficiency when broken up over a handful of workers
• Some tasks can scale well up into the hundreds of workers range
• Some tasks like CFD can scale well up in to the 10's of thousands of workers range.

audio/Video manipulation is not something that scales well.

Current technology is well in to the realm of diminishing returns. Frequency isn't going to substantially increase anymore, so the industry is employing a stop gap measure of throwing more cores at the problem in the hopes that parallellizing as much as possible can by them time. This is why people are working on concepts like Quantum computing, as they need to come up with something completely new if they want to keep moving the ball forward.

audio/Video manipulation is not something that scales well.

I can't say I agree with that. Especially video parallelizes just fine!

Frequency isn't going to substantially increase anymore, so the industry is employing a stop gap measure of throwing more cores at the problem in the hopes that parallellizing as much as possible can by them time. This is why people are working on concepts like Quantum computing, as they need to come up with something completely new if they want to keep moving the ball forward.

If you think that parallelizing is a stop gap be prepared for quantum computing, that's are all about super parallelizing things.

You can go on all you want about this operating system or that operating system, but I went to school for this type of thing. Specifically computational physics and mathematics, I worked on these types of problems at a fundamental level.

Nothing scales linearly, and I mean nothing.

• Some tasks can't be parallelized at all.
• some task drastically loose efficiency when broken up over a handful of workers
• Some tasks can scale well up into the hundreds of workers range
• Some tasks like CFD can scale well up in to the 10's of thousands of workers range.

audio/Video manipulation is not something that scales well.

Current technology is well in to the realm of diminishing returns. Frequency isn't going to substantially increase anymore, so the industry is employing a stop gap measure of throwing more cores at the problem in the hopes that parallellizing as much as possible can by them time. This is why people are working on concepts like Quantum computing, as they need to come up with something completely new if they want to keep moving the ball forward.

+1 Thanks Dan - Agreed -
Silicon technology hit the wall many years ago. Intel even dropped their "tick/tock" incremental improvements marketing. Not so long ago we became accustomed to CPU power doubling every 18-24 months at the same price thanks to Moore's Law which also died.
AMDs marketing has been "if 4 cores are good, then 8, 16, or 32 must be better" which is misleading the consumer market for the reasons you mentioned.
There have been rumours of a silicon replacement like carbon nano but any new technology takes at least 5 years to reach the market and Quantum computing, like Quantum Physics, is beyond my ability to comprehend. I'm not holding my breath for any major CPU developments in the foreseeable future.

I don't have your computational physics or mathematics background but I started on mainframes in the 60s and have owned and built PCs for decades.

Here is a layman's explanation from 2011/12 of the history of computing, microprocessors, multi-cores, parallelism etc any why technology hit the wall - actually three walls.
The future of computers - Part 1: Multicore and the Memory Wall
https://www.edn.com/design/systems-design/4368705/The-future-of-computers--Part-1-Multicore-and-the-Memory-Wall
Future of computers - Part 2: The Power Wall
https://www.edn.com/design/systems-design/4368858/Future-of-computers--Part-2-The-Power-Wall
Future of computing - Part 3: The ILP Wall and pipelines
https://www.edn.com/design/systems-design/4368983/Future-of-computing--Part-3-The-ILP-Wall-and-pipelines

From IEEE - https://spectrum.ieee.org/view-from-the-valley/computing/hardware/david-patterson-says-its-time-for-new-computer-architectures-and-software-languages

"That’s because Moore’s Law really is over, he says: “We are now a factor of 15 behind where we should be if Moore’s Law were still operative. We are in the post–Moore’s Law era.”

This means, Patterson told engineers attending the 2018 @Scale Conference held in San Jose last week, that “we’re at the end of the performance scaling that we are used to. When performance doubled every 18 months, people would throw out their desktop computers that were working fine because a friend’s new computer was so much faster.”

But last year, he said, “single program performance only grew 3 percent, so it’s doubling every 20 years. If you are just sitting there waiting for chips to get faster, you are going to have to wait a long time.”

audio/Video manipulation is not something that scales well.

I can't say I agree with that. Especially video parallelizes just fine!

Some bits may scale fairly well (like resizing), but others scale badly. If this would not be true your 16 cores would fly and gain per core would be about linear. If you split single frame, you hit smallest chunk problem. When you processing frames, you hit memory issues (+ problem with temporal filters). Many cores are not good for process which last relatively short time (like video processing). When processes take long time (eg. some advanced computing) then multicore overhead diminishes.

If you think that parallelizing is a stop gap be prepared for quantum computing, that's are all about super parallelizing things.

I think you have no idea about what you're talking about. I suggest you research interference, entanglement, and superposition, to get started.

audio/Video manipulation is not something that scales well.

I can't say I agree with that. Especially video parallelizes just fine!

Some bits may scale fairly well (like resizing), but others scale badly. If this would not be true your 16 cores would fly and gain per core would be about linear. If you split single frame, you hit smallest chunk problem. When you processing frames, you hit memory issues (+ problem with temporal filters). Many cores are not good for process which last relatively short time (like video processing). When processes take long time (eg. some advanced computing) then multicore overhead diminishes.

I just added another GPU with 3584 CUDA cores, and those cores are much more limited than CPU cores and guess what, it works really well.

Threadripper 2 has a different memory configuration, only two dies have direct memory access. For that, the Windows scheduler needs to make some adjustments.

[/quote]
Threadripper 2 has a different memory cofiguration, only two dis have direct memory access. For that, the Windows scheduler needs to make some adjustments.[/quote]

I think that the 1920 and 1950 have the same memory configuration as the 2920 and 2950. No change for the 12 and 16 core parts.The difference is that with 4 dies working on the 2924 and 2990 they still only have the two dies having memory access. The Infinity Fabric has to be used for these dies to get access through the two dies that have direct memory access. Bear in mind that these dies too may ask each other for access to the memory they have direct access to. This also applies to PCIe access too. So how programs use memory and which PCIe slots are used is important for ultimate speed. Fastest will be to use memory attached to the cores used and direct PCIe both for storage and GPU. Games mode drives the configuration this way and effectively turns the Threadripper into an 8 core !!!

And the funny thing is that it runs on Linux like the fire brigade, superfast with speeds never seen bevor from a single CPU-system.

And the funny thing is that it runs on Linux like the fire brigade, superfast with speeds never seen bevor from a single CPU-system.

Yes, indeed. I really want to see a test with 3200MHz CL14 RAM with difficult 8K R3D on a Linux resolve system.