Multi-core CPUs
Jason Johnson
jason.johnson.081 at gmail.com
Fri Oct 26 04:57:53 UTC 2007
Interesting. I really think that to make real progress in
parallelization we will have to walk away from the Intel model of
shared memory stacked on 3 levels of cache, snoopy busses to propagate
writes and so on. Of course they will force that model to scale to a
point, but it can't go on forever and there just has to be a simpler
way.
On 10/26/07, Marcel Weiher <marcel.weiher at gmail.com> wrote:
>
> On Oct 25, 2007, at 12:28 PM, Peter William Lount wrote:
>
> > The Tile-64 processor is expected to grow to about 4096 processors
> > by pushing the limits of technology beyond what they are today. To
> > reach the levels you are talking about for a current Smalltalk image
> > with millions of objects each having their own thread (or process)
> > isn't going to happen anytime soon.
> >
> > I work with real hardware.
>
>
> A couple of numbers:
>
> - Montecito, the new dual-core Itanic has 1.72 billion transistors.
> - The ARM6 macrocell has around 35000 transistors
> - divide the two, and you will find that you could get more ARM6 cores
> for the Montecito transistor budget than the ARM6 has transistors
>
> So we can have a 35K object system with every processor having its own
> CPU core and all message-passing being asynchronous. This is likely
> to be highly inefficient, with most of the CPUs waiting/idle most of
> the time, say 99%. With 1% efficiency, and say, a 200MHz clock, the
> effective throughput would still be 200M * 35000 / 100 = 70 billion
> instructions per second. That's a lot of instructions. And wait what
> happens if we have some really parallel algorithm that cranks
> efficiency up to 10%!
>
> I am not saying any of these numbers are valid or that this is a
> realistic system, but I do find the numbers of that little thought
> experiment...interesting. And of coures, while Moore's law appears to
> have stoppe for cycle times, it does seem to still be going for
> transistors per chip.
>
> Marcel
>
>
>
>
More information about the Squeak-dev
mailing list
|