4 ms·

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/ http://ww

by listic 18y ago

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/ 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 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?

frig 18y ago
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.
JulianMorrison 18y ago
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.
- listic 18y ago
  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.
sparky 18y ago
Rigel (https://rigel.crhc.illinois.edu/ 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.pdf 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 http://www.cavium.com/OCTEON_MIPS64.html) and Azul Systems (http://www.azulsystems.com/products/compute_appliance.htm 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.

by listic 18y ago

frig 18y ago

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.

JulianMorrison 18y ago

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.

listic 18y ago
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.

sparky 18y ago

Rigel (https://rigel.crhc.illinois.edu/ 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.pdf 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 http://www.cavium.com/OCTEON_MIPS64.html) and Azul Systems (http://www.azulsystems.com/products/compute_appliance.htm 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.