7 ms·
I'd argue that at this point one has to be aware of latency and concurrency on the local system also, and any programming model ignores this at their peril. It
by TheLoneWolfling 13y ago
I'd argue that at this point one has to be aware of latency and concurrency on the local system also, and any programming model ignores this at their peril.
It's the greatness of the potential of failure/hang on all actions that separates local RAM access from distributed computing. You don't generally need to worry about your app hanging indefinitely because of a memory read.
- jerf 13y agoWhile true, there's enough orders of magnitude in play that the same mechanisms can only rarely be optimal for both. Reaching into a chunk of NUMA space you don't own vs. reaching out to a highly-contended hard drive on the other side of the world are forever likely to be too different to unify.
- com2kid 13y agoCompare order of magnitude for register access versus cache versus RAM versus HDD. With page files, all of those are treated the same by the programmer. Local HDD can already have access latency similar to the local network! It is another order of magnitude to go beyond that. Meh. Reliability is, IMHO, the bigger issue.
- dllthomas 13y ago"Local HDD can already have access latency similar to the local network!" Right, there are situations where "in RAM on that other computer" is closer than "on my disk".
- jerf 13y ago"With page files, all of those are treated the same by the programmer." In many cases we just don't care, because a CPU hooked up to RAM is still pretty fast for many use cases. When you do care, this abstraction is actually a huge problem! I think this demonstrates my point, not refutes it.
- dllthomas 13y agoIt might be more interesting to treat these things as a memory mapped device, and just cough up whatever is currently there rather than fetching (blocking!) at every access. Would quite obviously have its own issues, though.