By: Travis Downs (travis.downs.delete@this.gmail.com), September 8, 2018 2:21 pm
Room: Moderated Discussions
Tim McCaffrey (timcaffrey.delete@this.aol.com) on September 8, 2018 8:55 am wrote:
> Travis (travis.downs.delete@this.gmail.com) on September 7, 2018 8:32 pm wrote:
> > Partly based on the tests in avx-turbo Daniel Lemire (mostly) and I (a bit) have
> > written an article about the AVX-512 frequency behavior, and how this makes for
> > a trickier landscape when it comes to decisions about what ISA features to use:
> >
> > https://lemire.me/blog/2018/09/07/avx-512-when-and-how-to-use-these-new-instructions/#comment-347616
>
> Useful article.
>
> The only critic I have are statements like "a frequency drop of 15% means your AVX-512 code needs
> to perform 15% faster" (that is not an exact quote). In fact, your code would have to perform almost
> 18% faster to make up the difference. I know that sounds trivial (and it is), but when you get up
> to 33% frequency drops, your code needs to perform 50% faster to make up the difference.
Yeah, stuff like "X% faster" is often ambiguous: does that mean 15% more work per unit time (speedup 1.15)? Or does it mean runtime reduced by 15% (speedup 1/.85)? The first is probably the correct one in a strict language semantic sense but the second is common too, and the 15% compensating speedup math works out in that case.
So it could probably be more precisely stated that "the runtime must be reduced by 15%" or similar.
> Travis (travis.downs.delete@this.gmail.com) on September 7, 2018 8:32 pm wrote:
> > Partly based on the tests in avx-turbo Daniel Lemire (mostly) and I (a bit) have
> > written an article about the AVX-512 frequency behavior, and how this makes for
> > a trickier landscape when it comes to decisions about what ISA features to use:
> >
> > https://lemire.me/blog/2018/09/07/avx-512-when-and-how-to-use-these-new-instructions/#comment-347616
>
> Useful article.
>
> The only critic I have are statements like "a frequency drop of 15% means your AVX-512 code needs
> to perform 15% faster" (that is not an exact quote). In fact, your code would have to perform almost
> 18% faster to make up the difference. I know that sounds trivial (and it is), but when you get up
> to 33% frequency drops, your code needs to perform 50% faster to make up the difference.
Yeah, stuff like "X% faster" is often ambiguous: does that mean 15% more work per unit time (speedup 1.15)? Or does it mean runtime reduced by 15% (speedup 1/.85)? The first is probably the correct one in a strict language semantic sense but the second is common too, and the 15% compensating speedup math works out in that case.
So it could probably be more precisely stated that "the runtime must be reduced by 15%" or similar.