Live data from Hacker News

A 32nm 1000-Processor Array

vcl.ece.ucdavis.edu

31–40 of 107 posts

Re: A 32nm 1000-Processor Array

#31
It's important for people to know these are eight bit CPU's. Least, that's what every other incarnation has been.

https://en.m.wikipedia.org/wiki/Kilocore

Asking what to do with 1,000 32- or 64-bit cores != 1,000 8-bit cores. Suddenly the value proposition doesnt seem so great. Such designs were used successfully, though, in both neural networks and genetic algorithms. Could probably handle stuff well that normally goes on DSP's.

Re: A 32nm 1000-Processor Array

#32

So how do you program such a beast? What progress is being made on that front? Cache coherency seems really hard to give up on, and even CPU-GPU cache coherency is becoming the expected norm, with even ARM delivering it.

Effectively you have to design for message-passing between microservices as a replacement for function calls. Not only do you have to step back from cache consistency but you have to step back from uniform memory access altogether and head towards a streaming architecture. It's very alien, but that's the only way to really use a system which has such a high ratio of processing power to external memory bandwidth/latency.

Re: A 32nm 1000-Processor Array

#33

So how do you program such a beast? What progress is being made on that front? Cache coherency seems really hard to give up on, and even CPU-GPU cache coherency is becoming the expected norm, with even ARM delivering it.

You program a machine like this much like you work with the unix command line when you string together a series of commands using 'pipes'. Only now the pipes are the comms links between the CPUs and the programs are the pieces of software executing on each of the CPUs, rather than that they all run on the same CPU.

So it's more of a data flow model than a function-call model, and every node will transform its input rather than that it will return results to callers.

This means that not every problem is easily mapped to such an architecture, but when there is a good correspondence between the topology of the network of CPUs and the problem then the throughput can be very good.

After all, there is no bottleneck where all of these have to access a shared resource (RAM) so when it pays off it pays off big.

Re: A 32nm 1000-Processor Array

#34

So how do you program such a beast? What progress is being made on that front? Cache coherency seems really hard to give up on, and even CPU-GPU cache coherency is becoming the expected norm, with even ARM delivering it.

Erlang/Elixir anything running on the BEAM

Re: A 32nm 1000-Processor Array

#35

This reminds me of the Ambric am2045 with 336 cores from 2007. They put 40 of these into an X-Ray machine for a total of 13,000 cores. https://en.wikipedia.org/wiki/Ambric http://www.embeddedinsights.com/epd/Diagrams/nethra-am2045.j...

There's (1) talking about getting ~60 tflops from ~130k compute elements by 3d assembly of 128mb ram . But it requires microfluidics cooling so it would be very expensive.

But in another paper(2), the authors say that offering this chip, even expensively ,could start building the ecosystem and and environment to start a Moore's law like race to solve the heat issue via photonics .

(1)https://www.semanticscholar.org/paper/Fft-on-Xmt-Case-Study-...

(2)http://drum.lib.umd.edu/handle/1903/17153

Re: A 32nm 1000-Processor Array

#36
post #29
post #27

Would a language like Erlang make sense for a machine like this? Run 1000s of communicating processes without any shared data.

I don't think Erlang's VM is that optimized. Currently (as far as I remember) the upper limit is to run 1024 schedulers (threads) but I imagine it certainly wont be 10x more efficient than running 100 schedulers on 100 core machine

Architecturally it's a perfect match for such CPUs. If you listen to Joe talks he was talking about designing for 1000 core cpus more then 10 years ago. It is his stated opinion that Erlang is perfect match for such situations.

Re: A 32nm 1000-Processor Array

#37
post #5

So how do you program such a beast? What progress is being made on that front? Cache coherency seems really hard to give up on, and even CPU-GPU cache coherency is becoming the expected norm, with even ARM delivering it.

It's very hard. In the mid 1980s there was a CPU called a "Transputer" [1] made some of the people who moved to ARM. These CPUs could be connected together in huge networks and directly talk to each other. The network of CPU's could auto-discover its topology, but coding for so many CPU's was difficult. Some specific algorithms scaled well with the number of CPUs, but most did not. [1] https://en.wikipedia.org/wiki/T…

transputers had four links and comms beyond that required routing in s/w. I wrote such a thing for a transputer machine.

Also, the auto-discovery wasn't really auto... That was the boot code probing for CPUs on other ends of links and propagating itself to connected CPUs, building a map of the network in the process (which is kind of cool).

Re: A 32nm 1000-Processor Array

#38
post #18

It is surprising the paper makes no comparisons with GPUs. So I will do it. For starters it looks like they are talking about integer operations (I only skimmed the paper and it mentions an ALU, not an FPU), whereas my GPU numbers below are single precision floating point numbers. So it is apples vs oranges. So, a modern 14-16nm GPU like the Tesla P100 or RX 480 does about 5 to 10 trillion ops/sec at 200-300 W, and a…

Another big difference is that most GPU architectures are multi-lane SIMD (so single instructions acting on multiple data but multiple sets of those) whereas the linked architure is MIMD.

In simpler terms: these processors all execute independent code whereas a GPU tends to have multiple cores but a (sometimes much) smaller number of threads of execution.

Re: A 32nm 1000-Processor Array

#39
post #36
post #29

Earlier quoted context omitted.

I don't think Erlang's VM is that optimized. Currently (as far as I remember) the upper limit is to run 1024 schedulers (threads) but I imagine it certainly wont be 10x more efficient than running 100 schedulers on 100 core machine

Architecturally it's a perfect match for such CPUs. If you listen to Joe talks he was talking about designing for 1000 core cpus more then 10 years ago. It is his stated opinion that Erlang is perfect match for such situations.

Of course it's (much) better than anything else... though my experience is that it's quite hard to scale your application that much... You always need some shared resource and it gets ugly. And I also suspect Erlang has some implementation quirks (for example the algorithm of deciding which scheduler gets which process) that will prevent it from scaling that much. Yeah, I do believe that some day we'll reach such scalability, probably just not today.
Post reply on HN