News for hackers. Stuff that matters.

A comment on With 'The Machine,' HP May Have Invented a New Kind of Computer. Parent comment

Re:With 'The Machine,' HP May Have Invented a New Kind of Co... by sp332 on Wednesday June 11, 2014 @01:56PM (#7879386)
Well, you wouldn't have to save files. You could just use a data structure in main memory because it's non-volatile. But how would you share data between programs when there's no disk? And you could execute binaries directly from storage without "loading" them into memory first. But you'd have to keep an original copy somewhere in case it modifies itself as it runs.
[ Parent | on HN ]
Re:With 'The Machine,' HP May Have Invented a New Kind of Co... by markbnj on Wednesday June 11, 2014 @02:13PM (#7879488)
You'd probably still have memory partitioned into persistent areas and runtime heap of a sort, and you might very well continue to use the file system metaphor because it still makes sense to humans. Whether a file is bits on magnetic disk, in flash memory, or fast persistent RAM isn't all that meaningful to the user. As for sharing, I don't see why this would be an issue. If you have to move memory contents between machines then you still need some sort of external transport, whether it is a network, or a glowing glass cube.
[ Parent | on HN ]
Re:With 'The Machine,' HP May Have Invented a New Kind of Co... by sp332 on Wednesday June 11, 2014 @02:25PM (#7879561)
Filesystem semantics are a bottleneck. Fusion IO had to get rid of them when they demoed their billion-IOPS platform last year. https://news.ycombinator.com/item?id=3434711

For communicating data between programs, would you create a filesystem object that points to memory inside your program, or what?

[ Parent | on HN ]
Re:With 'The Machine,' HP May Have Invented a New Kind of Co... by colanderman on Wednesday June 11, 2014 @03:14PM (#7879868)
That doesn't make any sense. Create a file, memory-map it, bam, you have RAM performance with "filesystem semantics". (There is NO overhead associated with memory-mapping a file on a ramdisk in the Linux kernel.)

Probably what they're referring to is something more along the lines of replacing SCSI or NFS with a protocol that is a better match for the random access patterns used to access in-memory structures. (Hence their 64-byte I/O size; that is equal to a cache line on Intel architectures.)

[ Parent | on HN ]
Re:With 'The Machine,' HP May Have Invented a New Kind of Co... by sp332 on Wednesday June 11, 2014 @04:55PM (#7880399)
Hm, how would this memristor stuff connect to the system? Will it look like a memory controller or more like PCI-e flash?
[ Parent | on HN ]
Re:With 'The Machine,' HP May Have Invented a New Kind of Co... by wmf on Wednesday June 11, 2014 @06:33PM (#7880830)
It sounds like HP is pitching it as memory.
[ Parent | on HN ]
Re:With 'The Machine,' HP May Have Invented a New Kind of Co... by DelwinAmber on Wednesday June 11, 2014 @02:38PM (#7879636)
Yes. On Linux it's /dev/shm and it is a ramdisk that you can access from multiple processes.

IPC (Inter-Process Communication) is a known technology. This won't change it much if at all.

[ Parent | on HN ]
Re:With 'The Machine,' HP May Have Invented a New Kind of Co... by melloclello on Wednesday June 11, 2014 @02:38PM (#7879642)
Continuing to use the file-system metaphor (Instead of, I don't know, anything else, perhaps some kind of global namespace with built-in versioning like Urbit's) seems like lobotomising this incredible new paradigm before it is even born.
[ Parent | on HN ]
Re:With 'The Machine,' HP May Have Invented a New Kind of Co... by markbnj on Wednesday June 11, 2014 @04:09PM (#7880142)
It might be. I'm not arguing that it is the ultimate best metaphor to use, but these things do tend to be adopted organically and become very entrenched.
[ Parent | on HN ]
Re:With 'The Machine,' HP May Have Invented a New Kind of Co... by hderms on Wednesday June 11, 2014 @02:16PM (#7879514)
Took the words right out of my mouth (better said, of course).
[ Parent | on HN ]
Re:With 'The Machine,' HP May Have Invented a New Kind of Co... by hderms on Wednesday June 11, 2014 @02:16PM (#7879507)
I mean, there should still be a need for both the data and code sections of a program. Similarly, some kind of tree-like structure for naming "files" locations (for interprocess communication). I would imagine, at least in the early days of some diskless architecture, we'd have something that looks very similar to how computing is currently done but in one memory space.
[ Parent | on HN ]
Re:With 'The Machine,' HP May Have Invented a New Kind of Co... by colanderman on Wednesday June 11, 2014 @04:14PM (#7880167)
And you could execute binaries directly from storage without "loading" them into memory first.

Linux already does this. Program code is cached copy-on-write in shared memory. The fact that, say, bash has to be loaded from disk once is pretty much irrelevant. After that, the kernel's just managing pointers.

[ Parent | on HN ]
Re:With 'The Machine,' HP May Have Invented a New Kind of Co... by danmaz74 on Wednesday June 11, 2014 @02:31PM (#7879596)
I think there would still be a need for "files", ie, a way to store a self-contained document format in memory that is independent from the code that is working on the data at one exact moment: to allow moving documents between computers, but also to allow updating the software in a safe way (ie without losing data), to save older version of a document, but most importantly IMHO to be able to create snapshots that can be safely reloaded in case of a system crash. We're not ready to have systems that can't be rebooted.
[ Parent | on HN ]
Re:With 'The Machine,' HP May Have Invented a New Kind of Co... by colanderman on Wednesday June 11, 2014 @03:02PM (#7879797)
Filesystems aren't going to disappear. Databases haven't disappeared, even though there exist 256 GB RAM monsters in data warehouses.

The logical structure of a filesystem is still a useful abstraction (and has been decoupled from physical constraints for a long time now).

[ Parent | on HN ]
Re:With 'The Machine,' HP May Have Invented a New Kind of Co... by bkurtz13 on Wednesday June 11, 2014 @02:14PM (#7879495)
Some kind of git-like diff-based snapshot system for programs?
[ Parent | on HN ]
Re:With 'The Machine,' HP May Have Invented a New Kind of Co... by yeukhon on Wednesday June 11, 2014 @02:30PM (#7879587)
What's the issue with RAM disk to address your concern about "no disk"?
[ Parent | on HN ]
Re:With 'The Machine,' HP May Have Invented a New Kind of Co... by sp332 on Wednesday June 11, 2014 @02:57PM (#7879762)
It's a lot of unnecessary copying. The data is already in RAM, but you "save" it to a different RAM location, in the RAM disk. Or if you do all your work directly on the file in the RAM disk, you have to deal with filesystem overhead constantly.
[ Parent | on HN ]
Re:With 'The Machine,' HP May Have Invented a New Kind of Co... by colanderman on Wednesday June 11, 2014 @04:10PM (#7880144)
Or if you do all your work directly on the file in the RAM disk, you have to deal with filesystem overhead constantly.

Not so. Take a look at the Linux kernel implementation of memory-mapped ramdisk files. There is no "filesystem overhead". Zero. The kernel pretty much sets up the page mapping and then is hands-off.

Even if your memory mapping is backed by a file on a block device, the only overhead is occasional paging to disk. This happens on the order of SECONDS… not "constantly"!

[ Parent | on HN ]
Re:With 'The Machine,' HP May Have Invented a New Kind of Co... by sp332 on Wednesday June 11, 2014 @05:06PM (#7880443)
That's assuming you already have a file and know how big it should be. Or does it take the whole space for one file, and every program on the computer shares the space?
[ Parent | on HN ]
Re:With 'The Machine,' HP May Have Invented a New Kind of Co... by colanderman on Wednesday June 11, 2014 @07:45PM (#7881081)
Files can be both sparsely and dynamically allocated.
[ Parent | on HN ]
Re:With 'The Machine,' HP May Have Invented a New Kind of Co... by AnthonyMouse on Wednesday June 11, 2014 @06:29PM (#7880812)
You save things to persistent storage because you want the copy. In the large majority of cases the format on the filesystem is different from the format in memory because the file format is meant to be more readable by humans or by machines with a different endianness or pointer size etc., whereas data in memory is binary and platform-specific to optimize for fast access by the local machine. The benefit of that distinction doesn't go away just because you make the persistent storage faster.
[ Parent | on HN ]