Related articles |
---|
Re: Optimizing Across && And || leichter@zodiac.rutgers.edu (1995-03-07) |
Best, Simple versus Best preston@tera.com (1995-03-14) |
Best, Simple versus Best preston@tera.com (1995-03-14) |
Re: Best, Simple versus Best schrod@iti.informatik.th-darmstadt.de (1995-03-15) |
Best, Simple versus Best Jon.Bertoni@Eng.Sun.COM (1995-03-15) |
Re: Best, Simple versus Best hbaker@netcom.com (1995-03-16) |
Re: Best, Simple versus Best oz@nexus.yorku.ca (1995-03-16) |
Re: Best, Simple versus Best sdm7g@elvis.med.virginia.edu (Steven D. Majewski) (1995-03-20) |
Re: Best, Simple versus Best leichter@zodiac.rutgers.edu (1995-03-21) |
Re: Best, Simple versus Best csabhv@upe.ac.za (Prof Herman Venter) (1995-03-30) |
Best, Simple versus Best preston@tera.com (1995-03-30) |
[2 later articles] |
Newsgroups: | comp.compilers |
From: | Jon.Bertoni@Eng.Sun.COM (Jon Bertoni) |
Keywords: | optimize, design |
Organization: | Compilers Central |
References: | 95-03-050 95-03-081 |
Date: | Wed, 15 Mar 1995 19:22:28 GMT |
Re Mike Powell's Modula2 compiler:
>I never used Powell's compiler; it was dead by the time I started grad
>school. However, I know people who did use it. They described it as
>"a pig" -- used too much memory and too many cycles for "real" code (I
>user horror quotes since these were all academic users). They had to
>employ a "coke-can semaphore" to ensure that only 1 person was
>compiling at a time (i.e., you don't compile unless you've got _the_
>coke can in your possesion).
I have used this compiler fairly extensively. It probably was indeed dead
fairly quickly, although I personally believe that's because Modula-2
died. I would not describe it as a "pig". It probably did use more
memory than was good for most academic users at that time, but, as I
recall, it was targeted for a newer generation of machine with more
memory. Remember, the workstation for which it was initially designed had
a standard configuration of 64 mb or so. I think I remember the compiler
running perfectly well in 32mb, and probably would do well with less.
It's been a long time now. The memory issue was never important enough
for me to bother to test.
As far as cycles, it certainly was targeted for a single-user machine.
The C compiler I use every day doesn't exactly seem lightweight in these
respects. Are you stating that a "modern" compiler would be strikingly
better? My experience says otherwise. I include the SunPro, DEC Alpha,
DEC MIPS, and IBM RS/6000 compilers in the list of compilers I have used.
>Why? Simple algorithms (especially "simple to understand and
>implement" algorithms aren't always asymptotically efficient).
>You have to work hard if you want to find efficient and effective
>approaches to hard problems.
I'm not sure what you mean here. Powell's compiler generated good code
for me, and did it in what I thought was good time. What more could I
want from the code improvement phase?
>Of course, many optimizing compilers are big and slow, and many are
>ineffective. Bummer. But most people working on optimization are
>working to improve the state of the art, not hold it in the '70s.
I think that Powell's compiler was mostly a research vehicle, so please
don't quote me as saying it was ready for the general user public. On the
other hand, the failings that it had weren't in compile time, compile
space, or object code performance, as far as my opinion goes, not for its
intended target, anyway.
No doubt some of its strategies could be updated, but "best simple" still
sounds interesting to me.
Jon Bertoni
bertoni@eng.sun.com
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.