Counting bytes fast

Post by sitkack » Sun, Sep 28, 2014, 6:21 AM UTC

nkurz wrote: post #5

I wish the author would have been more specific about the processor being tested. This is the sort of thing that is extremely dependent on the microarchitecture of processor used. I wonder if he's testing on AMD or older Intel? Modern Intel chips usually do an very good job of "store-to-load forwarding" when the load is the same size or smaller than the store. Although it's testing a slightly different effect, this i…

Post by zvrba » Sun, Sep 28, 2014, 7:00 AM UTC

userbinator wrote: post #32

nkurz wrote: post #29

Earlier quoted context omitted.

I agree that this would occasionally be a very useful feature. Any idea if this would be architecturally feasible? Might it be similar to modern a GPU's "register file"? Maxwell (current generation NVidia) has 64KB of registers. How did you come up with 2048 bytes for x64, though? I get 16 * 32B = 256 if I count logical registers, or 168 * 32B = 5376 if I count physical (for Haswell).

Architecturally, it would merely be a matter of taking the register selection bits not from the instruction itself but from some other source, like another register; there will certainly be a bit more complexity due to dependencies etc. 2048 bytes since AVX-512 has 32 registers, each 512 bits (64 bytes) wide.

Post by danbruc » Sun, Sep 28, 2014, 7:50 AM UTC

sitkack wrote: post #31

nkurz wrote: post #5

I wish the author would have been more specific about the processor being tested. This is the sort of thing that is extremely dependent on the microarchitecture of processor used. I wonder if he's testing on AMD or older Intel? Modern Intel chips usually do an very good job of "store-to-load forwarding" when the load is the same size or smaller than the store. Although it's testing a slightly different effect, this i…

Pretty sure this would help. https://software.intel.com/en-us/node/513929 Author should have supplied test code and a benchmark suite.

Post by innocenat » Sun, Sep 28, 2014, 10:40 AM UTC

nkurz wrote: post #34

zvrba wrote: post #33

Earlier quoted context omitted.

> Architecturally, it would merely be a matter of taking the register selection bits Except these do not exist for individual SIMD lanes; that's why you have permutation instructions. Treating individual lanes as registers would increase the needed number of addressing bits, which I'm sure would complicate stuff much more than "just" changing the possible source.

This Intel Forum post entitled "AVX-512 is a big step forward - but repeating past mistakes" addresses some of these issues: https://software.intel.com/en-us/forums/topic/477541 The debate is essentially whether AVX-512 is making a mistake by giving up 8-bit and 16-bit operations. Agner feels it's a mistake, but other smart people argue that it's not a problem.

Post by kabdib » Sun, Sep 28, 2014, 1:58 PM UTC

nkurz wrote: post #20

kabdib wrote: post #16

Earlier quoted context omitted.

This code is generating tons of D-cache misses, at the cost of hundreds of cycles (in a modern x86 memory system), so you can afford a branch miss now and then.

I don't think this is correct. The input is sequential, so the hardware prefetcher should be very successful: the only misses will be 1/4096 for the first entry into a new 4KB page, and even this could be avoided with a single judicious software prefetch. He's counting 8-bit bytes, and thus has 256 entries per table. Using 64-bit counters, this is 8 * 256 = 2048 contiguous bytes per table. 4 tables gets him up to 8KB…