It's not that it's meaningless or pointless, it's just that using Cinebench will make x86 appear much faster than it actually is in majority of real-world applications. Reasons for that have been discussed multiple time:
- Cinebench uses Embree, a library written and maintained by Intel, which is hand-optimised for x86 SIMD. ARM SIMD support is provided though a compatibility header that implements x86 SIMD instructions as one or more ARM instructions. This approach not always results in best possible code on the ARM platform. Apple recently submitted a series of patches that are supposed to improve the performance on Apple Silicon by around 8%, but this is likely still not optimal
- Cibenench appears to rely on long dependent computation chains, that is, it has low ILP (instruction level parallelism). This is clear from inspecting CPU counters of retired instructions per cycle, which is significantly lower for Cinebench compared to other common code (I don't remember the exact numbers from the top of my head). This is not surprising since, again, it uses an x86 optimised library that aims to utilise the SIMD units present on x86 CPUs, so it's coded based on the assumption about latency and throughput of these units. Apple Silicon on the other hand relies on a very wide execution backend to execute many instructions from the same thread simultaneously. It can't really do that running Cinebench
- The previous point is also the reason why SMT (HyperThreading) is so effective in Cinebench. Since SMT tries to increase the utilisation of the execution units by feeding them operations from different threads, it excels in situations where the ILP is low. Apple Silicon does not have SMT and so goes underutilised in Cibenench.
- Cinebench is dominated by SIMD instruction throughput. Apple Silicon has little chance to win that kind of battle, even under optimal conditions. M1 family has four 128-bit SIMD units per core, effectively allowing them to process 512 bits worth of data per cycle. This is similar to modern x86 cores, but Apple Silicon runs much lower frequency. Also, x86 CPUs generally have higher cache bandwidth (this is especially true for Intel CPUs which are designed to sustain fetching large vector operands from cache — Apple is more conservative here, probably due to power consumption concerns). So on optimally hand-optimised SIMD code that's either throughput or memory bandwidth limited, higher clocked x86 will always win. On the other hand, on code where you need flexibility Apple is likely to win, because they can schedule more independent operations (this is especially true for non-vectorised scientific compute where M1 is extremely fast)
That more or less should cover it, unless I've forgotten something. TLDR: Cinebench is optimised for x86, not Apple, its basic software design favours x86, not Apple, and it represents a niche software problem where Apple is weaker overall. If you are looking for something quotable, feel free to quote this post. I am prepared to defend every point