Vectorized FFT

[nbgl]

Vectorized version of FFT. Pretty much a direct translation of the old code. I worry that the vector stuff gets in the way of readability; I welcome suggestions for fixing that.

[dlubarov]

This is minor but maybe we could tweak the second loop to emphasize how it's a continuation of the first:

• let s = max(r, log_packed_width);
• for lg_half_m in s..lg_n { ... }
• rename i -> lg_half_m in the first loop, or we could just call both i if you think lg_half_m is long/confusing

[dlubarov]

Yeah it's fairly tough to read, but I think it makes sense, and I can't think of any significant improvements. Do you expect a significant speedup on certain (i.e. AVX-512) hardware? If so I think it seems OK. Would like to get @unzvfu's thoughts also though.

What do you think of having dedicated functions for the first several layers? It might improve readability in some ways, though of course there'd be some more redundancy, so I'm not really sure if it's a good tradeoff. Could also lead to some optimizations, e.g. roots could just be immediate values in the first few layers.

[nbgl]

The speed improvement is fairly significant even without AVX-512. On my Skylake, which only has AVX2, vectorization increases the throughput of that hot loop by 1.4× (figure from my profiles of the fft benchmarks). So even though AVX2 doesn’t increase the throughput of multiplication per se (see #1), there are other effects:

1. 4× fewer loads/stores/bounds checks
2. AVX2 multiplication cannot use 4 instructions/cycle (the maximum on Skylake) because there’s only 3 vector ALUs. So we get the same multiplication throughput while doing loads/stores/bounds checks/conditional jumps for free
3. Addition and subtraction are faster in vector

Of course, I expect the improvement to be bigger still on AVX-512.

[unzvfu]

FWIW this is looking good to me. The vectorised implementation is pretty clear (or at least not much harder to read than the original).