You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The trouble with the naive version of matrix multiplication was that there was unnecessary latency since we were accessing the second matrix factor ("B") by its columns rather than its rows. It occurred to me that one way of improving the performance would therefore be to transpose B and then to multiply the rows of A by the rows of B^T....
... But I suppose the cost of doing the transposing work would make this a worse option? And perhaps even worse than just cranking through the naive version?
The text was updated successfully, but these errors were encountered:
It seems unlikely that this would help for a single matrix multiplication. Think about how the transpose has to be implemented. You have to have the matrix B, and a matrix that's the transpose (call it BT). When you're doing the copying, either you have to access the matrix B row-wise and the matrix BT column-wise, or vice-versa, so that operation is not any more cache-friendly, and also not vectorizable with SIMD.
However, if you know that you will want to access B column-wise many times, it may make sense to take the transpose right away and reuse that copy.
The trouble with the naive version of matrix multiplication was that there was unnecessary latency since we were accessing the second matrix factor ("B") by its columns rather than its rows. It occurred to me that one way of improving the performance would therefore be to transpose B and then to multiply the rows of A by the rows of B^T....
... But I suppose the cost of doing the transposing work would make this a worse option? And perhaps even worse than just cranking through the naive version?
The text was updated successfully, but these errors were encountered: