John Poole (john.delete@this.primatelabs.com) on September 26, 2013 2:59 pm wrote:
> Linus Torvalds (torvalds.delete@this.linux-foundation.org) on September 25, 2013 5:49 pm wrote:
> > It actually seems to have gotten worse with version 3, which you should be aware of. On
> > ARM64, that SHA1 performance is hardware-assisted. I don't know if SHA2 is too, but Aarch64
> > does apparently do SHA256 in the crypto unit, so it might be fully or partially so.
>
> Geekbench 3 uses cryptography instructions (when available) for AES and
> SHA-1. Both Twofish and SHA-2 are implemented purely "in software".
>
> > So basically a quarter to a third of the "integer" workloads are just utter BS.
>
> Only 2 of the 13 integer workloads use cryptography instructions. Do
> you have specific concerns with any of the other integer workloads?
>
> > And quite frankly, it's not even just the crypto ones. Looking at the other GB3 "benchmarks",
> > they are mainly small kernels: not really much different from dhrystone. I suspect
> > most of them have a code footprint that basically fits in a L1I cache.
>
> Outside of enterprise software stacks we're not aware of scenarios where L1I cache misses
> have a significant impact on performance. Are there scenarios that we've missed?
>

John, I've mentioned that SGEMM has the potential to be problematic when compiled with Polly. It might be interesting, as an experiment today, to compile it with LLVM switching on Polly, and see what happens. Point is, when polyhedral optimization IS part of a compiler, then a benchmark like that is testing the compiler, not the HW. Not a problem today, but will be soon.
I agree that an FP benchmark like SGEMM is valuable, but not one that is so easily manipulated by the HW. You might want to look through Numerical recipes and find an alternative algorithm (for example calculating eigenvalues of a sparse matrix) which doesn't have quite so regular an access pattern and so can't be accelerated by polyhedral optimization.