5 ms·

Why broken? If they're on the same core then they share the L1/L2 cache which is as fast as it can get. Why can't I have fast, low instruction cost communicati

Why broken? If they're on the same core then they share the L1/L2 cache which is as fast as it can get. Why can't I have fast, low instruction cost communication between any two CPUs, regardless of which core it's on? In other words, why do I have to do that bookkeeping to have super fast communication between threads/actors? Peeps who do chips aren't stupid. It's probably laws of physics rather than incompetence that stopping it, and if it isn't that then it's economics. The RISC revolution was in part due to "peeps who do chips" getting stuck in their ways, succumbing to CISC group-think, and forgetting to "play Moneyball" with price/performance. I don't think communication between threads was so much an issue in the past. But if it works, well, cache line snooping is, I guess, exceedingly fast so why not. Is it really worth sacrificing an entire cache line to do it? Are there other communication mechanisms which could achieve the same or higher speeds with a smaller component count? I don't see how it would violate the laws of physics if the answers were no and yes.

tempguy9999 7y ago
> Why can't I have fast, low instruction cost communication between any two CPUs, regardless of which core it's on? Fizzics, specifically a mixture of C and some electrical crap about signal propagation which I don't unnerstand. Einstein, he say no. > The RISC revolution was in part true I suppose. Even dumber things were reputed to have been done in the design of the SPARC chips. > Is it really worth sacrificing an entire cache line to do it? First show me where this is mentioned in the doc. Second, yeah, why not. If you can pass 512 bits of info between threads in a few cycles, sounds ok to me. If you want another mechanism, be prepared to pay for it. Memory has been around for ages, it's well understood, and bloody fast. It'd be stupid not to use it. Look, you can't just have stuff cos you want it. You've given no reason for needing it, or that you understand the tradeoffs at the hardware level, or any appreciation of the blinding speed of current chips. How would faster XYZ improve your life? Go and read <https://www.amazon.co.uk/Computer-Architecture-Quantitative-Approach-Kaufmann/dp/0128119055/> https://www.amazon.co.uk/Computer-Architecture-Quantitative-... then maybe you'll understand your plaint is falling on uninterested ears (mine anyway). Suggest something constructive based on the realities of hardware then I'll talk.
dragontamer 7y ago
> Why can't I have fast, low instruction cost communication between any two CPUs, regardless of which core it's on? In other words, why do I have to do that bookkeeping to have super fast communication between threads/actors? L1 cache is literally inside of the core of modern chips. You can't beat its speed because its physically the closest speed possible. Moving cache further away (ex: L2 or L3) means more wires, more capacitance, and slower electricity. Electricity doesn't move instantly: it has to fight the capacitance of wires. The wider the wires, the more electrons you need to put onto the wire before its voltage changes. There's also inductance: the longer the wire is, the longer you need to hold a voltage before electrons actually decide to move. Second: L1 caches do a LOT of book-keeping for you. All cores on modern systems (anything more modern than DEC Alpha from the 90s) will have cache coherence automatically. That's downright huge, and modern multithreaded programming would be damn near impossible without the ordering guarantees of basic cache coherence. (yes: even ARM / MIPS and their "relaxed memory model" are more coherent than chips from earlier eras). So first of all, be gracious about the level of memory ordering available to the modern programmer. ------------ So how are caches coherent? Most modern caches use some form of MESI to communicate with each other (invisibly: this is "below" assembly language and is happening at the hardware level). When one cache claims "exclusive access" to the data, no other cache will write to it (although they may read stale versions of that data from their own cache). When that core / L1 cache is done, it will "invalidate" the data. Modern cache coherence protocols can go faster: MESIF for Intel means that writes may be (F)orwarded to other caches automatically (which is slightly faster than (E)xclusive -> (I)nvalid -> (E)xclusive in the 2nd core). Again, this is all done automatically, because programmers want to have their data look the same from all cores (for some definition of "looks the same"). This does NOT mean that the data is in the correct order however (!!). L1 caches can change the order of reads and writes before the data is shipped to other cores. Indeed, this is the very POINT of L1 cache. If one core is doing a while(true) iter++; loop, its more efficient to merge the writes together and "batch" them out slowly. Ex: Core#2 may see "1, 10, 33, 600" each time it reads the value of "iter". Indeed, the most efficient implementation of this while(true) iter++; loop is to have "iter" be a register private to a core that has absolutely no communication to the outside world at all.
- tempguy9999 7y ago
imtringued 7y ago
Why do you need faster communication mechanisms? Unless you're "burning" an entire core via busy waiting which costs some performance you will never reach the latency limits of the cache. Your bottleneck will not the communication mechanism, rather the bottleneck will be that the receiver isn't processing the messages fast enough. If your problem is really that time critical then using a CPU was a huge mistake in the first place. What you want is an FPGA.

