←back to thread

507 points martinald | 1 comments | | HN request time: 0s | source
Show context
qrios ◴[] No.45053956[source]
For sure an interesting calculation. Only one remark from someone with GPU metal experience:

> But compute becomes the bottleneck in certain scenarios. With long context sequences, attention computation scales quadratically with sequence length.

Even if the statement about quadratically scales is right, the bottleneck we are talking about is somewhere north by factor 1000. If 10k cores do only simple matrix operations each needs to have new data (up to 64k) available every 500 cycles (let's say). Getting these amount of data (without _any_ collision) means something like 100+GByte/s per core. Even 2+TByte/s on HBM means the bottleneck is the memory transfer rate, by something like 500 times. With collision, we talk about an additional factor like 5000 (last time I've done some tests with a 4090).

replies(1): >>45054207 #
Onavo ◴[] No.45054207[source]
What do you mean by collision?
replies(2): >>45054438 #>>45054585 #
qrios ◴[] No.45054585[source]
If multiple cores tries to get the same memory addresses, the MMU feeds only one core, the second one have to whait. Depends on the type of RAM, this will cost a lot of cycles.

GPU MMUs can handle multiple line in parallel. But not 10k cores at the same time. The HBM is not able to transfer 3.5TByte sequencial.

replies(1): >>45054631 #
whatshisface ◴[] No.45054631[source]
Why is that? It seems like multiple cores requesting the same address would be easier for the MMU to fetch for, not harder.
replies(3): >>45054700 #>>45054872 #>>45057841 #
1. qrios ◴[] No.45054700[source]
This is not my domain, but I assume the MMUs acting like a switch and something like multicast is not available here. I‘ve tried to implement such on a FPGA and it was extremely cost intensiv.