Tuesday, September 26, 2006

80 cores, but what can we do with it?

Slashdot's been talking about multi-core again. Someone brought up FPGA in there too which is always nice. A lot of people wonder what OS support and software support for multi-core will look like. I wonder this regularly, and I think the answer is that we should start to treat multi-core processors not too differently from FPGAs.

I think in terms of amortized efficiency benefits, it is likely that the true benefits of multi-core will be "assembly-line" throughput benefits. It is OK to have a very long pipeline spanning 80 processing kernels if such a methodology substantially increases system throughput even at a cost to single request delay. Even many realtime systems will benefit despite these throughput / delay tradeoffs.

Working away on mapping graphs to a lattice....

1 comment:

Rupert said...


Nice blogs.

To declare an interest, I work for picochip (www.picochip.com)

We are one of the (many!) multicore players. I'd like to say we are different, because :
a) we actually have had real product for some time (5 years!) now
b) It works and we have real customers using it for real systems (Intel is a customer, Sprint's WiMAX network relies on it, etc)

But we agree: I actually describe our architecture as "an FPGA you program in C" !

Basic building block is a processor, not a LUT, but the logic of "set things up at design time, then just execute" is the same, as -of course- is the logic of "spread tasks in space across the array, not sliced in time with RTOS"

Indeed, IMEC actually copyrighted the term "FPPA - Field Programmable Processor Array"...