"Fischer, Paul F." <[email protected]> writes:

Yes -- but my question was intended for the case without off-node communication.

Ah, okay. LU still requires significant on-node synchronization, but I now realize you actually asked about DGEMM.

In other words, I'm trying to understand what size problem per node is required, even before we start counting the cost of going off-node. I guess this depends heavily on the intra-node parallel model, but I was thinking that someone might have developed the "fastest" dgemm (in terms of flops, say, which would encourage using more cores) on knl, and then what size n was required for that and then what was the corresponding n_1/2.

I'm happy, btw, with any other respected benchmark - but I think speed needs to be the metric (not for comparison against other benchmarks, but simply to understand how problem size and speed are related for a given well-implemented benchmark test).

This is why I want to know execution time at 50% efficiency. But for DGEMM, I agree with Jeff that it depends almost entirely on where the operands reside. For example, if m=24, n=8 and k is not too small (or C is already in registers) and the operands are in cache, then you get great (near peak) performance because large-size DGEMM boils down to this (plus packing).