3

Think about persistent storage that can preserve pointers: among other things there is no need to serialize/deserialize data. For example, you typically build a tree structure and then serialize it into XML so that it can be stored permanently on disk. Now there is no need for that: the structure in memory can be left there as is, possibly given a name, so that it can be used by other programs.

Thus the concepts of loading/saving may be transformed into something else, if not eliminated altogether. File systems can become something entirely different: e.g. just memory with symbolic labels.

Serialization will still be used in network communication of course. Besides, considering process isolation, memory protection etc, the scenario above may be a bit more complicated than that. One thing is clear though: large persistent addressable storage can at least save a lot of time, and at most cause paradigm shifts in programming. It would be interesting to hear your insights on this.

Improve this question
7
  • large websites are already operating in a similar fashion. most your data is almost surely stored in memory somewhere - but it might be located on a machine thousands of miles away. Memristor simply makes ultra-high memory capacity possible; it isn't going to bring a change in programming paradigm. Perhaps you are looking for content-addressable memory? (that's not a new concept anyway.)
    – rwong
    Commented Apr 22, 2011 at 6:54
  • 6
    I have the feeling that you are severely misrepresenting what a memristor is. (Note: I am not an electrical engineer, so I only understand about 1% of it myself.) Devices which can save state when powered off have existed for a long time: they are called hard disks. More recently, Flash memory has become the new hype. MRAM and FeRAM also can do that, and are not quite as fast as DRAM and certainly not SRAM, but still significantly faster than Flash (and let's not even talk about hard disks). That's not what a memristor is really about (although it is definitely a possible use case).
    – Jörg W Mittag
    Commented Apr 22, 2011 at 11:10
  • 3
    You can most definitely store pointers on hard disks. On operating systems like Windows or Linux or OSX, pointers can't point to structures on the hard disk, but that's just a limitation of those operating systems, not of hard disks. It's simply because pointers are "memory" addresses and hard disks aren't part of the address space. However, on other operating systems, they are part of the address space, and thus pointers can point to objects on the hard disks. On OS/400, for example, you can't even tell whether an object is in memory or on disk. ...
    – Jörg W Mittag
    Commented Apr 22, 2011 at 11:13
  • ... Interestinly, OS/400 doesn't really have pointers, either. It has opaque object references. And this even goes all the way down to the CPU.
    – Jörg W Mittag
    Commented Apr 22, 2011 at 11:15
  • @Jörg W Mittag: If we go earlier, CRT memory and mercury memory had to be constantly refreshed, but core was stable when powered off (it had to be rewritten only when read). Where I work, we have no problems with writing complicated data structures out and reading them back.
    – David Thornley
    Commented Apr 22, 2011 at 14:03

4 Answers 4

Reset to default
2

No, this doesn't change any paradigms. What you're describing is a large / seemingly unbounded shared memory model which we've had for quite a long time. Of course, as soon as we think we have a lot of memory, it seems that the problem space quickly expands to fill it.

So, this might have an affect on software for a little while, just like every other hardware change has had during the history of computer science.

Improve this answer
2

I think it affects hardware and system designers more than programmers.

From a casual reading of some popular internet articles about memristor, the aspects which might bring about paradigm shift are: (going from the easiest-to-develop to the distant future)

  • Improved capacity and reliability of persistent memory chips
    • Better user-experiences from mobile devices
    • Faster computer startup time, instant sleep-awake
  • Shifts the memory hierarchy balance toward faster memory by bringing high-density cache memory closer to the CPU.
    • Affects CPU design, but doesn't affect the programming model.
    • Doesn't affect software design because history tells us that what used to be accomplishable under 640KB memory now requires several GBs.
  • Ability to combine logic elements to memory elements at the very low level (bits and bytes)
    • Memory-based computing (bit twiddle on a massive scale)
    • Content-addressable memory (i.e. giant hash table)
    • Reconfigurable logic (i.e. FPGA)
    • Improving other VLSI types such as image sensors, etc
  • Ability to design new types of transistors or logic elements based on memristor only
    • This won't happen soon because today's CPU transistors already operate at 10s of picoseconds, and memristor seems to operate at several nanoseconds in laboratory.

Programmers will have less to worry about processing huge volumes of data, and can focus more on the business logic. This bodes well to generalists and not so well to specialists.

Edited: If there is indeed a paradigm shift in the CPU programming model, the Compiler industry as-we-know-it-today will be devastated, paving way for a new industry called Reconfigurable Logic Mapper (mapper for short). (I was wrong when I said there's little effect.) Because of their sacrifice, all other programmers will be able to live their lives as usual, pretending that a Logic Mapper is just the same as a Compiler.

Disclaimer: I am not a scientist and I have zero training in semiconductor fabrication.

Improve this answer
1

I don't think that any hardware changes are going to influence programming paradigms, for the simply reason that programming paradigms have nothing to do with hardware. Programming paradigms are ways to organize our thoughts and ideas.

Changes in hardware can make some paradigms more practical to implement, though. For example, the current mainstream CPUs and mainstream operating systems are extremely hostile to object-orientation. They are also extremely hostile to garbage collection. Compare that to the Azul Vega 3 CPU and system architecture as implemented in the Azul JCA 7300 series, which runs Java at speeds that us Intel users can only dream of.

Improve this answer
1

I think the people saying "none" are pretty much dead-on. Just for example, consider portable devices using things like Windows CE. They use battery-backed RAM instead of memristors (or competitors like FE-RAM), but the basic idea is the same: your primary memory is (effectively) non-volatile. Despite this, nearly all such devices divide the memory into two sections, one used as main memory, and the other for file-system storage.

In theory there's no real need for that. They could, for example, do like MULTICS did, and map it all as virtual memory, with the possibility of giving names to memory regions so you can treat them (somewhat) like files. For that matter, given the address space of a current CPU, you could go even further: you could map the entire Internet as a giant address space, so retrieving a page from site X would be treated as simply paging in some virtual memory.

I can think of at least two reasons that hasn't happened, and shouldn't be expected to happen any time soon either. First, it doesn't fit well with the way most existing software works. You'd have to throw out nearly all existing software (applications and operating systems) and start over from the beginning to really take advantage of this.

Second, it doesn't seem to fit well with the same most people think and work. I could think of all the data on all the servers in the world as "virtual memory" for my computer, but most people don't. From an electrical viewpoint, there's not even all that big of a difference between a SATA connection and (say) an Ethernet connection. While things like storage area networks and iSCSI have helped erode many people's perceptions a little, most people still think of "memory", "files", "local", "remote", etc., as being quite distinct from each other.

These don't remove (or even substantially reduce) the need for things like serialization either. Yes, while I'm working on a file on my machine, it wouldn't have to be serialized -- but the minute I decide to send the file to somebody else on their machine, I need a way to serialize ("marshall", if you prefer) the data so they can use it on their machine. The capability might not be used quite as often, but it would still need to be present.

Likewise, you'd need some way to back up, restore and (by strong preference) version your data. This (again) generally requires some sort of serialization, so I can take a "snapshot" of the data at some point in time and have it coherent so I can use it later. That might not be exactly the same as serialization the way most people think of it right now, but offhand it seems like it would be reasonably similar.

Bottom line: In theory it might be able to change a lot in a hurry, but in fact the net effect is probably to make it easier to (for example) produce portable devices that work almost exactly the way they do now, but get longer battery lives because the RAM will draw power only for reading/writing, not just to maintain its current contents.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.