Re: tlug: Karl-Max has cool dreams [was: dual-pentium processors]

["Manuel M. T. Chakravarty" <chak@example.com>]

Karl-Max Wagner <karlmax@example.com> wrote,

> > There are not many people who can write a program that
> > scales to 64 processors, and if you can, it is an aweful lot
> 
> Depends on the problem. I don't think much in terms of
> scientific (or mathematical) computing. Most run-of-the-mill
> stuff is either heavyload graphics processing (moviemaking, game
> rendering etc. ) or signal processing (digital filtering, sound
> processing etc.). These things are inherently paralell in their
> nature and scale well.

These applications are not really a good argument in favour
of the "common people's parallel computer", I'd say.
Parallel machines are fine for special applica-
tions/environments, but given todays state of the art of
programming those machines, they are absolutely useless for
everyday computing.

> > of work.  And then there are more problems where we don't
> > know any useful parallel algorithm than problems where such
> 
> Right. But they are in the minority.

Sorry, but I'd rather say, there are few problems for which
good parallel algorithms are known.

> > algorithms are know.  Furthermore, there is no compiler
> > taking your sequential program to a parallel program[1].  I
> 
> Obviously. You have to think paralell from the outset.

I agree, but even in the parallel programming community to
many people are still dreaming of the Great Parallelizing
Compiler. 

> > I don't think, there will be ubiquitous parallel computing
> > without a paradigm shift in programming languages.  Please
> 
> Let's say: you need the same paradigm like a hardware
> description language.
> 
> > don't extrapolate from your two- or four-processor
> 
> I don't have any ! I am interested in that more from a DSP point
> of view - and there it's quite commonplace.
> 
> > With 16 it already starts to get nasty and 64 processors are 
> > a nightmare.
> 
> If you insist on converting sequential code into paralell one,
> definitely. If you write code that consists of a lot of more or
> less independent processes, it's not much of a problem - IMHO
> the latter is easier to understand and to conceive of anyway -
> who likes large monolithic programs ?

As I said, I completely agree.  Unfortunately, there is no
`good' programming language that properly supports such a
view yet.  (I don't say that there are no promising
approaches, but all of these are at best research
prototypes.) 

> Again: if you come from a hardware and logic design background,
> like things like FPGA's than you are in a good position for
> paralell programming. If your background is writing sequential
> code ONLY, it's a nightmare.
> 
> Actually, I did lots of stuff in the past using "TTL-graves" -
> typical old style logic design which is inherently paralell.
> When I started using micros, I kinda hated the sequential
> thinking required there - I had to sequentialize problems that
> were inherently paralell. This is why I like things like
> multitasking, paralell processing etc.: this way I can go back
> to the design methology used in hardware design. It's a dream
> come true !
> 
> To put it in a nutshell: With paralell computing you gotta think
> paralell. Kiss your old sequential habits goodbye !

Unfortunately, software parallelism is far more complex than 
hardware parallelism (the latter is bounded and in some
sense you can exploit all logical parallelism with only
moderate interaction of resources), but in principle I
agree.

Manuel
--------------------------------------------------------------
Next Nomikai: 18 September, 19:30 Tengu TokyoEkiMae 03-3275-3691
Next Meeting: 10 October, Tokyo Station Yaesu central gate 12:30
--------------------------------------------------------------
Sponsor: PHT, makers of TurboLinux http://www.pht.co.jp