> Virtual memory should have been extended to network resources, but this has not really happened.
I get that we are already operating in heterogeneous virtual memory worlds, but network transactions are so slow. I can't see it being useful to have them as virtual addresses if random reads and writes to network space take literal seconds of round trip. That is so much worse than even disk, there is a reason networking is at most virtual filesystem bound and at least just its own thing above that via URIs.
It really pokes holes in Von Neumann computer models around memory when the memory has heavily disparate access times. You can have networked devices via drivers (like printers) that do have those huge round trip times, or you can have cache hits that give you single digit cycle retrieval. It is NUMA before you even get to the hardware version.
> Reject the notion that one program talking to another should have to invoke some “input/output” API. You’re the human, and you own this machine. You get to say who talks to what when, why, and how if you please. All this software stuff we’re expected to deal with — files, sockets, function calls — was just invented by other mortal people, like you and I, without using any tools we don’t have the equivalent of fifty thousand of. Let’s do some old-school hacking on our new-school hardware — like the original TX-0 hackers, in assembly, from the ground up — and work towards a harmonious world where there is something new in software systems for the first time since 1969.
So if you had a machine executing code - without an operating system - it would need to pull in functions from disk or something whenever they get invoked by another program? And have some means to deduce which function that is, via some mechanism to scan the filesystem to find it. Because you need to discretize out "programs" because each one is inherently insular in its world view. So you just execute dynamic code that invokes other dynamic code.
That sounds like a real big performance hit, though, to have an indirection on every function call to see if its property resident in memory or just fake - at least a conditional every time saying "is this function at 0x00? then it needs to be looked up!".
Virtualization and network resources have a long and glorious research history, although most, if not all, of the approaches are not currently in fashion. (And maybe there's a good reason for that?[1])
"Distributed memory" is one example. Once upon a time it was a big deal. I suppose that things like iSCSI could be regarded as an application, but that is the only use I know about that's at all recent.
"Remote procedure calls", "distributed objects" and stuff like that could be seen as "virtualization", if you like. I suspect all of the major advocates of these have either recanted or died off---at least I hope so. When I'm wearing my network-protocol-guy hat, I hate these things with the fiery passion of a thousands suns.
[1] See http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.7..., "A Note on Distributed Computing" by Jim Waldo, Geoff Wyant, Ann Wollrath, and Sam Kendall, from Sun ca. 1994, for some early, clear, and correct reasons why making remote things look like local things doesn't work as well as you might think.
> I can't see it being useful to have them as virtual addresses if random reads and writes to network space take literal seconds of round trip.
It's just another stage of the storage hierarchy, isn't it? Registers → CPU cache → DRAM → Flash storage → spinning-rust storage → network storage → archive storage.
It's not practical to cover all of those with the one abstraction (having a CPU read-byte instruction pause while a robot navigates a warehouse to find the right backup tape is a bit ridiculous), but what we have at the moment is mostly a reflection of the way our technology ecosystem has developed, rather than the best way to organise and cache information.
Local networking can be significantly faster than accessing a hard drive. It's very common to have only network filesystems. Look at EC2, for example. Toss a cache on it and everything's good.
This indirection already happens in present systems. Check out my previous blog post about it:
http://davidad.github.io/blog/2014/02/19/relocatable-vs-posi...
Modern hardware is optimized to do this kind of indirection reasonably fast. What I propose can exploit the same hardware acceleration.
perhaps it was meant in a different sense- I thought he meant that a "socket" resource shouldn't have the programmer specifying the physical hardware and port number while other programs have the ability of monopolising that resource.
I get that we are already operating in heterogeneous virtual memory worlds, but network transactions are so slow. I can't see it being useful to have them as virtual addresses if random reads and writes to network space take literal seconds of round trip. That is so much worse than even disk, there is a reason networking is at most virtual filesystem bound and at least just its own thing above that via URIs.
It really pokes holes in Von Neumann computer models around memory when the memory has heavily disparate access times. You can have networked devices via drivers (like printers) that do have those huge round trip times, or you can have cache hits that give you single digit cycle retrieval. It is NUMA before you even get to the hardware version.
> Reject the notion that one program talking to another should have to invoke some “input/output” API. You’re the human, and you own this machine. You get to say who talks to what when, why, and how if you please. All this software stuff we’re expected to deal with — files, sockets, function calls — was just invented by other mortal people, like you and I, without using any tools we don’t have the equivalent of fifty thousand of. Let’s do some old-school hacking on our new-school hardware — like the original TX-0 hackers, in assembly, from the ground up — and work towards a harmonious world where there is something new in software systems for the first time since 1969.
So if you had a machine executing code - without an operating system - it would need to pull in functions from disk or something whenever they get invoked by another program? And have some means to deduce which function that is, via some mechanism to scan the filesystem to find it. Because you need to discretize out "programs" because each one is inherently insular in its world view. So you just execute dynamic code that invokes other dynamic code.
That sounds like a real big performance hit, though, to have an indirection on every function call to see if its property resident in memory or just fake - at least a conditional every time saying "is this function at 0x00? then it needs to be looked up!".