5 ms·

> 64 bytes of FizzBuzz per 4 clock cycles That's borderline incredulous, given a single AVX2 instruction can last multiple clock-cycles. The reciprocal through

> 64 bytes of FizzBuzz per 4 clock cycles That's borderline incredulous, given a single AVX2 instruction can last multiple clock-cycles. The reciprocal throughput also doesn't go below ~0.3 to my, admittedly shallow, knowledge. A remarkable piece of engineering!

gpderetta 5y ago
That's 16 bytes per clock cycle, i.e. one avx register per clock cycle. As most intel CPUs can only do one store per clock cycle, that's also the theoretical limit with avx. I wonder if using non temporal stores would help make the code be cache size agnostic. Note that the instruction latency is not important as long as you can pipeline the computation fully (which appear to be the case here!). Edit: to go faster you would need to be able to use the bandwidth of more than one cpu. I wonder if you could precompute were the output will cross a page to be able to have distinct cores work on distinct pages... Hum I need a notepad. Edit2: it is much simpler than that, you do not need to fill a page to vmsplice it. So in principle the code should parallelize quite trivially. Have each tread grab, say 1M numbers at a time, for example by atomically incrementing counter, serialize them to a bunch of pages, then grab the next batch. A simple queue will hold the ready batches that can be spliced as needed either by a service thread or opportunistically by the thread that has just finished the batch next in sequence.
- gpderetta 5y ago
  Note: of course SSE is 16 bytes, AVX is 32 bytes! So there is still some margin to be exploited here.
- londons_explore 5y ago
  Except the program counting the data generation rate is running on only a single CPU...
  - gpderetta 5y ago
    That shouldn't be a problem, pv is basically only counting the number of pages being written. As long as the page size is much larger than the number of threads it should keep up just fine.
    - londons_explore 5y ago
      The page size can't be more than half the L2 cache (else writeback to DRAM would be triggered, dramatically lowering performance). That means you have to use a relatively small page size, and lock contention in the kernel for those pages then limits throughput if you use many cores, even if the data is never read by pv. See the comments in the code for info...
    - deleted 5y ago
      [deleted]
monktastic1 5y ago
> incredulous FYI "incredible" might be a better word here. "Incredulous" would mean that it finds something incredible.
- howenterprisey 5y ago
  Alternatively "unbelievable"?
  - v-erne 5y ago
    Inconceivable ? Sorry I could not resist.

gpderetta 5y ago

That's 16 bytes per clock cycle, i.e. one avx register per clock cycle. As most intel CPUs can only do one store per clock cycle, that's also the theoretical limit with avx. I wonder if using non temporal stores would help make the code be cache size agnostic. Note that the instruction latency is not important as long as you can pipeline the computation fully (which appear to be the case here!). Edit: to go faster you would need to be able to use the bandwidth of more than one cpu. I wonder if you could precompute were the output will cross a page to be able to have distinct cores work on distinct pages... Hum I need a notepad. Edit2: it is much simpler than that, you do not need to fill a page to vmsplice it. So in principle the code should parallelize quite trivially. Have each tread grab, say 1M numbers at a time, for example by atomically incrementing counter, serialize them to a bunch of pages, then grab the next batch. A simple queue will hold the ready batches that can be spliced as needed either by a service thread or opportunistically by the thread that has just finished the batch next in sequence.

gpderetta 5y ago
Note: of course SSE is 16 bytes, AVX is 32 bytes! So there is still some margin to be exploited here.
londons_explore 5y ago
Except the program counting the data generation rate is running on only a single CPU...
- gpderetta 5y ago
  That shouldn't be a problem, pv is basically only counting the number of pages being written. As long as the page size is much larger than the number of threads it should keep up just fine.
  - londons_explore 5y ago
    The page size can't be more than half the L2 cache (else writeback to DRAM would be triggered, dramatically lowering performance). That means you have to use a relatively small page size, and lock contention in the kernel for those pages then limits throughput if you use many cores, even if the data is never read by pv. See the comments in the code for info...
  - deleted 5y ago
    [deleted]

monktastic1 5y ago

> incredulous FYI "incredible" might be a better word here. "Incredulous" would mean that it finds something incredible.

howenterprisey 5y ago
Alternatively "unbelievable"?
- v-erne 5y ago
  Inconceivable ? Sorry I could not resist.