Related articles |
---|
[2 earlier articles] |
Re: PL/I nostalgia robin51@dodo.com.au (robin) (2012-04-25) |
Re: PL/I nostalgia gah@ugcs.caltech.edu (glen herrmannsfeldt) (2012-04-24) |
Re: PL/I nostalgia robin51@dodo.com.au (robin) (2012-04-28) |
Re: PL/I nostalgia gah@ugcs.caltech.edu (glen herrmannsfeldt) (2012-04-28) |
Re: PL/I nostalgia bobduff@shell01.TheWorld.com (Robert A Duff) (2012-04-29) |
Re: PL/I nostalgia robin51@dodo.com.au (robin) (2012-09-19) |
Re: PL/I nostalgia gah@ugcs.caltech.edu (glen herrmannsfeldt) (2012-09-19) |
Re: PL/I nostalgia robin51@dodo.com.au (robin) (2012-09-21) |
Re: PL/I nostalgia gah@ugcs.caltech.edu (glen herrmannsfeldt) (2012-09-21) |
Re: PL/I nostalgia robin51@dodo.com.au (robin) (2012-09-30) |
From: | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
Newsgroups: | comp.compilers |
Date: | Wed, 19 Sep 2012 03:56:35 +0000 (UTC) |
Organization: | Aioe.org NNTP Server |
References: | 12-04-070 12-04-077 12-04-081 12-04-082 12-04-084 12-09-014 |
Keywords: | PL/I, history |
Posted-Date: | 20 Sep 2012 22:51:10 EDT |
robin <robin51@dodo.com.au> wrote:
>> [The code fron PL/I F was comparablw to Fortran G, but much worse than
>> Fortran H. The PL/I optimizing compiler's code was better, but still
>> not as good as Fortran H and its descendants. -John]
Well, the dynamically allocated variables and save areas for PL/I are
naturally slower than static allocated Fortran IV.
Also, many PL/I features naturally don't optimize as well as Fortran.
> Finally I have to hand Tucker's "Programming Languages".
I have one of those. Not my favorite, but not bad.
"History of Programming Languages" is better.
> Case study 2, matrix inversion with 20 x 20 data:
What page is that on?
> with IBM 370-145 FORTRAN (G) execution time 8.41 secs
> (H) execution time 5.28 secs.
> With IBM 370-145 PL/I (F) execution time 6.31 secs
> PL/I Optimiser execution time 5.77 secs.
> (refer to pages 112 and 279 for times)
Not in the second edition.
> However, in the case of the PL/I program, Tucker //omitted// to supply
> the option (REORDER) which is necessary to obtain full optimisation.
> Thus, the PL/I optimiser execution obtained was larger than it should
> have been.
When did that appear? I don't remember it in (F).
> It is clear that the times for FORTRAN (G) and PL/I(F) are equivalent,
> and that FORTRAN(H) and PL/I optimiser times are equivalent.
I suppose. A better test would use a larger matrix, though.
> As well as that, FORTRAN (H) required c. 150K of memory (i.e. a 256K
> machine) which was far more than the 128K that we had initially,
> whereas PL/I (F) required only 64K and IIRC FORTRAN (G) a little more.
If you really want to be fair, add the compilation time to the
run time, then see which one is faster.
-- glen
Return to the
comp.compilers page.
Search the
comp.compilers archives again.