Re: question - automatic parallelization

In article <48smcu$q7j@elektron.et.tudelft.nl>,
Jeroen Hordijk <jeroen@leonardo.et.tudelft.nl> wrote:
>
>I'm a PhD student and going to research automatic exploitation of
>functional parallelism (task parallelism). I'm trying to find
>papers/books about this research interest. I'm especially interested
>in automatic restructure sequential C programs for execution on parallel
>architectures (starting with shared memory multiprocessors, maybe
>distibuted memory processors later).
>
>Is it true that most researchers in parallel computing, consider
>automatic exploitation of parallelism from sequential programs, like
>C, too complicated ?


Roughly, yes. There are four points to consider:


        1) C is one of the most disgusting languages ever invented, and is
much harder to optimise or parallelise than Fortran (which is itself
pretty unclean). This is why you can usually get better performance
on 'supercomputers' and modern RISC systems using Fortran than using
C. So, don't start with C!


        2) The 'functional means parallisable' camp have been laughed out
of court. Programming in a functional style (i.e. no gratuitous
side-effects) is well worth-while, and using a 'functional' language
has some advantages. But it generally gives mediocre automatic
parallisation (e.g. factors of under 8).


        3) There has been a lot of progress in the automatic parallisation
of vectorisable code (usually in Fortran), especially for standard
matrix operations on very large vectors. This is very active area at
present, both in academia and in the supercomputing industry.


        4) But the basic fact remains that most sequential programs cannot
be vectorised or parallelised as they stand. Some of them need only
cleaning up (i.e. rewriting in a better, more 'functional' style), but
others need more extensive changes, and some need algorithmic changes.




The consequence of the above points means that most parallelisation is
semi-automatic - i.e. the programmer needs to clean up his code and
provide hints to the compiler, which will then do the tedious work of
actually reorganising the code. This is a good engineering
compromise, but lacks theoretical elegance :-)




Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nmm1@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
--

Return to the comp.compilers page.
Search the comp.compilers archives again.