I can reproduce this on 4.5.2. No RyuJIT here. Both x86 and x64 disassemblies look reasonable. Range checks and so on are the same. The same basic structure. No loop unrolling.
x86 uses a different set of float instructions. The performance of these instructions seems to be comparable with the x64 instructions except for the division:
- The 32 bit x87 float instructions use 10 byte precision internally.
- Extended precision division is super slow.
The division operation makes the 32 bit version extremely slow. Uncommenting the division equalizes performance to a large degree (32 bit down from 430ms to 3.25ms).
Peter Cordes points out that the instruction latencies of the two floating point units are not that dissimilar. Maybe some of the intermediate results are denormalized numbers or NaN. These might trigger a slow path in one of the units. Or, maybe the values diverge between the two implementations because of 10 byte vs. 8 byte float precision.
Peter Cordes also points out that all intermediate results are NaN… Removing this problem (valueList.Add(i + 1) so that no divisor is zero) mostly equalizes the results. Apparently, the 32 bit code does not like NaN operands at all. Let’s print some intermediate values: if (i % 1000 == 0) Console.WriteLine(result);. This confirms that the data is now sane.
When benchmarking you need to benchmark a realistic workload. But who would have thought that an innocent division can mess up your benchmark?!
Try simply summing the numbers to get a better benchmark.
Division and modulo are always very slow. If you modify the BCL Dictionary code to simply not use the modulo operator to compute the bucket index performance measurable improves. This is how slow division is.
Here’s the 32 bit code:
64 bit code (same structure, fast division):
This is not vectorized despite SSE instructions being used.