Hacker News Reader

Comment by listic | Hacker News Reader

I wonder if this could fly.

Because the other approach very-many-cores processor design that I know of, was by Intellasys (http://www.intellasys.net/), the latest company of Forth's inventor Chuck Moore. And it seemed to have gone nowhere: http://www.colorforth.com/S40.htm

The problem with this design, as I could see it, is that tiny cores can be too small to do anything practically useful on their own; inter-processor communication and I/O eats cycles. In Intellasys' case I guess the problems were multiplied by the fact that it would be harder to get traction for the chip was designed to be programmed in Forth , and Chuck Moore would settle for nothing less.

Maybe University of California will have better chance of success, i.e. if it has more runway to tweak their design.

Does anyone know of other very-many-cores processor chips?

View on HN

Rigel (https://rigel.crhc.illinois.edu/) is one such project, though the silicon implementation is decidedly less far-along than AsAp. The goal there is 1024+ cores in 45nm. The targeted applications are more like "things that are massively parallel but don't run well on GPUs" than "DSP kernels that decompose into pipelines", but they are both accelerators nonetheless. A more detailed paper on the architecture itself can be found here: https://netfiles.uiuc.edu/jkelm2/www/papers/kelm-isca2009.pd... .

Full Disclosure: I am affiliated with this project. However, I am making no claims about the relative merits of AsAp and Rigel, just pointing out another manycore research project.

Also, you may be interested in commercial chips from Cavium (http://www.cavium.com/OCTEON_MIPS64.html) and Azul Systems (http://www.azulsystems.com/products/compute_appliance.htm). Of course, modern GPUs and Intel's forthcoming Larrabee are manycore chips as well, though GPUs have some restrictions and special-purpose hardware that makes them slightly less general than others.

Not as helpful as I'd want, but yeah, I recall one that was getting some traction as a signals-processing aide for tasks like, eg, radar or video analysis and possibly DPI.

Totally blanking on the name, it had a pretty similar kit: it seemed like you wrote the raw code in C or a C-like lang, then there was some software assist for laying out dataflow between cores.

Edit: I was thinking of Tilera.

IIRC the seaforth chips were designed to have blocking reactive IO at ports on each processor, so there was no need to waste cycles waiting on IO or explicitly driving peripherals, you just coded as if the stream was continuous.

Yes, you're right. In Seaforth's case inter-processor communication and I/O shouldn't eat cycles on its own.

I wish we could use some of this technology.

Reply on news.ycombinator.com