Re: PL/I nostalgia

"robin" <robin51@dodo.com.au>
Fri, 21 Sep 2012 13:53:13 +1000

          From comp.compilers

Related articles
[3 earlier articles]
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)
| List of all articles for this month |

From: "robin" <robin51@dodo.com.au>
Newsgroups: comp.compilers
Date: Fri, 21 Sep 2012 13:53:13 +1000
Organization: Compilers Central
References: 12-04-070 12-04-077 12-04-081 12-04-082 12-04-084 12-09-014 12-09-015
Keywords: history, PL/I
Posted-Date: 21 Sep 2012 00:23:54 EDT

From: "glen herrmannsfeldt" <gah@ugcs.caltech.edu>
Sent: Wednesday, 19 September 2012 1:56 PM




> 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.


But not where it counts. By the time some procedure (such as INVERT)
is called, the array(s) has(have) been allocated. Allocation is a
once-off task, probably not measurable in terms of time. And the
FORTRAN IV code was, essentially, rigid, and required re-compilation
for larger arrays.


> Also, many PL/I features naturally don't optimize as well as Fortran.


That may be so, but to have to re-compile the FORTRAN code to deal
with larger-sized arrays counted strongly against it. As well, PL/I
offered full roll-out of fixed-size array operations Not all arrays
needed to be dynamic. As well as that, PL/I offered such things as
double precision complex, string-handling, and error recovery.


Error recovery more than compensated for any difference in speed that
may have existed between FORTRAN and PL/I. Having to re-run FORTRAN
code because of some error to find out what went wrong outweighed any
speed advantage that FORTRAN might have had, because in PL/I, the
error information was already there (including values of variables),
and without necessarily a program termination. Hence, a re-run of the
PL/I code was avoided. That was important, not only in terms of
machine time, but also in terms of turn-around time, because
turn-around time in those days was as much as a week.


> 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?


Look in the index.


>> 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 wasn't in F, but it was in the optimising compiler, where it counted.


>> 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.


20 W 20 is more than large enough.
It's the size of a typical matrix in a typical job.


>> 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.


Compilation time is only relevant when the run-time is very short.
When speed mattered, it was in long-running executable codes,
in which case, compilation time was unimportant.


To get the entire time for a job, you'd have to add in the link time,
which Tucker didn't provide.


And if compilation time was important, such as in short jobs,
you'd have used PL/C or WATFOR.


Post a followup to this message

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