4 ms·

Rendering is parallel, yes, but it also makes heavy use of SIMD to accelerate the operations per thread. One does not obviate the other. In the most trivial ca

by dagmx 2y ago

Rendering is parallel, yes, but it also makes heavy use of SIMD to accelerate the operations per thread. One does not obviate the other. In the most trivial case, sure, the JavaScript runtimes won’t compile to use SIMD but there’s lot of cases where they will as well as part of their JIT. I think you’re trivializing how they work. And back to the main point, it doesn’t really matter if you believe Cinebench reflects real world rendering. The fact is that R23 uses SIMD for x86, but not for ARM. R24 rectifies that. Both R23 and R24 use the same rendering code path regardless of running in single or multi threaded mode. So using R23 as benchmarks for efficiency and performance will naturally benefit x86 significantly. There’s a reason none of the people who push the “AMD is almost the same” use the fairer benchmark to do so. R24 really highlights the actual discrepancy when both are given a fair playing field.

AnthonyMouse 2y ago
> The fact is that R23 uses SIMD for x86, but not for ARM. R24 rectifies that. Both R23 and R24 use the same rendering code path regardless of running in single or multi threaded mode. But that's not the issue. Even if Cinebench R23 isn't a valid comparison, Zen5 also faster for Cinebench R24 MT. Cinebench ST (R24 or R23) turns out to be a silly benchmark, because nobody in real life is going to artificially limit their renderer to one thread, but a renderer limited to one thread is also a bad proxy for real single-threaded workloads. What it's mostly telling you is how wide the CPU is. Which only matters for real single-threaded code if the CPU can find enough instruction-level parallelism to exploit (which that test doesn't probe), and only matters for multi-threaded code to the extent that the processor can maintain that instruction density without becoming limited by thermals/cache/memory/etc. when the code is running on all the cores, which is the thing the MT benchmark tests.
- dagmx 2y ago
  Again, I think your logic here is flawed. It’s still valuable to know how a single core behaves for a rendering work load. I’ve worked professionally in feature film production. We test single threaded performance all the time. It tells us the performance characteristics of the nodes on our farm, and lets us more accurately get a picture of how jobs will scale and/or be packed. It’s not uncommon to have a single thread rendering, for example to update part of an image while an artist works on other parts. It’s not just a test of how wide the chip is. It also tests things like how it actually handles the various instruction sets from a real world codebase. Not all processors that are equally “wide” (not the right term but whatever) handle AVX the same, and you need to know how a single core behaves for that. It’s also useful to see how the cores actually behave on their own so you can eliminate the overhead of thread synchronization and system scheduling affecting you.

by dagmx 2y ago

AnthonyMouse 2y ago

> The fact is that R23 uses SIMD for x86, but not for ARM. R24 rectifies that. Both R23 and R24 use the same rendering code path regardless of running in single or multi threaded mode. But that's not the issue. Even if Cinebench R23 isn't a valid comparison, Zen5 also faster for Cinebench R24 MT. Cinebench ST (R24 or R23) turns out to be a silly benchmark, because nobody in real life is going to artificially limit their renderer to one thread, but a renderer limited to one thread is also a bad proxy for real single-threaded workloads. What it's mostly telling you is how wide the CPU is. Which only matters for real single-threaded code if the CPU can find enough instruction-level parallelism to exploit (which that test doesn't probe), and only matters for multi-threaded code to the extent that the processor can maintain that instruction density without becoming limited by thermals/cache/memory/etc. when the code is running on all the cores, which is the thing the MT benchmark tests.

dagmx 2y ago
Again, I think your logic here is flawed. It’s still valuable to know how a single core behaves for a rendering work load. I’ve worked professionally in feature film production. We test single threaded performance all the time. It tells us the performance characteristics of the nodes on our farm, and lets us more accurately get a picture of how jobs will scale and/or be packed. It’s not uncommon to have a single thread rendering, for example to update part of an image while an artist works on other parts. It’s not just a test of how wide the chip is. It also tests things like how it actually handles the various instruction sets from a real world codebase. Not all processors that are equally “wide” (not the right term but whatever) handle AVX the same, and you need to know how a single core behaves for that. It’s also useful to see how the cores actually behave on their own so you can eliminate the overhead of thread synchronization and system scheduling affecting you.