By: none (none.delete@this.none.com), November 18, 2020 9:18 am
Room: Moderated Discussions
Dummond D. Slow (mental.delete@this.protozoa.us) on November 18, 2020 7:17 am wrote:
[...]
> You know I am not completely sure about this as I can't check, but I heard that SPEC uses x264's
> code WITHOUT SIMD assembly compiled (whether disabling ASM intentionally or not compiling with yasm
> or whatever, no idea). If that is true it probably grossly changes character of the workload because
> compiler autovectorization tends to fails on vectorizing multimedia integer algorithms. Normally,
> x264 spends like 55% (figure given by devs 8-9 years back) in hand-tuned x86 SIMD.
You're correct: no assembly (or intrinsics) are in any SPEC test; portability is paramount.
So yes, that's not a good representation for the publicly available x264. But then it could
be argued that you should use HW IP for that anyway, and so that part of SPEC is not very
interesting; but it has quite a high IPC which makes it interesting to study.
[...]
> You know I am not completely sure about this as I can't check, but I heard that SPEC uses x264's
> code WITHOUT SIMD assembly compiled (whether disabling ASM intentionally or not compiling with yasm
> or whatever, no idea). If that is true it probably grossly changes character of the workload because
> compiler autovectorization tends to fails on vectorizing multimedia integer algorithms. Normally,
> x264 spends like 55% (figure given by devs 8-9 years back) in hand-tuned x86 SIMD.
You're correct: no assembly (or intrinsics) are in any SPEC test; portability is paramount.
So yes, that's not a good representation for the publicly available x264. But then it could
be argued that you should use HW IP for that anyway, and so that part of SPEC is not very
interesting; but it has quite a high IPC which makes it interesting to study.