Earlier quoted context omitted.
Ten years too early.... https://parallella.org/2015/05/25/how-the-do-i-program-the-p...
Nope, Parallela was the wrong thing at the time and it's still wrong. Cache is good.
Absolute statements are bad.
Core to core latency data on large systems
21–30 of 32 posts
Re: Core to core latency data on large systems
#22I was misreading these charts for too long. Maybe I still am. Am I seeing that none of these processors implement a toroidal communication path? I thought that was considered basic cluster topology these days so I’m surprised that multi core chips don’t implement it.
If your chip is fabricated on a flat rectangular piece of silicon, that would involve links running from each edge, across the chip, to the other edge, in both orientations. I can imagine that would be very demanding of chip resources, slow, etc.
If your chip is fabricated on the surface of a torus, or on a rectangle in highly curved space, then it would be a very natural architecture. But i am not aware of any chips that are.
Re: Core to core latency data on large systems
#23The NUMA nature of recent* chips has made me wonder if there’s ever going to be a movement to start using message passing libraries (like MPI) on shared memory machines. * actually, not even that recent, Zen planted this hope in my brain.
In HPC it's common to do a mix of MPI (message-passing / distributed memory) and OpenMP (shared memory) parallelism when running on big multicore (and obviously multi-node) machines. It helps with locality, among other things.
This is what I do actually, and it works fairly well. Currently I do one MPI process per socket, but mostly just because the OpenMP code I’m calling is a library, and it doesn’t seem to scale well past one modern Xeon worth of cores.
I don’t know what I’d do if I had an old Zen machine, maybe map an MPI process to each chiplett.
My impression is that in the first generation Zen machines, the cost of communicating from one chiplett to another was really quite significant, but they’ve made good enough progress there that it is only something that the really hardcode folks care about.
Re: Core to core latency data on large systems
#24Earlier quoted context omitted.
Nope, Parallela was the wrong thing at the time and it's still wrong. Cache is good.
> Nope, Parallela was the wrong thing at the time and it's still wrong. Can you elaborate?
It didn't have DRAM or caches. Programming with scratchpads is so difficult that people just give up.
Re: Core to core latency data on large systems
#25The NUMA nature of recent* chips has made me wonder if there’s ever going to be a movement to start using message passing libraries (like MPI) on shared memory machines. * actually, not even that recent, Zen planted this hope in my brain.
I don't know where you got that idea from. There is a movement in the complete opposite direction with CXL. Don't waste your time with silly libraries, serialisation or networking. Have a rack that is filled with nothing but memory pooled RAM and then connect your servers (which still retain RAM as a L4 cache). You now have a huge shared memory machine with distributed CPUs using CXL for cache coherence accross the entire system. There have been benchmarks that kept 75% of the memory outside the server and the performance degradation was only 10% compared to keeping the entire data set on a single server.
Re: Core to core latency data on large systems
#26Earlier quoted context omitted.
> Nope, Parallela was the wrong thing at the time and it's still wrong. Can you elaborate?
It didn't have DRAM or caches. Programming with scratchpads is so difficult that people just give up.
Scratchpads are the memory equivalent of VLIW.
Processors can extract parallelism dynamically at runtime. They can also manage your memory automatically at run time. Better yet, they can utilize hardware resources instead of software resources. It is such an obvious win.
Re: Core to core latency data on large systems
#27Earlier quoted context omitted.
Thread-per-core software architectures are doing this https://penberg.org/papers/tpc-ancs19.pdf Real world examples are scylladb and Redpanda, both built on the seastar framework (C++ https://seastar.io/message-passing/ ). And for rust there is glommio https://www.datadoghq.com/blog/engineering/introducing-glomm...
Does thread per core necessarily imply message passing? I don't see why the two need to be related.
The thread-per-core manifesto has a goal of not sharing data between cores, and thus the communication inside the process becomes message passing, handing off ownership of a chunk of data to the recipient core. This lack of sharing is what enables the performance (no locks etc needed, outside of the message passing).
This is a good watch (first half is pure background, second half talks about the motivation): https://www.youtube.com/watch?v=PbgTyCSDPrs
Re: Core to core latency data on large systems
#28Earlier quoted context omitted.
It didn't have DRAM or caches. Programming with scratchpads is so difficult that people just give up.
Scratchpads are the memory equivalent of VLIW. Processors can extract parallelism dynamically at runtime. They can also manage your memory automatically at run time. Better yet, they can utilize hardware resources instead of software resources. It is such an obvious win.
Are you saying that scratchpads were like VLIW in the sense that they seemed like a really cool idea, but failed because people didn’t want to manually code things well enough to take advantage of them?
Re: Core to core latency data on large systems
#29If I'm reading this right socket-to-socket latency hasn't really improved much in a long time, why?
Re: Core to core latency data on large systems
#30I was misreading these charts for too long. Maybe I still am. Am I seeing that none of these processors implement a toroidal communication path? I thought that was considered basic cluster topology these days so I’m surprised that multi core chips don’t implement it.
If your chip is fabricated on a flat rectangular piece of silicon, that would involve links running from each edge, across the chip, to the other edge, in both orientations. I can imagine that would be very demanding of chip resources, slow, etc. If your chip is fabricated on the surface of a torus, or on a rectangle in highly curved space, then it would be a very natural architecture. But i am not aware of any chips…
I would presume the first couple of layers of silicon would be wires instead of gates. At least at the edges. Top left to top right,
Bottom left to bottom right, top left to bottom left, top right to bottom right.
The middle of the chip could contain logic.