benchmarking Neat DeNoiser on an iMacPro??

… pure academic interest, no Neat nor iMp here, but Q came up in some private discussion:

Did anyone post numbers, how the famous 'CPU eater' NeatVideo compares btw a regular iMac vs. an iMacPro?

Karsten Schlüter wrote: … pure academic interest, no Neat nor iMp here, but Q came up in some private discussion: Did anyone post numbers, how the famous 'CPU eater' NeatVideo compares btw a regular iMac vs. an iMacPro?

I've tested this plus some other compute-intensive effects on my 10-core Vega 64 iMac Pro vs my top-spec 2017 iMac 2017.

Neat Video 4.7: using the optimal config of CPU cores and GPU recommended by the tool Tools>Preferences>Performance>"Optimize Performance Settings". This built-in Neat Video test evaluates all combinations of CPU cores and GPU to recommend the best configuration, and lists the frames/sec of each one. On 4k H264/29.97 material, this was:

iMac Pro: 10 CPU cores + Vega 64: 5.29 frames/sec
2017 iMac: 5 cores + Radeon Pro 580: 2.76 frames/sec

Note the test evaluates all hyperthreaded virtual cores so this is 20 on the 10-core Xeon and 8 on the 4-core i7-7700K in the iMac.

A similar slow-running compute-bound test is Digital Anarchy's Flicker Free. To de-flicker 10 sec of 4k H264/29.97 material this was:

iMac Pro: 5 min 9 sec
2017 iMac: 6 min 31 sec

Another very compute-bound effect is Imagenomic Portraiture, which does skin smoothing. On the same 10-sec 4k clip, this took:

iMac Pro: 1 min 7 sec
2017 iMac: 1 min 10 sec

While effects often claim to be "GPU accelerated", both Flicker Free and Portraiture seem to be mostly CPU bound. I don't know why Portraiture wasn't much faster on the iMP.

However this situation is typical. In recent years performance evaluation has become much more complex due to higher core-count CPUs, GPU and specialized accelerators like Quick Sync. Software which harnesses those effectively is much faster.

An extreme example is FCPX 10.4 export performance on 10-bit 4k HEVC: it is 32x slower than 8-bit, which indicates it's not using the AMD UVD/VCE transcoding hardware for 10-bit encoding.

Joema, I have a similar spec iMac Pro - 10-core, 3 GHz Intel Xeon W, Radeon Pro Vega 64 16 GB, 64 GB 2666 MHz DDR4 - and I get similar scores as you've posted running Neat Video 4.7 on 4k material. However, Neat Video consistently crashes FCPX when I try to run Preference>Optimize or process 8K material. I have contacted Neat Video support and we are trying to isolate/resolve this issue. Have you had any problems or testing with >4k footage?

BTW, the NeatBench standalone command line tool reports no problems for my system and configuration.

thinkfilm wrote: ... Neat Video consistently crashes FCPX when I try to run Preference>Optimize or process 8K material. I have contacted Neat Video support and we are trying to isolate/resolve this issue. Have you had any problems or testing with >4k footage?...

I haven't tried it on 8k material, so I have nothing to report. As a workaround you could try blindly setting it to use 10 CPU cores and no GPU, or only GPU and no CPU. Maybe you could find a combination that doesn't crash.

There are other video noise reduction products, although Neat is the best. BorisFX has one: web.borisfx.com/helpdocs/?page_id=1019

Another option is investigate whether the codec makes any difference. If your 8k material is H264 or RED, you could try transcoding that to ProRes before applying Neat.

Yes, I have been able to set the CPU only so that Neat Video processes the clip ok - just much more slowly of course. It seems there is something at issue when the GPU kicks in alone or in combo with the CPU. I've also tried to specify the percentage of the GPU that Neat Video can access - still no luck. Neat Video seems to initialize the AMD GPU driver ok so perhaps it may be related to the properties of the clip. Neat Video's support has been very responsive to me so perhaps we will resolve this issue.

Otherwise, I'm quite happy with Neat Video - it handles any other material just fine. As you say it seems to be the best in its class for noise reduction.

FWIW, the material I've been testing with is ProRes HQ - originally a RED RCD file graded in and exported from DaVinci Resolve as ProRes HQ.