tempguy9999 7y ago

> Why can't I have fast, low instruction cost communication between any two CPUs, regardless of which core it's on? Fizzics, specifically a mixture of C and some electrical crap about signal propagation which I don't unnerstand. Einstein, he say no. > The RISC revolution was in part true I suppose. Even dumber things were reputed to have been done in the design of the SPARC chips. > Is it really worth sacrificing an entire cache line to do it? First show me where this is mentioned in the doc. Second, yeah, why not. If you can pass 512 bits of info between threads in a few cycles, sounds ok to me. If you want another mechanism, be prepared to pay for it. Memory has been around for ages, it's well understood, and bloody fast. It'd be stupid not to use it. Look, you can't just have stuff cos you want it. You've given no reason for needing it, or that you understand the tradeoffs at the hardware level, or any appreciation of the blinding speed of current chips. How would faster XYZ improve your life? Go and read <https://www.amazon.co.uk/Computer-Architecture-Quantitative-Approach-Kaufmann/dp/0128119055/> https://www.amazon.co.uk/Computer-Architecture-Quantitative-... then maybe you'll understand your plaint is falling on uninterested ears (mine anyway). Suggest something constructive based on the realities of hardware then I'll talk.

dragontamer 7y ago

> Why can't I have fast, low instruction cost communication between any two CPUs, regardless of which core it's on? In other words, why do I have to do that bookkeeping to have super fast communication between threads/actors? L1 cache is literally inside of the core of modern chips. You can't beat its speed because its physically the closest speed possible. Moving cache further away (ex: L2 or L3) means more wires, more capacitance, and slower electricity. Electricity doesn't move instantly: it has to fight the capacitance of wires. The wider the wires, the more electrons you need to put onto the wire before its voltage changes. There's also inductance: the longer the wire is, the longer you need to hold a voltage before electrons actually decide to move. Second: L1 caches do a LOT of book-keeping for you. All cores on modern systems (anything more modern than DEC Alpha from the 90s) will have cache coherence automatically. That's downright huge, and modern multithreaded programming would be damn near impossible without the ordering guarantees of basic cache coherence. (yes: even ARM / MIPS and their "relaxed memory model" are more coherent than chips from earlier eras). So first of all, be gracious about the level of memory ordering available to the modern programmer. ------------ So how are caches coherent? Most modern caches use some form of MESI to communicate with each other (invisibly: this is "below" assembly language and is happening at the hardware level). When one cache claims "exclusive access" to the data, no other cache will write to it (although they may read stale versions of that data from their own cache). When that core / L1 cache is done, it will "invalidate" the data. Modern cache coherence protocols can go faster: MESIF for Intel means that writes may be (F)orwarded to other caches automatically (which is slightly faster than (E)xclusive -> (I)nvalid -> (E)xclusive in the 2nd core). Again, this is all done automatically, because programmers want to have their data look the same from all cores (for some definition of "looks the same"). This does NOT mean that the data is in the correct order however (!!). L1 caches can change the order of reads and writes before the data is shipped to other cores. Indeed, this is the very POINT of L1 cache. If one core is doing a while(true) iter++; loop, its more efficient to merge the writes together and "batch" them out slowly. Ex: Core#2 may see "1, 10, 33, 600" each time it reads the value of "iter". Indeed, the most efficient implementation of this while(true) iter++; loop is to have "iter" be a register private to a core that has absolutely no communication to the outside world at all.

tempguy9999 7y ago

imtringued 7y ago

Why do you need faster communication mechanisms? Unless you're "burning" an entire core via busy waiting which costs some performance you will never reach the latency limits of the cache. Your bottleneck will not the communication mechanism, rather the bottleneck will be that the receiver isn't processing the messages fast enough. If your problem is really that time critical then using a CPU was a huge mistake in the first place. What you want is an FPGA.