From: Eugene Miya on
In article <efep6h$vbl$1(a)agate.berkeley.edu>,
Jon Forrest <forrest(a)ce.berkeley.edu> wrote:
>quad-core
>80-core
....
>Where do you think the point of diminishing returns might be?

Ask Dave Patterson on the 5th floor of Soda about PIMs.

--
From: Nick Maclaren on

In article <e46tu3-k1e.ln1(a)osl016lin.hda.hydro.com>,
Terje Mathisen <terje.mathisen(a)hda.hydro.com> writes:
|> Joe Seigh wrote:
|> >
|> > For one thing, the operating system would change. Interrupt
|> > handlers for asynchronous interrupts would go away. You'd have
|> > dedicated, possibly special purpose, processors to handle devices.
|> > They're already talking about this with "coprocessors".
|>
|> You still need some what to handle async inter-core communication! I.e.
|> I believe that you really don't have any choice here, except to make
|> most of your cores interruptible.

Nope. I posted a design that did away with that, at the hardware level,
and there have been lots of systems that proved you could do without
them at the software level. You wouldn't start from existing software
designs and interfaces, of course :-)


Regards,
Nick Maclaren.
From: Nick Maclaren on

In article <451bf0c3$1(a)darkstar>, eugene(a)cse.ucsc.edu (Eugene Miya) writes:
|> In article <efep6h$vbl$1(a)agate.berkeley.edu>,
|> Jon Forrest <forrest(a)ce.berkeley.edu> wrote:
|> >quad-core
|> >80-core
|> ...
|> >Where do you think the point of diminishing returns might be?
|>
|> Ask Dave Patterson on the 5th floor of Soda about PIMs.

When are we going to see them, then?

Seriously, they have been talked about as imminent for 20 years, so
either there is a major problem or the IT industry is suffering a
collective failure of nerve. Or both.


Regards,
Nick Maclaren.
From: Joe Seigh on
Terje Mathisen wrote:
> Joe Seigh wrote:
>> Rethinking this, the question should be what would you do
>> with an unlimited number of processors?
>>
>> For one thing, the operating system would change. Interrupt
>> handlers for asynchronous interrupts would go away. You'd have
>> dedicated, possibly special purpose, processors to handle devices.
>> They're already talking about this with "coprocessors".
>
>
> You still need some what to handle async inter-core communication! I.e.
> I believe that you really don't have any choice here, except to make
> most of your cores interruptible.

Async presumes processors are a scarce commodity and you want to have it
do other work while it's waiting for something to be done. That goes
away if you have unlimited numbers of processors.

>
>> The scheduler would go away. No need for it when every thread has
>> it's own dedicated hardware thread. This would affect realtime
>> programming. No need to play games with thread priorities and
>> any of the timeouts that could be caused by not being scheduled
>> quickly enough, i.e. no dispatch latency.
>
>
> I believe you'd still need it, but not for anything that's timecritical.
> I.e. after sufficient time with tens of cores/hundreds of threads
> available, programming patterns to use/abuse them all will turn up, and
> you'll run out of resources anyway. :-(
> \

The OP posed the question of whether you can have too many cores. You're
saying there will never be enough? :)

--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.
From: Nick Maclaren on

In article <srKdnUtcqoTDaIbYnZ2dnUVZ_rCdnZ2d(a)comcast.com>,
Joe Seigh <jseigh_01(a)xemaps.com> writes:
|> Terje Mathisen wrote:
|> >
|> > You still need some what to handle async inter-core communication! I.e.
|> > I believe that you really don't have any choice here, except to make
|> > most of your cores interruptible.
|>
|> Async presumes processors are a scarce commodity and you want to have it
|> do other work while it's waiting for something to be done. That goes
|> away if you have unlimited numbers of processors.

Not really. Let's assume that you do have such an infinite number of
threads, and thread A wants to prod thread B at a time it is doing something
else. That can't be done without some form of asynchronicity.

As you may remember, my design used FIFOs for inter-thread communication.
That avoids the problem of interrupts, but is no less asynchronous.

TANSTAAFL.


Regards,
Nick Maclaren.