BTW, Karsten, I apologize if I've veered from the original topic of this thread. I can start another.

joema wrote: // full quote //.

Thanks Joe, interesting numbers… and, a bit underwhelming, isn't it?
ok, 'twice as fast' is impressive,esp on longer projects - but with all the cores, and Xeons and wotnot… as a complete idiot on hardware, I would have expected … more.

What do you think: is this a lack of 'optimizing' on Neats side, or an OS/FinalCut issue? Who's in charge to make more use of all the 'power' in the beast?

Karsten Schlüter wrote: ...ok, 'twice as fast' is impressive,esp on longer projects - but with all the cores, and Xeons and wotnot… as a complete idiot on hardware, I would have expected … more.

What do you think: is this a lack of 'optimizing' on Neats side, or an OS/FinalCut issue? Who's in charge to make more use of all the 'power' in the beast?

Neat is actually doing a pretty good job. The 10-core iMP was nearly 2x faster than the 4-core iMac, which has a higher base clock speed. Even for perfectly-written software running on perfect hardware with zero bus or cache contention, multi-core scalability will fall off at higher core counts if the algorithm requires any synchronization. This is Amdahl's Law: en.wikipedia.org/wiki/Amdahl%27s_law

Neat also sizes GPU vs CPU performance and lets you select the optimum mix. Almost no other app or plugin does that.

So the question is why the other apps and plugins are not any better on the iMP. Even within a single app the results vary. Lightroom 7.2 import and 1:1 preview creation is about 30% faster on the iMP vs 2017 iMac. Not great but it's faster. However changing sharpening in a correction brush is no faster, and becomes about 3x faster if you disable Lightroom GPU acceleration -- on both iMP and iMac. Obviously a total software foul-up by Adobe.

For some things FCPX is significantly faster on the iMP vs 2017 iMac, for other things about the same and for a few things it's slower. The slower things usually involve handling certain types of H264.

Re whose fault it is, that is complex. Programmers must get better at writing multi-threaded code and using available hardware accelerators like Quick Sync and AMD's similar UVD/VCE. However this can be limited by available programming frameworks and development environments.

On the "personal computer" platform it's been possible to write efficient multi-threaded code which was preemptively scheduled since Windows NT in 1993. Macs did not get this until OS X was released in 2001. However there initially was little programmer support for this and developers had to manually manage their own threads and synchronization, which was very difficult: developer.apple.com/library/content/docu...ty/ThreadSafety.html

Apple did not address this until Grand Central Dispatch in 2009: en.wikipedia.org/wiki/Grand_Central_Dispatch : developer.apple.com/library/content/docu...TP40008091-CH100-SW1

Microsoft did not release .NET Framework 4 which simplified multi-threaded development until 2010: docs.microsoft.com/en-us/dotnet/standard...parallel-library-tpl

That was years ago, why isn't everything perfect today? Partially it's conflicting priorities -- programmers are under the gun to deliver features marketing wants. When CPUs were getting dramatically faster each year, and the installed base of 4 core and higher machines was limited, there was less incentive to improve application thread concurrency.

Today that's vitally important but sometimes cross-platform issues may impeded this. E.g, a developer of cross-platform software who uses Grand Central Dispatch can't use this on Windows. I'm not sure if a .NET Framework 4 app using Task Parallel Libraries can be ported to macOS. In theory the developer could write to some kind of higher-level cross-platform framework, but I don't know how robustly those support concurrent multi-threaded programming, exception handling and debugging.

FCPX isn't cross platform, so doesn't have that burden. Maybe that's why it's so much faster than Premiere (in general). But even a single-platform app must make changes to harness improved hardware.

The iMP apparently doesn't have Quick Sync so for encode/decode acceleration developers must use AMD's UVD/VCE which requires its own API framework. Any time a resource like that is used in a real-world professional app, it must support thread-safe access, exception handling, debugging, and it must be very reliable. Its much more demanding than a "Hello world" test program.

OTOH Quick Sync has been available since 2011, and Adobe still doesn't use that on the Mac version of Premiere. They didn't use it on Windows until June 2016. I'm not sure what their excuse is for that.