Re: Parallelizing (WAS: Death by pointers.)

blume@zayin.cs.princeton.edu (Matthias Blume)
Mon, 23 Oct 1995 12:42:16 GMT

          From comp.compilers

Related articles
[3 earlier articles]
Re: Parallelizing (WAS: Death by pointers.) preston@tera.com (1995-09-29)
Re: Parallelizing (WAS: Death by pointers.) creedy@mitre.org (1995-10-02)
Re: Parallelizing (WAS: Death by pointers.) stefan.monnier@epfl.ch (Stefan Monnier) (1995-10-03)
Re: Re: Parallelizing (WAS: Death by pointers.) chase@centerline.com (1995-10-04)
Re: Parallelizing (WAS: Death by pointers.) imp@village.org (Warner Losh) (1995-10-11)
Re: Parallelizing (WAS: Death by pointers.) Martin.Jourdan@inria.fr (1995-10-18)
Re: Parallelizing (WAS: Death by pointers.) blume@zayin.cs.princeton.edu (1995-10-23)
Re: Parallelizing (WAS: Death by pointers.) wclodius@lanl.gov (1995-10-28)
Re: Parallelizing (WAS: Death by pointers.) cliffc@ami.sps.mot.com (1995-11-03)
Re: Parallelizing (WAS: Death by pointers.) chase@centerline.com (1995-11-06)
Re: Parallelizing (WAS: Death by pointers.) chase@centerline.com (1995-11-06)
Re: Parallelizing (WAS: Death by pointers.) hbaker@netcom.com (1995-11-10)
Re: Parallelizing (WAS: Death by pointers.) dave@occl-cam.demon.co.uk (Dave Lloyd) (1995-11-13)
[4 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: blume@zayin.cs.princeton.edu (Matthias Blume)
Keywords: parallel, optimize
Organization: Princeton University
References: 95-09-030 95-10-054 95-10-092
Date: Mon, 23 Oct 1995 12:42:16 GMT

> Martin.Jourdan@inria.fr (Martin Jourdan) writes:


      A side benefit is that the C code produced by such compilers is generally
      free from hard-to-analyze features (e.g. aliases) that hinders low-level
      optimizations,


I wouldn't call this a benefit -- rather the opposite. It is true that
C code generated from high-level programs doesn't have some undesirable
properties, but the C compiler doesn't know that. Only expensive analysis,
which often is too pessimistic and conservative to even discover the truth
(because it also has to deal with `real' C programs), prevents many useful
optimizations from taking place.


      so that, altogether, the executable you obtain from a
      Scheme or ML source is quite competitive with the one you get from
      hand-written C code (and of course much easier to write).


What is `quite competetive'? Only twice as slow? Five times? Ten times?


--
-Matthias
--


Post a followup to this message

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