3 ms·

Yes, there’s no difference between the single and multi core benchmark other than how many threads get spun up. I’m not sure why you’re trying to equate simd w

by dagmx 2y ago

Yes, there’s no difference between the single and multi core benchmark other than how many threads get spun up. I’m not sure why you’re trying to equate simd with parallelization. Tbh, a lot of your response seems odd to me because it’s making several incorrect assumptions. You can’t really escape parallelization with how any modern core works, even on a single core. You may have certain operations process concurrently depending on how the cores resources are available at a given time and what is needed. Regardless, SIMD isn’t concurrency. It’s batching. There’s still significant benefit to having SIMD on a single threaded task. There’s a lot of thread overhead to using multiple cores to do something, whereas SIMD lets you effectively batch things on a single core.

AnthonyMouse 2y ago
SIMD workloads generally imply that you're doing the same operation repeatedly. It's literally in the name; single instruction, multiple data. There are occasional cases where that happens but doesn't parallelize well. TLS is probably a good example because you might have to encrypt a network packet and it's big enough to benefit from SIMD but not big enough that the overhead of splitting it across cores is worth it. But most of the time if you're doing the same operation repeatedly you'll benefit from using more cores. Even for TLS, the client might not split the individual connection across multiple cores, but the server is going to handle multiple clients at once in parallel. Heavy workloads like video encoding make this even more apparent. In general the things that benefit from SIMD are parallel tasks that benefit from multiple cores. Compare this with, say, a browser running JavaScript in a single tab. There is nothing to put on another core, you don't know what instructions will be executed next until you get there. This is where people actually care about single-thread performance, and where processors achieve it by using branch prediction etc. But these exercise very different parts of the CPU than SIMD-heavy workloads. The latter can easily fill the execution units of a wide processor that would be stymied by the former.
- dagmx 2y ago
  This feels like a really absurd stretch of trying to discern SIMD away from stuff like standard integer and float operations. Maybe in the early 90s, but they’re such a part of processor design that you can’t realistically avoid them. Especially for rendering, which is matrix math heavy, you’d have to design something completely bespoke to avoid it. SIMD is a natural necessity for rendering with any kind of performance. And because SIMD is such a part of every mainstream processor, it’s very important that benchmarks show how well they perform. I also don’t understand why you think a JavaScript runtime wouldn’t use SIMD. V8 can make use of SIMD, whether directly targeted or indirectly via the compiler that compiled the runtime itself. If you want to stress very specific parts of a processor, then use something like SPEC. Cinebench is meant to be a realistic reflection of production rendering.
  - AnthonyMouse 2y ago
    > Especially for rendering, which is matrix math heavy, you’d have to design something completely bespoke to avoid it. SIMD is a natural necessity for rendering with any kind of performance. Well sure, but rendering is a classically parallel operation which is regularly implemented as threaded. > I also don’t understand why you think a JavaScript runtime wouldn’t use SIMD. V8 can make use of SIMD, whether directly targeted or indirectly via the compiler that compiled the runtime itself. JavaScript runtimes are executing code, so they'll implement the whole gamut and their execution will depend on what kind of code it actually is. But the common JavaScript code, and the kind presumably being tested in JavaScript benchmarks because it's what people care about, isn't implementing a video encoder using SIMD. It's manipulating DOM objects and parsing short pieces of text input, which is branch-heavy code with lots of indirection and very little use of SIMD if any. > If you want to stress very specific parts of a processor, then use something like SPEC. Cinebench is meant to be a realistic reflection of production rendering. Which is kind of my point. Production rendering is going to be threaded and max out all the cores, which is Cinebench MT. "CineBench ST" is measuring something that nobody does in real life and doesn't even really correlate with the things people actually do. It doesn't represent real threaded workloads (which optimally run on many low-clocked cores, not one high-clocked one) nor real serialized workloads (which are full of conditional jumps and cache misses).
    - 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.

by dagmx 2y ago

AnthonyMouse 2y ago

SIMD workloads generally imply that you're doing the same operation repeatedly. It's literally in the name; single instruction, multiple data. There are occasional cases where that happens but doesn't parallelize well. TLS is probably a good example because you might have to encrypt a network packet and it's big enough to benefit from SIMD but not big enough that the overhead of splitting it across cores is worth it. But most of the time if you're doing the same operation repeatedly you'll benefit from using more cores. Even for TLS, the client might not split the individual connection across multiple cores, but the server is going to handle multiple clients at once in parallel. Heavy workloads like video encoding make this even more apparent. In general the things that benefit from SIMD are parallel tasks that benefit from multiple cores. Compare this with, say, a browser running JavaScript in a single tab. There is nothing to put on another core, you don't know what instructions will be executed next until you get there. This is where people actually care about single-thread performance, and where processors achieve it by using branch prediction etc. But these exercise very different parts of the CPU than SIMD-heavy workloads. The latter can easily fill the execution units of a wide processor that would be stymied by the former.

dagmx 2y ago
This feels like a really absurd stretch of trying to discern SIMD away from stuff like standard integer and float operations. Maybe in the early 90s, but they’re such a part of processor design that you can’t realistically avoid them. Especially for rendering, which is matrix math heavy, you’d have to design something completely bespoke to avoid it. SIMD is a natural necessity for rendering with any kind of performance. And because SIMD is such a part of every mainstream processor, it’s very important that benchmarks show how well they perform. I also don’t understand why you think a JavaScript runtime wouldn’t use SIMD. V8 can make use of SIMD, whether directly targeted or indirectly via the compiler that compiled the runtime itself. If you want to stress very specific parts of a processor, then use something like SPEC. Cinebench is meant to be a realistic reflection of production rendering.
- AnthonyMouse 2y ago
  > Especially for rendering, which is matrix math heavy, you’d have to design something completely bespoke to avoid it. SIMD is a natural necessity for rendering with any kind of performance. Well sure, but rendering is a classically parallel operation which is regularly implemented as threaded. > I also don’t understand why you think a JavaScript runtime wouldn’t use SIMD. V8 can make use of SIMD, whether directly targeted or indirectly via the compiler that compiled the runtime itself. JavaScript runtimes are executing code, so they'll implement the whole gamut and their execution will depend on what kind of code it actually is. But the common JavaScript code, and the kind presumably being tested in JavaScript benchmarks because it's what people care about, isn't implementing a video encoder using SIMD. It's manipulating DOM objects and parsing short pieces of text input, which is branch-heavy code with lots of indirection and very little use of SIMD if any. > If you want to stress very specific parts of a processor, then use something like SPEC. Cinebench is meant to be a realistic reflection of production rendering. Which is kind of my point. Production rendering is going to be threaded and max out all the cores, which is Cinebench MT. "CineBench ST" is measuring something that nobody does in real life and doesn't even really correlate with the things people actually do. It doesn't represent real threaded workloads (which optimally run on many low-clocked cores, not one high-clocked one) nor real serialized workloads (which are full of conditional jumps and cache misses).
  - 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.