3 ms·
This post cites sources that actively contradict the points it attempts to make. It provides a wealth of useful aggregation of information against the points it
by valarauca1 8y ago
This post cites sources that actively contradict the points it attempts to make. It provides a wealth of useful aggregation of information against the points it makes.
Let's us begin
However, there are also deterministic frequency
reductions based specifically on which instructions you
use and on how many cores are active (downclocking).
As you are likely using AVX-512 in a cloud deployment you don't have access to any of the information, and are likely sharing that hardware who may not respect the same engineering rigor.
Also, nobody setting there CPU affinity to ensure the down-clocking stays on a single core. You have to pray the scheduler doesn't shuffle your workload around. This requires a lot of platform specific C and most people are writing Java/Go/Ruby/Python where doing bit twidling NUMA management is impossible, furthermore the information you have access to in a cloud environment (which is where you'll be using advanced AVX-512 unless you work for Amazon, Google, Intel, or Cloudflare) may just lie about core count, and NUMA architecture.
Also this is just false [1]. Running AVX-512 adjusts the BASE clock for the package. There are throttling attempts to ensure every other core on the package throttles back. This is a package wide effect, not a per-core effect.
Light instructions include integer operations other than
multiplication, logical operations, data shuffling
(such as vpermw and vpermd) and so forth.
This is false according cloudflare [2] which you've linked. They test your "light" carry less adding, shifting, and xoring (these are the only operations in ChaCha20 [4]). It cost too much.
We have chosen to only include two columns.
I'll include the whole thing [3]. Wow yeah the entire package's power curve is changing. The base clock, cores not effected, all their clocks are changing. Its almost like having 1 out of 24 cores still effects all 24 cores....
For example, the openssl project used heavy AVX-512
instructions to bring down the cost of a particular
hashing algorithm (poly1305) from 0.51 cycles per byte
(when using 256-bit AVX instructions) to 0.35 cycles
per byte, a 30% gain on a per-cycle basis. They have
since disabled this optimization.
The literal example to show AVX-512 is good at ends with statement that people using AVX-512 are now actively avoiding it.
This is less then content, do you have an agenda or are you just an idiot?
[1] https://en.wikichip.org/wiki/intel/xeon_silver/4116 https://en.wikichip.org/wiki/intel/xeon_silver/4116
[2] https://blog.cloudflare.com/on-the-dangers-of-intels-frequency-scaling/ https://blog.cloudflare.com/on-the-dangers-of-intels-frequen...
[3] https://en.wikichip.org/wiki/intel/xeon_gold/5120 https://en.wikichip.org/wiki/intel/xeon_gold/5120
[4] https://en.wikipedia.org/wiki/Salsa20 https://en.wikipedia.org/wiki/Salsa20
- teraflop 8y ago> Also this is just false [1]. Running AVX-512 adjusts the BASE clock for the package. There are throttling attempts to ensure every other core on the package throttles back. This is a package wide effect, not a per-core effect. The explanatory page accompanying that table contains text that contradicts your claim: https://en.wikichip.org/wiki/intel/frequency_behavior https://en.wikichip.org/wiki/intel/frequency_behavior > The frequency of each core is determined independently based on the workload described above. That is, cores running Non-AVX workloads can enjoy the full regular turbo frequency, whereas cores executing AVX-512 or AVX2 will operate at their own designated turbo frequencies. [...] > In Haswell, an AVX2 workload on one core meant all cores were capped at AVX2 Turbo frequency. This had the undesirable effect of reducing performance for non-AVX workloads on cores that were unrelated to the cores executing AVX2 workloads. This behavior was changed with Broadwell which grouped cores executing AVX2 workloads together and cores executing non-AVX workloads separately, allowing the former cores group to execute at the lower AVX2 turbo frequency while having the later cores group execute at full non-AVX2 turbo. Also: > The literal example to show AVX-512 is good at ends with statement that people using AVX-512 are now actively avoiding it. It's an example to show that cycle-by-cycle speedups due to the use of AVX-512 are not always worthwhile, especially in library code. Which was one of the points the article was trying to make. It's fine if that was an obvious point from your perspective, but it doesn't contradict the article and it doesn't make it "less than content".
- dang 8y agoPlease don't break the HN guidelines by becoming uncivil. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html