Hacker News Reader

Comment by paulbaumgart | Hacker News Reader

With memristors you can decide if you want some block to be memory, a switching network, or logic. Williams claims that dynamically changing memristors between memory and logic operations constitutes a new computing paradigm enabling calculations to be performed in the same chips where data is stored, rather than in a specialized central processing unit. Quite a different picture than the Tower of Babel memory hierarchy that exists today.

That part is mind-blowing.

And I'm wondering, if this all works out, will the whole multi-core thing and all the trouble that comes with it (from a software standpoint) be pushed back for another decade?

And what implications would that have for programming languages? Seems like it would mean JavaScript wouldn't be so much worse than Erlang after all (cf. http://news.ycombinator.com/item?id=1304599 ).

(Yeah, I know, it's a little bit of a stretch.)

View on HN

Actually, it's the other way around; it sounds like they are talking about having lots of processors literally physically spread amongst the data. That's sort of more Erlang-y, although it isn't actually Erlang-y either. Erlang pretty deeply assumes homogeneity of the computational units it is accessing. (It does allow you to start a process on a given node, and that's a start, but the VM's strategies for memory management and copying on a given node would have to change quite substantially to cope better. Or map one node to each processor-in-the-memory in which case I'd expect too much copying between nodes to occur without a lot of care taken by the programmer, sort of fighting the language the whole time. Erlang lets you control where processes run, but not directly control where data lives beyond that.) Basically this future seems to be NUMA writ large, and while an "Erlang-inspired" language may be the way forward, Erlang itself would not make this transition without substantial changes. (Might be feasible, though.)

But Javascript as it stands today is even worse off, as are most languages. We don't really have much that could cope with this right now in a clean way. (Anyone know a language that really handles NUMA well? And I do mean a language, not a library for C or something. Something slick, not something that merely "permits" working with it.)

I agree that there's no technical reason for artificially limiting yourself to a single (but really fast) "computational unit".

But I wonder whether it will be worth the trouble (at least to the majority) if you can basically get away with only worrying about one processor, and that one processor is no longer limited in its clock rate by the current leaking, massively heat dissipating MOSFETs we have today.

Connection machine lisp.

http://scholar.google.com/scholar?cluster=140343302019350181...

Anyone know a language that really handles NUMA well?

Depending on what you mean by well, any language that offers fork() as a primitive does work. The trick is that this allows you to create 2 copies of a process that share little enough that a scheduler can safely move them from one machine to another. By contrast with threading you have the problem that the scheduler cannot know when it is safe to schedule two threads on distant CPUs.

Of course this only lets you scale embarrassingly parallel problems.

For another approach that could be made to work reasonably well, try Go. Its central idea is that you pass messages to the processing job, and not vice versa. Figuring out how to schedule threads is a complex task, but run-time scheduling heuristics should do a reasonable job of that for most problems. (Writing algorithms that reliably avoid having bottlenecks will be an interesting challenge.)

And a third approach to watch is Parallel Haskell. Because of the guarantees it offers, the opportunities to rewrite the program at run-time based on what is appropriate are extremely interesting.

It's even more different than that.

It's a collection of nodes, any of which can be either CPU transistors, bitkeepers, or both, at any given time - and change with the problem space.

While we may be able to target it with Erlang or JavaScript or whathaveyou eventually, it's going to need a completely different kind of instruction set than what any CPU currently has.

That part is mind-blowing.

It sounds like version 0.1 of computronium.

It's exciting, for sure. Although, I do have to remain skeptical that it will happen as soon as the author hopes. These sorts of changes require so many companies, organizations, and people to change their tools across the entire spectrum of computing..low level hardware, compilers, and possibly programming languages. Then there will be tools to cross-compile existing software onto these new architectures, and those tools will undoubtedly have a host of bugs of their own.

Nevertheless, if and when this happens, it's going to be FUCKING AWESOME.

Too bad it can't happen how revolutionary technology used to be started: in a garage. Leaving corporations at this goal with only a quarterly focus will not heed well for the this task.

I've just created a google group to discuss implementing this and other game changing techs. Because if you are going to start from scratch with computers again, you want to correct the some other problems we have with current systems (e.g. security architectures)

http://groups.google.co.uk/group/fca-t

Spread the word (I was kinda waiting until I had some more content before I publicised, but this seemed like a good opportunity).

  And what implications would that have for programming languages?

Probably not that many, as programming languages abstract data manipulation and this new technology only requires/allows different ways to implement data representation and manipulation.

Now these differences in representation and manipulation are large, as you don't need to 'get' and 'store' data from the memory to the CPU anymore, as the memory is the CPU. Calculations could basically be implemented as moving data from one part of the memory to another.

so, like an FPGA?

I think more like what FPGAs could have been. FPGAs today are generally used as a cheap way to implement an application-specific circuit. Once they are programmed, they stay in a fixed configuration. It is theoretically possible for the configuration to change on the fly, but it is almost never done.

Memristors would implement physically what FPGAs could technically emulate using transistors. With this come the benefits of lower power consumption and the ability to keep state when powered down (which FPGAs can't do).

I think cellular automata like the Game of Life are a better mental model for memristor circuits (but I am probably hugely wrong here).

Glad to see i'm not the only one thinking about FPGAs, the thing that i like the most is that this will likely provide an easy way to load a circuit/cpu schematic on a bare memristors based component. If the computing paradigm don't change completely in the meanwhile (unlikely), being able to load/clone dynamically some x86 cores, gpu-like cores, etc... directly from a schematic description and use them (old-style system emulation) is in my opinion quite cool.

Reply on news.ycombinator.com