Memristors Part 2: Software
Memristors Part 2: Software
In this post, we'll talk about the impact these components will have on the architecture of the next generation of computers and, more importantly, what impact this new architecture will have on the kinds of programs we can create.
Join the DZone community and get the full member experience.Join For Free
Container Monitoring and Management eBook: Read about the new realities of containerization.
In part 1, we talked about what a memristor is and its basic operating principles. In part two, we'll talk about what impact these components will have on the architecture of the next generation of computers and, more importantly, what impact this new architecture will have on the kinds of programs we can create.
History has proven that as soon as memory becomes less expensive, we add more of it (save $). Also, when it becomes more compact we add more of it (more fits in the old box, so why not?). And, when it uses less power we add more of it (keep the same power supply/battery). Finally, if it generates less waste heat we add more of it (we've already designed the cooling system, so why not?). So, it seems clear that in the near future computer memory arrays will become huge (if not titanic).
But, it is not the absolute size of the available data store that makes this important. It is the nature of this huge data store that will change the paradigm.
Today we have huge server arrays that solve certain kinds of problems with truly huge data sets. These server arrays are a collection of independent computers connected through a network and working in tandem on small parts of a bigger problem. The very nature of these between task communications determines the kinds of problems we can solve with these arrays. These systems work best on problems that deal with "local" data environments (e.g. a weather simulation where all of the individual data cell models are adjacent). If you have written programs for GPGPU (e.g. Nvidia) then you are already sensitive to the issue of data locality. Data is accessible in the processor registers (very fast), in the process thread (fast), in the threat grid (slower), in the Warps of those grids (slower yet), in the global GPGPU memory pool, in the CPU memory pool, and the virtualized disk data store (at this point the latency can be 1 million times longer). And, for really large data sets, it spans many disk data stores shared over networks.
One of the more common approaches to programming these large server arrays is to take a MapReduce approach (e.g. Hadoop). If you're not familiar with the methodology you can think of it as the sophisticated and generalized version of merge/sort. If the task at hand is amenable to this divide-process-recombine scheme, then this approach will reduce the latency of the overall task. The result comes sooner because more processors are working on it, but the actual amount of computation is larger (and if you're not careful, very much larger) because of all of the dividing, data packing, transmitting, receiving, data unpacking, computing, result packing transmitting, receiving, result unpacking, recombination at each point in the hierarchical decomposition of the data set.
This approach of breaking the problem down until the pieces are small enough for one processor and its associated memory to work on is a tool and it works well on a certain class of problems. For fun, we might call this tool a "hammer". If we have to nail down an answer to a problem with this class we have the right tool. But, what if we need a "wrench"?
There are other classes of problems that require randomly checking data across the entire data set and computing precursors to use with other widely scattered data:
Simulating the motion of all the stars in the galaxy (called a Generalized N-body problem) requires access to the entire data set.
Most optimization problems require the entire data set.
The mathematical integration used in methods like Bayesian inference require wide-ranging data access.
These and other problems would be solved better with a "wrench".
Because of all of the features of memristors I mentioned above, it won't be long before we have a system memory for a single computer that offers a flatly addressable petabyte data store with nano second response. Think of all the new problems we can attack. And think of all the new, and yet unknown, applications we could make with this technology. Another advantage is that the high data density, low power requirements, inherent reliability (no moving parts) will obsolete mechanical disk drives. A 1 petabyte "memristor disk" would be smaller, lighter, faster than its mechanical counterpart and would use less power, make no noise, generate no vibrations, and not be susceptible to head crashes. In fact, it wouldn't really be a disk at all, it would just plug into the address space of the computer. Wouldn't that be nice?
Memristors solve a lot of problems! I think we'll see them in products on the market in a year or two at the most. So, start thinking about those titanic, nonlocal data algorithms you've always wanted to play with.
Opinions expressed by DZone contributors are their own.