By: Dummond D. Slow (mental.delete@this.protozoa.us), November 19, 2020 3:35 pm
Room: Moderated Discussions
Doug S (foo.delete@this.bar.bar) on November 19, 2020 9:13 am wrote:
> Dummond D. Slow (mental.delete@this.protozoa.us) on November 18, 2020 4:50 pm wrote:
> > No. Strawman/misunderstanding/BS.
> > The question was if SPEC is representative of real world workloads/usage. x264 is used
> > with SIMD compile in in real world. It is used without SIMD by accident (as mentioned,
> > mistake of distro package maintainer) by people who don't know what they are doing.
>
>
> So if you believe it is unfair that the x264 test doesn't allow using hand tuned SIMD assembly,
> would you also allow use of on chip h.264 hardware, as well as Apple's IPU or NPU if those
> proved more appropriate for some other benchmark instead of using their CPU cores?
>
> Or are you going to come up with some tortured logic to claim using any *CPU* resources is OK,
> but using other blocks on an SoC isn't fair to CPUs being tested that aren't part of an SoC?
I think I said elsewhere here that hardware and software encoding are different beasts for different roles.
But no, this is 100% ridiculous. You are actively suggesting to test apples against... perhaps not even oranges.
Again, this whole mess started with a question, does SPEC's x264 represent real world usage?
If you (got fooled by the name to) think so, you expect it to represent running x264, not blackbox hardware encoder that does something completely different. You are aware that stuff encoder can do with input frames given to it has almost infinite range of leeway? You could literally output yuv frames full of zeroes with some added headers and call it a day, it would be a valid encoder, just with a tad bad psnr. If we want to be silly: Would you allow that to stand in for the x264 codebase?
Come on, people are discrediting libquantum because it can be rewritten by compiler for ridiculous speedeups. But that still gives correct results. Your idea does not, so why did you even propose that?
Do you guys crave to find avenues to disagree so much? All to defend a benchmark suite from valid criticism that you see (for no reason) as an attack, which you don't like because to "attack" (criticise) that benchmark is to "attack" a processor you like? Seriously?
I really don't get what got you people so riled up to feel need to disagree with such an obvious thing as "x264 --no-asm is not representative of real use".
> Dummond D. Slow (mental.delete@this.protozoa.us) on November 18, 2020 4:50 pm wrote:
> > No. Strawman/misunderstanding/BS.
> > The question was if SPEC is representative of real world workloads/usage. x264 is used
> > with SIMD compile in in real world. It is used without SIMD by accident (as mentioned,
> > mistake of distro package maintainer) by people who don't know what they are doing.
>
>
> So if you believe it is unfair that the x264 test doesn't allow using hand tuned SIMD assembly,
> would you also allow use of on chip h.264 hardware, as well as Apple's IPU or NPU if those
> proved more appropriate for some other benchmark instead of using their CPU cores?
>
> Or are you going to come up with some tortured logic to claim using any *CPU* resources is OK,
> but using other blocks on an SoC isn't fair to CPUs being tested that aren't part of an SoC?
I think I said elsewhere here that hardware and software encoding are different beasts for different roles.
But no, this is 100% ridiculous. You are actively suggesting to test apples against... perhaps not even oranges.
Again, this whole mess started with a question, does SPEC's x264 represent real world usage?
If you (got fooled by the name to) think so, you expect it to represent running x264, not blackbox hardware encoder that does something completely different. You are aware that stuff encoder can do with input frames given to it has almost infinite range of leeway? You could literally output yuv frames full of zeroes with some added headers and call it a day, it would be a valid encoder, just with a tad bad psnr. If we want to be silly: Would you allow that to stand in for the x264 codebase?
Come on, people are discrediting libquantum because it can be rewritten by compiler for ridiculous speedeups. But that still gives correct results. Your idea does not, so why did you even propose that?
Do you guys crave to find avenues to disagree so much? All to defend a benchmark suite from valid criticism that you see (for no reason) as an attack, which you don't like because to "attack" (criticise) that benchmark is to "attack" a processor you like? Seriously?
I really don't get what got you people so riled up to feel need to disagree with such an obvious thing as "x264 --no-asm is not representative of real use".
