Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's likely that computing with random pulses would increase power. That's because the vast majority of power in processors today is spent transferring information, not computing arithmetic operations. The actual arithmetic operations are very cheap energy-wise compared to the cost of reading and writing data from memory, as well as sending it around the chip.

The cost of moving data is proportional to the number of toggles you have to push through the wire. And with this representation, the number of toggles is immense. Bill Dally noted at SysML the other week that this kind of data format is almost the worst possible number format you could construct, if you care about power, because on average there must be lots of toggles.

It's too bad the article doesn't include any comparisons to see why the authors believe this is a good idea. The neuromorphic story is getting a little threadbare at this point, without data to back it up.



A few points: data movement is expensive, but the reasons are not so simple:

1) x68s RAM needs to move huge amounts of data cheaply and extremely reliability. This requires a lot of power to fight noise. Once you're allowed to have a few bit flips, the bus voltages can be made much power directly lowering losses.

2) A significant portion of the large energy costs is actually in computing associated with memory movement! (according to Sohmers from REX Computing, about 40%). Encoding, queuing on processor, Decoding, fetching, queuing on the memory controller, and caching again on the CPU takes a lot of logic.

I think it's quite possible this approach is superior for low precision floating point applications that currently use CPUs/GPUs. Note this allows lowering voltages for the whole system, including interfaces and memory.

Also, data movement doesn't dominate the energy cost of all applications; there are plenty of operations still compute-bound (e.g. some evolutionary methods), it's just that the applications more in vogue are like that. There are plenty of applications that are currently done in DSPs and ASICs because of heavy computational costs (error correction decoding as mentioned in the article) that might benefit from this.

---

As far as I know, it is still an open question whether it is possible to generalize this approach for data-efficiency. I have a few ideas I've been playing around with but none that seem to work yet.


I don't see where the authors are advocating that stochastic computers would wholesale replace general purpose digital computers. It looks more like they've found specific cases where stochastic computing could be a big benefit and are doing basic research on development techniques and other possible applications.


> That's because the vast majority of power in processors today is spent transferring information, not computing arithmetic operations.

As an aside: I found this aspect (and the amount of dark silicon in modern CPUs) very interesting when watching Simon Knowles talk on their graph core design. They try to reduce this cost, maximise compute and minimise dark silicon by using a far more localised memory architecture (granted what they are doing is naturally more parallel than a CPU though).

I think you are correct when thinking about dropping this into a normal CPU design as a bolt on discrete block of logic... but perhaps it's better used as a hardware building block for specialised processing. i.e rather than exposing it as an actual instruction on its own, use it as the building block of an algorithm implemented in hardware that requires really fast arithmetic but does not need to be perfectly deterministic (with no back and forth to registers until the end result) keep in mind it truly can be fast inside a single clock because fixed length streams (i.e words) can be processed in parallel.

I guess in short i'm saying: avoid the serialisation process until necessary, chain the probabilistic arithmetic until done _then_ do the expensive de-serialisation. My intuition tells me it would have value then, but I don't know.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: