Hacker News Reader

Comment by userbinator | Hacker News Reader

There is an... interesting post by Linus Torvalds about GeekBench:

http://www.realworldtech.com/forum/?threadid=136526&curposti...

In other words, Linus claims it's mainly testing the speed of specialised instructions implemented in hardware, and not general-purpose computing. For a similar analogy, compare the speed of a Bitcoin mining ASIC vs. a GPU or even a CPU. At the same clock speed, dedicated hardware will vastly outperform the software implementation.

I think it's somewhat ironic then, that the "RISC" CPU is getting higher scores due to the presence of such CISC-y instructions.

View on HN

That was about Geekbench 3, the previous version. The new version doesn't have those problems, and also it uses the exact same workload between desktops and mobile devices.

In those same forums there are comments by Linus about the new Geekbench 4 and they are much more positive. http://www.realworldtech.com/forum/?threadid=159853&curposti...

Something is still wonky with their approach. Consider a 3770 vs 6700: https://browser.primatelabs.com/v4/cpu/compare/3041851?basel...

Almost all other benchmarks I've seen put the 6700 at ~15% faster for both single and multi core tests, including most importantly, real world benchmarks. Geekbench has the 6700 at 47% faster single core and 64% faster multi-core. The few individual benchmarks I've see with numbers close to Geekbench's overall spread are using new instructions or are actually testing the onboard GPU.

The 6700 result you selected is significantly faster than the average for the 6700: http://browser.geekbench.com/processor-benchmarks

Maybe it's overclocked? If you look at the averages for the 3770 and the 6700 Geekbench reports a difference of 20% for single core.

>The new version doesn't have those problems.

See, that's the thing. It may be much better than before, but starting from such a low level this doesn't mean much.

Considering the whole Geekbench history I have a hard time accepting that statement in its absolute form. That they suddenly are _the_ indesputable luminaries about all the intricacies, pitfalls and subtleties of multi-arch benchmarking and have done everything right to make a single artificial score a meaningful comparator (which is questionable in itself in the best of cases IMO).

I don't think a lot of these tests are that "CISC-y". They're just incredibly synthetic.

Both CPU's are entirely CISC. The Intel CPU just have way more of... well, everything. That's the primary reason for the TDP gap.

It's really hard to say anything about the benchmarks without the assembly for both architectures, though. Is the Intel memory copy a simple "rep mov", or a mov using all xmm registers? Is the ARM AES benchmark using AES extensions?

Well, akhchtually! rep mov is pretty fast these days (on Ivy Bridge onwards).

On the other hand XMM registers are pretty old, we have YMM and ZMM now.

When I tried on an Ivy Bridge laptop-class processor a few years back, move over XMM utilizing a handful of registers was still significantly faster than rep mov. It would make sense for Intel to improve it, though.

But my point was more that you need to know what it does to know what you compare. That the "fast way" changes over time makes it even more important.

Only for small copies (due to static overhead/no branch prediction in microcode). For large buffers, rep/movs has been a win since ivybridge once your buffers are too large for L2. A big part of this is that the stores used by rep/movs get to do a dataless read-for-ownership, so they actually move 1/3 less data around than any other implementation when they miss L2.

Another obvious win is that you do not trash "user-facing" registers with rep mov, like you do with a multi-xmm-register dance.

I'm pro rep mov, but an XMM duffs device just won over rep mov where I tested. It was years ago, however, so I do not remember if I tried to run above L2 and L3. It was related to a compiler optimization debate for alternate memcpy/memmove implementations...

> get to do a dataless read-for-ownership, so they actually move 1/3 less data around than any other implementation when they miss L2.

Can't you achieve same using cache line sized non-temporal stores?

There are no cacheline-size store instructions pre AVX-512 (on Ivybridge, the widest store is 32B, and even that cracks to two 16B store uops; it's a real 32B store on Haswell+). Also the NT stores suffer from a bunch of other hazards that rep/movs avoids.

Non temporal stores shouldn't go to the cache at all though. They go to write combining buffers instead.

Shouldn't, but do. They RFO into the LLC.

I would argue that the LLVM test isn't skewed with specialized instructions, and the iPad wins it regardless.

I'd really be interested to see an evaluation of what makes the difference there.

First guess: The iPad's massively larger L2 cache.

And what, exactly, is the LLVM test?

Do you have access to the source?

Reply on news.ycombinator.com