Jomo Fisher -- Sharp Things

I like very much the 1 good core and lots of little ones concept. I don't get why it would be a TCP/IP stack to communicate between the processors though...

I think you missed the point.

Currently my computer has 48 processes running. If I had one CPU per process, then each application could run at full speed instead of constantly fighting for the same CPU.

I would get this gain without any change what so ever to my existing applications.

Sounds similar to the Cell CPU.

And no, the TILE64 is not similar to what you are talking about. It has 64 identical processors which have reconfigurable interconnects.

If you read a bit about TILE64, you would find that you can compile C code to it. So any .NET implementation written in C would work.

A slightly different way to put your proposition (I don't buy Desktop SMP is dead) is that you'd rather have say 1 Wintel compatible fast as possible cpu + 32 simpleton massively parallel cpus than 8 identical Wintel cpus.

I pull the 1+32 vs 8 out of thin air, but there is some tradeoff that would give you more simple cpus.

The problem with this approach is finding a killer app for the simpleton cpus and creating all the dev tools to go with it since it is an incompatible architecture.  There is also the question of whether so many more cpus makes the problem of accessing memory over the system bus so much worse that you still lose versus fewer more powerful cpus.

I tend to think the world will have enough trouble making massively parallel software if most of the cpus are the same.  However, I can easily envision special purpose apps. For example, imaging pairing the latest graphics GPU (basically a microprocessor) with a 64 cpu Tile 64 on the same board with very high speed memory and dedicated software to do graphics (pretty well understood parallel software) at unheard  of speeds?  If it worked, by the next year they'd have a 1+64 all on one chip equivalent and you could buy one at the store for $69.95.

Cheers!

BW

PS  Can't we put to rest once and for all that even if windows is running 64 threads it can't keep 64 cores busy?  Take a look at the column that shows cpu utilization.  Nearly all of those threads are asleep, using 0 cpu, waiting for something to happen.  Windows will do well just to keep 4 cores busy under the worst cases on a desktop.

Bob and Jomo,

Asymmetric multiprocessing (aSMP) is, imho, a big part of why title porting to the PS3 (which uses the Cell - 1 main CPU, 7-8 special purpose processors) hasn't happened as quickly as hoped.  

Major Nelson has a 4 part series article about why aSMP isn't appropriate for games but the analysis might apply equally well to application software.  The bulk of the time of the CPU is spent doing operations (fetch, load, store) that don't benefit from the specialized processors.  Put another way, most programs don't spend enough time doing things that specialized processors do well to justify the tradeoff (speed vs flexibility).

This is why software engineers write software, and electronics engineers make hardware.  I feel like my eyes have been assaulted :P!

I see where your coming from, but the fact of the matter is that the bottleneck in most systems is the caching and memory access, not the core number, or speed of the cores.  This is why the current quad core is actually 2 dual cores back to back, as the 4 cores / 1 cache system is extremely hard to get right.

Secondly, you would never, ever implement communications across the CPU's through TCP/IP.  You would use a multi access register or dedicated on chip bus to communicate, as TCP/IP would be too expensive in both silicon and time taken.

That said, the idea of several less powerful cores to do work with is very cool.  For instance the .net threadpool could be implemented at hardware level, so that when a thread is taken from the pool, it's literally runing on a core (or timeslice on a core).

I would like to see a core that could run x86 instructions, with an instruction decoder that had a second microcoded instruction set for performing IL instructions and thus removing JIT overhead.  

I realise that you can't do everything through microcode (ie precalculated addresses for jumps etc), but any reduction to JIT time would give significant decreases to startup time.  Also the underlying calls could be implemented more effectively on a non x86 core optomised for .Net style instructions.

Food for thought.