Re: 1teraflops cell processor possible?

"Glew News SBC" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
snip
>
> Anyway, first let me suggest, just because I like being the devil's
> advocate, that it *is* lack of processing power that is holding us
> back in the area of parallel computation.  Specifically, the
processing
> power needed to analyze, on the fly and dynamically, non-parallel
> user programs, and run them in the most parallel manner possible.
>
> I'm deadly serious about this; but now let me talk about explicit
parallel
> software.
>
> Jack Dennis (one of the fathers of dataflow) gave a workshop talk
> at PACT in Paris circa 1997 where he said that the problem with
> explicit parallel programming was that it exposes global resource
> management issues to the programmer of LIBRARY modules.
> I.e. it violates modularity.
>
> E.g. you are on a 32 processor system.  Your application won't
> run well if it is parallelized to use more than 32 threads.
> Say you have 4 threads to start with.  Each calls a library routine...
> but this library routine is easy to parallelize.  If each of the
instances
> of the library routine on each thread invokes 7 more threads,
> giving a total of 32 threads, great; but if each invokes 16 threads,
> giving a total of 64 threads on a 32 processor system, you lose.
>
> I think Dennis is 100% correct.  Ease of software development
> nearly always wins out over performance.   Parallel systems need
> to support software modularity.
>
> There have been vague attempts to do this by making global
> resource management information available to the library module
> - how many threads should I fork?  But I think the right way to
> do this, the only way that stands a chance long term, is to virtualize
> the parallelism - to create virtual threads that can be created and
> destroyed cheaply and at will, which do not thrash each other
> when run on a system with fewer physical CPUs.
>
> Some threading software systems do this - create "task descriptors"
> that are multiplexed onto the actual CPUs. Make the task descriptors
> lighter even than a pthread like user level thread.
>
> I think that there may be a role for hardware to play here.

Some great minds in POK :-) are way ahead of you (maybe) with the LPAR
on zSeries.  At least if I understand correctly, one can have thousands
of "virtual machines" or Logical Partitions  on a processor with many
fewer physical processors.

I don't know how dynamic this is or the overhead.

del
>