3 ms·

You seem to be living in an imaginary world where main memory is much, much closer to the CPU than it is in real life. 10,000ns is 174 cache misses on my machin

You seem to be living in an imaginary world where main memory is much, much closer to the CPU than it is in real life. 10,000ns is 174 cache misses on my machine. That's not a lot of room when you are popping something off a queue or finishing an IO.

JoeAltmaier 10y ago
The presumption of large cache misses is where our intuitions diverge. Algorithms where threads operated on the same data, for instance, would not actually have many cache misses or even zero cache misses. btw Lets take it down a notch, and back off on the personal aspersions? ok?
- luckydude 10y ago
  Sorry if it sounds personal, it's not intended to be so. I get weird when I see people not seeing all of the picture. To me, the picture includes main memory, I've spent way too much time with a logic analyzer watching stuff go across the bus (actually did a lot of this while tuning some hashing code for performance). Memory misses are a fact of life. If you look at my comments elsewhere, I noted that CPU: 20x faster Main memory: 3x faster Context switch: about the same If memory wasn't the main part of the equation, shouldn't the context switches be faster? Yes, as I pointed out, the OS is now fine grained multi threaded but that doesn't explain a 20x difference. As for the comment that some stuff is going to have zero cache misses, sure, in theory. Can you show any real world examples of that? I would think that anything that takes a lock on more than one cpu/cache is going to have lock traffic that is going to cause a cache miss like stall. Has cache coherency changed such that locks are "free"? That would be (interesting) news to me.
  - JoeAltmaier 10y ago
    The question is, would multiple threads have any essential difference from another embodiment e.g. procedural. If not, then the (only) gain is being able to recast the problem as threads, for whatever that's worth. If thinking about an algorithm as synchronization-of-data is helpful, then the low-or-zero-latency-added thread model is helpful.

JoeAltmaier 10y ago

The presumption of large cache misses is where our intuitions diverge. Algorithms where threads operated on the same data, for instance, would not actually have many cache misses or even zero cache misses. btw Lets take it down a notch, and back off on the personal aspersions? ok?

luckydude 10y ago
Sorry if it sounds personal, it's not intended to be so. I get weird when I see people not seeing all of the picture. To me, the picture includes main memory, I've spent way too much time with a logic analyzer watching stuff go across the bus (actually did a lot of this while tuning some hashing code for performance). Memory misses are a fact of life. If you look at my comments elsewhere, I noted that CPU: 20x faster Main memory: 3x faster Context switch: about the same If memory wasn't the main part of the equation, shouldn't the context switches be faster? Yes, as I pointed out, the OS is now fine grained multi threaded but that doesn't explain a 20x difference. As for the comment that some stuff is going to have zero cache misses, sure, in theory. Can you show any real world examples of that? I would think that anything that takes a lock on more than one cpu/cache is going to have lock traffic that is going to cause a cache miss like stall. Has cache coherency changed such that locks are "free"? That would be (interesting) news to me.
- JoeAltmaier 10y ago
  The question is, would multiple threads have any essential difference from another embodiment e.g. procedural. If not, then the (only) gain is being able to recast the problem as threads, for whatever that's worth. If thinking about an algorithm as synchronization-of-data is helpful, then the low-or-zero-latency-added thread model is helpful.