By: Dummond D. Slow (mental.delete@this.protozoa.us), November 18, 2020 12:17 pm
Room: Moderated Discussions
none (none.delete@this.none.com) on November 18, 2020 10:14 am wrote:
> Dummond D. Slow (mental.delete@this.protozoa.us) on November 18, 2020 9:21 am wrote:
> > Maynard Handley (name99.delete@this.name99.org) on November 18, 2020 9:13 am wrote:
> > >
> > > x264 in SPEC is not there to help you decide which PC to buy for ripping DVD content!
> > > It is there as an exemplar of certain styles of code: various generic compression techniques
> > > (so lots of bit by bit manipulation) and various image analysis techniques (so searches
> > > over images and image comparisons at various frequency granularities).
> > >
> >
> > You didn't read it? If x264 is example of a kind of code, it is an example of code
> > heavily optimised with multimedia (integer) SIMD. It's a greeat example or maybe
> > too great, other codebases like ffmpeg or x265 will be a bit less optimized.
> >
> > If you want to explore such code, run it with assembly. It has assembly for ARM too, and not that
> > little of it. Without SIMD, it is the opposite of example of multimedia compression code.
>
> The main interest of that code is its high IPC and potential automatic vectorization, not
> that it exhibits absolute fastest code for h264 compression.
>
> The mistake is to think that since it's named x264 it should behave as the x264 you know. An
> understandable mistake, I agree.
>
I don't think this is reasonable at all. We don't want to test how clever compilers are at autovectorization. We want to know how fast CPUs are running actual code.
And if the starting argument was about whether SPEC represents real usage then no, this is doubly irrelevant. Real usage is with SIMD and I see no reasonable way around that fact.
We should refrain from introducing completely theoretical and arbitrary extra constrains into the matter if those are merely for the goal of changing the result to something we prefer to the actual result we get when we just do it the correct straightforward way.
>
> > "Various generic compression techniques", my butt. This is an area I
> > know, so please don't talk armchair nonsense like you did just now.
>
> Keeping it civil is an option, you know?
Maynard clearly ignored my message and went on to claima complete opposite of what the same premises imply.
And note it was a reply to somebody who is keeping it civil like this. I still only used words like butt or nonsense in reference to stuff that was said and not people who said it.
At one point or the other, if it is nonsense you have to call it such.
> > > x264 in SPEC is not there to help you decide which PC to buy for ripping DVD content!
I ignored his patronizing, strawman ad hominem (or what was exactly the intention here) too :)
> Dummond D. Slow (mental.delete@this.protozoa.us) on November 18, 2020 9:21 am wrote:
> > Maynard Handley (name99.delete@this.name99.org) on November 18, 2020 9:13 am wrote:
> > >
> > > x264 in SPEC is not there to help you decide which PC to buy for ripping DVD content!
> > > It is there as an exemplar of certain styles of code: various generic compression techniques
> > > (so lots of bit by bit manipulation) and various image analysis techniques (so searches
> > > over images and image comparisons at various frequency granularities).
> > >
> >
> > You didn't read it? If x264 is example of a kind of code, it is an example of code
> > heavily optimised with multimedia (integer) SIMD. It's a greeat example or maybe
> > too great, other codebases like ffmpeg or x265 will be a bit less optimized.
> >
> > If you want to explore such code, run it with assembly. It has assembly for ARM too, and not that
> > little of it. Without SIMD, it is the opposite of example of multimedia compression code.
>
> The main interest of that code is its high IPC and potential automatic vectorization, not
> that it exhibits absolute fastest code for h264 compression.
>
> The mistake is to think that since it's named x264 it should behave as the x264 you know. An
> understandable mistake, I agree.
>
I don't think this is reasonable at all. We don't want to test how clever compilers are at autovectorization. We want to know how fast CPUs are running actual code.
And if the starting argument was about whether SPEC represents real usage then no, this is doubly irrelevant. Real usage is with SIMD and I see no reasonable way around that fact.
We should refrain from introducing completely theoretical and arbitrary extra constrains into the matter if those are merely for the goal of changing the result to something we prefer to the actual result we get when we just do it the correct straightforward way.
>
> > "Various generic compression techniques", my butt. This is an area I
> > know, so please don't talk armchair nonsense like you did just now.
>
> Keeping it civil is an option, you know?
Maynard clearly ignored my message and went on to claima complete opposite of what the same premises imply.
And note it was a reply to somebody who is keeping it civil like this. I still only used words like butt or nonsense in reference to stuff that was said and not people who said it.
At one point or the other, if it is nonsense you have to call it such.
> > > x264 in SPEC is not there to help you decide which PC to buy for ripping DVD content!
I ignored his patronizing, strawman ad hominem (or what was exactly the intention here) too :)