The Ampere GA102, GA103 and Lovelace AD102, AD103 chips (cc86 and cc89, respectively) can set up two concurrent fp32 operations, as opposed to one int32 and one fp32 instruction in the earlier Turing hardware. Thus, the theoretical peak FLOPs of an A40 is nearly double that of an A100 (which does not have such concurrent instructions available, although it does do “beast mode” fp64).
Is there a way I can tell whether, to any extent, my code is taking advantage of such concurrent instructions? I have a slick way to rejigger the most compute-heavy kernel in my code that will present two identical calculations in the inner loop, although it’s not a slam dunk (each calculation involves an if-then based on whether two particles are within range of on another, and while it will be very likely that both particles are within range if either is within range, I may have to crunch through some blanks in a way that SIMT can’t mitigate to any degree). I’d like to see whether I’m already getting some concurrency, however.
This question would appear to be a better fit for the Nsight Compute sub-forum.
Looking through the events available I don’t see any that appear to directly provide a count of FP32 dual issue events. Indirectly one could conclude that when there are more FP32 instructions issued than cycles elapsed, there must have been FP32 dual issues (by the pigeonhole principle), but this kind of weak statement probably is not helpful for the scenario described.
Nsight Compute does not have a metric to calculate if back to back FP32 instructions were issued taking advantage of the new feature. Nsight does show the utilization of the new math pipe fmalite.