By: Dummond D. Slow (mental.delete@this.protozoa.us), November 18, 2020 9:31 am
Room: Moderated Discussions
none (none.delete@this.none.com) on November 18, 2020 8:18 am wrote:
> 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.
The hardware IP argument is rubbish as far as I can tell. Software encoding is completely different area than hardware encoding. It's authoring vs streaming, high-value encodes versus disposable 1-use encodes, typically. Many people actually use the hardware encoders in production, but it's a heavy compromise. If they for example use GPU/SoC encoders for the final video that is to be distributed to many people, it's simply a mistake. Well perhaps the content is not worth it but there is a big difference between these two worlds.
The x264 component in SPEC is still misrepresenting though, as it is bound by different parts of the processor.
Frankly, they should have not included it at all, in my opinion. Portability is rubbish reason if nobody will use a software "ported" by disabling assembly. If you want to port a multimedia encoder, you put in the effort to re-implement its SIMD routines or go away. It's going to be unusable mess at least order of magnitude slower than it should be.
> 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.
The hardware IP argument is rubbish as far as I can tell. Software encoding is completely different area than hardware encoding. It's authoring vs streaming, high-value encodes versus disposable 1-use encodes, typically. Many people actually use the hardware encoders in production, but it's a heavy compromise. If they for example use GPU/SoC encoders for the final video that is to be distributed to many people, it's simply a mistake. Well perhaps the content is not worth it but there is a big difference between these two worlds.
The x264 component in SPEC is still misrepresenting though, as it is bound by different parts of the processor.
Frankly, they should have not included it at all, in my opinion. Portability is rubbish reason if nobody will use a software "ported" by disabling assembly. If you want to port a multimedia encoder, you put in the effort to re-implement its SIMD routines or go away. It's going to be unusable mess at least order of magnitude slower than it should be.
