5 ms·

A 128bit address space would be fun. Of course as the page mentions, if you want to use IPv6 for this, you actually want something more like a 196bit address sp

by com2kid 13y ago

A 128bit address space would be fun. Of course as the page mentions, if you want to use IPv6 for this, you actually want something more like a 196bit address space or just round it up to a 256bit address space. Imagine all the world's computers running in a single unified address space. All network access is abstracted away, loading a resource is as simple as loading a memory address. It would be like a new golden era for C! Rather than using URIs or some sort of XML addressing schema or whatever else people decide to invent, instead, all the world's information and knowledge from all around the world (solar system, universe?) is available through one unified address space. Although I imagine we'd still need some sort of DNS system running on top. ;)

wmf 13y ago
Imagine all the world's computers running in a single unified address space. All network access is abstracted away, loading a resource is as simple as loading a memory address. The standard rebuttal to this thinking is Waldo et al. "A Note on Distributed Computing" from 1994. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.7628 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.7... "We argue that objects that interact in a distributed system need to be dealt with in ways that are intrinsically different from objects that interact in a single address space. These differences are required because distributed systems require that the programmer be aware of latency, have a different model of memory access, and take into account issues of concurrency and partial failure."
- SoftwareMaven 13y ago
  In nearly 20 years of building distributed systems, this has held true every. single. time. Trying to abstract away the distributed nature of a system inevitably leads to pain and sorrow. I think having explicit knowledge about what is local and what is remote is critical, but having a single, universal address space, so any application can reference any resource, anywhere, when it logically needs to, would be great. They are just different things.
- 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 ago
    While 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 ago
      Compare 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 ago
    It 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.
al2o3cr 13y ago
"It would be like a new golden era for C!" Well, it'd certainly be a new golden era for DRAM manufacturers as every pointer in the system bloats up to 8x original size just to support a 0.1% use case...
danellis 13y ago
> All network access is abstracted away Which is a BAD thing, because it's one hell of a leaky abstraction. http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Comput...
- com2kid 13y ago
  Working in embedded, I am used to assuming most of those working with just local resources. > 1.The network is reliable. I don't assume my file system is reliable. Flash fails. > 2.Latency is zero. Latency is non-0 even on local access! My team's requirements is that anything that may take more than ~1ms is done async. This includes memcopy! > 3.Bandwidth is infinite. Never has been, even locally. > 4.The network is secure. Local busses are not secure either. > 5.Topology doesn't change. I'll give'em that, although this is hopefully less of a problem now days, ignoring NATs... > 6.There is one administrator. Again, the industry has hopefully evolved to understand finer grained access controls. > 7.Transport cost is zero. Nope, never has been even locally. You doing something consumes resources from someone else. > 8.The network is homogeneous. Half the fun is in things being heterogeneous! Put work where it is best done at.

by com2kid 13y ago

wmf 13y ago

Imagine all the world's computers running in a single unified address space. All network access is abstracted away, loading a resource is as simple as loading a memory address. The standard rebuttal to this thinking is Waldo et al. "A Note on Distributed Computing" from 1994. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.7628 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.7... "We argue that objects that interact in a distributed system need to be dealt with in ways that are intrinsically different from objects that interact in a single address space. These differences are required because distributed systems require that the programmer be aware of latency, have a different model of memory access, and take into account issues of concurrency and partial failure."

SoftwareMaven 13y ago
In nearly 20 years of building distributed systems, this has held true every. single. time. Trying to abstract away the distributed nature of a system inevitably leads to pain and sorrow. I think having explicit knowledge about what is local and what is remote is critical, but having a single, universal address space, so any application can reference any resource, anywhere, when it logically needs to, would be great. They are just different things.
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 ago
  While 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 ago
    Compare 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 ago
  It 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.

al2o3cr 13y ago

"It would be like a new golden era for C!" Well, it'd certainly be a new golden era for DRAM manufacturers as every pointer in the system bloats up to 8x original size just to support a 0.1% use case...

danellis 13y ago

> All network access is abstracted away Which is a BAD thing, because it's one hell of a leaky abstraction. http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Comput...

com2kid 13y ago
Working in embedded, I am used to assuming most of those working with just local resources. > 1.The network is reliable. I don't assume my file system is reliable. Flash fails. > 2.Latency is zero. Latency is non-0 even on local access! My team's requirements is that anything that may take more than ~1ms is done async. This includes memcopy! > 3.Bandwidth is infinite. Never has been, even locally. > 4.The network is secure. Local busses are not secure either. > 5.Topology doesn't change. I'll give'em that, although this is hopefully less of a problem now days, ignoring NATs... > 6.There is one administrator. Again, the industry has hopefully evolved to understand finer grained access controls. > 7.Transport cost is zero. Nope, never has been even locally. You doing something consumes resources from someone else. > 8.The network is homogeneous. Half the fun is in things being heterogeneous! Put work where it is best done at.