Live data from Hacker News

Matrix Multiplication Inches Closer To Mythic Goal

quantamagazine.org

41–50 of 53 posts

Re: Matrix Multiplication Inches Closer To Mythic Goal

#41

It would be interesting to put this in perspective in regards to total energy savings. Since so much of computation is matrix multiplication, how much computational power integrated over the next decade would we say that the exponent going from 3->2.3 has saved?

None. Afaik, all practical implementations of matrix multiplication execute the naive n^3 algorithm because sub-cubic algorithms have too large constant overheads and/or are numerically unstable.

Re: Matrix Multiplication Inches Closer To Mythic Goal

#42

The part I don't follow is that I thought multiplication used the same number of CPU cycles as addition, so I didn't get the the part where one multiplication replaced with many additions was obviously better. Could someone explain that part? I feel I must be fundamentally misunderstanding something.

If you look at operations per cycle, in this example for Intel Haswell processors, you'll find that an equivalent add and multiple are quite a bit different. An add/subtract from a 32 bit register to register is 0.25 cycles per operation. A multiply from 32 bit register to register is 2 cycles per operation. So a 8x speed difference, not counting for latency, etc. See page 230 and 231 of this paper: https://www.agner…

For what it's worth, what counts for normal implementations is the number of multiply-add operations per cycle, typically two on current hardware with FMA.

Re: Matrix Multiplication Inches Closer To Mythic Goal

#43
post #41

It would be interesting to put this in perspective in regards to total energy savings. Since so much of computation is matrix multiplication, how much computational power integrated over the next decade would we say that the exponent going from 3->2.3 has saved?

None. Afaik, all practical implementations of matrix multiplication execute the naive n^3 algorithm because sub-cubic algorithms have too large constant overheads and/or are numerically unstable.

Fascinating! I wonder if the instability could be kept small enough to be accurate enough for graphic applications (for power savings)… What if the constants were hardware stored in the silicon? :)

Re: Matrix Multiplication Inches Closer To Mythic Goal

#44
post #6

Which one of these algos does Intel/Nvidia/Google use in their AVX/Cuda/TPU implementations?

Simple block partitioning, usually 4x4, with the full ordinary algorithm per block. This is the most numerically-stable and parallel. https://developer.nvidia.com/blog/cutlass-linear-algebra-cud...

However, on recent CPUs 4x4 is small for the innermost block size of the non-trivial hierarchy you need. You can see examples under https://github.com/flame/blis/tree/master/config with an a priori procedure for determining them in https://www.cs.utexas.edu/users/flame/pubs/TOMS-BLIS-Analyti... (but compare with what's actually used for SKX, in particular). OpenBLAS will normally be similar, though it may come out somewhat faster, but it's easier to see in BLIS.

Re: Matrix Multiplication Inches Closer To Mythic Goal

#45
post #5

Which one of these algos does Intel/Nvidia/Google use in their AVX/Cuda/TPU implementations?

Strassen's method is the only one practical on modern hardware

If it's of interest, there's an account of fairly recent work in the "Strassen reloaded" paper https://dl.acm.org/doi/10.5555/3014904.3014983 or otherwise in https://www.cs.utexas.edu/users/flame/pubs/FLAWN79.pdf

Re: Matrix Multiplication Inches Closer To Mythic Goal

#46
post #17

This thought has been churning around in my mind for some years now — we focus too much on processing speed and reductions in time complexity and not enough on increasing the size and efficiency of our cache and stack . MM (especially MM on large type numbers like e.g. hashing algorithms) are very reliant on the cache because you can’t always fit that big of a number into a register. Side note, I was reading some Abs…

This is kind of like "doctors are spending too much time curing cancer, they should worry about my bathroom, which is flooding!"

Theoretical Computer Scientists aren't going to increase the size of your cache, that's just not what they're into or what they know anything about.

Re: Matrix Multiplication Inches Closer To Mythic Goal

#47
post #41

It would be interesting to put this in perspective in regards to total energy savings. Since so much of computation is matrix multiplication, how much computational power integrated over the next decade would we say that the exponent going from 3->2.3 has saved?

None. Afaik, all practical implementations of matrix multiplication execute the naive n^3 algorithm because sub-cubic algorithms have too large constant overheads and/or are numerically unstable.

People definitely use the more sophisticated algorithms, it just depends on the size of the matrix. Usually exploring computer architecture is more important than the algo, but at a certain size MMM is definitely faster using state of the art algos.

Re: Matrix Multiplication Inches Closer To Mythic Goal

#48

Just for reference: a Google TPU can multiply a 256x256 matrix in 1 clock cycle[1]. That seems astonishingly fast, considering the TPU operates at 700MHz: The TPU Matrix Multiplication Unit has a systolic array mechanism that contains 256 × 256 = total 65,536 ALUs. That means a TPU can process 65,536 multiply-and-adds for 8-bit integers every cycle. Because a TPU runs at 700MHz, a TPU can compute 65,536 × 700,000,000…

It appears that while the TPU is capable of ingesting the inputs of a few matrices each clock cycle, it likely takes several clock cycles for the matrix multiplication operation to percolate through the systolic array pipeline. That means while it may be able to sustain an average of one matrix multiplication per clock cycle, any particular matrix multiplication operation will require multiple cycles before the result is valid.

Re: Matrix Multiplication Inches Closer To Mythic Goal

#50

Just for reference: a Google TPU can multiply a 256x256 matrix in 1 clock cycle[1]. That seems astonishingly fast, considering the TPU operates at 700MHz: The TPU Matrix Multiplication Unit has a systolic array mechanism that contains 256 × 256 = total 65,536 ALUs. That means a TPU can process 65,536 multiply-and-adds for 8-bit integers every cycle. Because a TPU runs at 700MHz, a TPU can compute 65,536 × 700,000,000…

This isn’t exactly correct. A TPU can probably multiply two matrices per clock cycle, but it most likely takes a few hundred cycles for a single operation to be performed. This is similar to how a modern cpu can execute many instructions per cycle, but most instructions take multiple clock cycles to be performed.
Post reply on HN