Re: PL/I nostalgia

From: "glen herrmannsfeldt" <gah@ugcs.caltech.edu>
Sent: Wednesday, 25 April 2012 9:52 AM


> robin <robin51@dodo.com.au> wrote:
>
> (snip, glen herrmannsfeldt wrote)
>>>It has always seemed to me that PL/I would have been more successful
>>>if the early compilers generated faster code (and ran faster, too).
>
> (previous snip on I/O bound COBOL, and not worrying about CPU time.)
>
>>>It might have been that too much of the above was adopted, along with
>>>other COBOL features, by PL/I. There are many things that other
>>>languages, such as Fortran, traditionally didn't let you do, because
>>>they might run too slow, but that PL/I allowed.
>
>> FORTRAN was developed by 1956.
>> PL/I was developed by 1966.
>> In the decade after 1956, many deficiencies had been identified
>> in FORTRAN; some of its statements were pretty crude.
>
> This is true, but not so important for this question.


It is fundamentally important, since you raised it 2 paras ago, as to
what was put in PL/I and why. FORTRAN was deficient in many areas,
including I/O, its use of EQUIVALENCE and COMMON, character strings,
and DO loops. Algol already had recursion; FORTRAN didn't, and that
deficiency made it difficult to write algorithms that were general and
which dealt with dynamic arrays that, in scientific computation, was a
pressing need.


> Fortran didn't allow for recursion until 1990, and even then you had
> to have the RECURSIVE attribute. Compilers could still generate
> non-recursive code without the attribute.


All that's irrelevant.


> There is overhead to the calling sequence to allow for recursion, at
> least on most systems. It was usual for Fortran compilers to use
> static allocation through Fortran 77. (Some rules were written
> specifically to allow for it.) On machines without a call stack, there
> is also overhead for that, in addition to local variable allocation.


The overhead is small, and in many programs, negligible.


> Even more for PL/I, the ability to do multi-tasking adds more
> complications that have more overhead.


An irrelevant consideration in this discussion.


>> Similar comments may be made about COBOL.
>
> As noted, this was in response to a suggestion that COBOL programs
> were I/O bound, and so there was less need for CPU time optimization.


Any program can be I/O bound. There are, nevertheless, COBOL
programs that are not I/O bound. Even in ones that are, time can be
saved through optimisation, as a reduction in the run-time of
the computational components that cannot be overlapped with I/O
reduces overall time.


> On the other hand, I/O optimizations such as locate mode I/O would
> have been more important for COBOL.


That isn't an "optimisation", it's a programming strategy.


>> While some features of both FORTRAN and COBOL were adopted
>> in PL/I, many new features were added, including (but not
>> limited to) recursive procedures and dynamic allocation
>> (already in Algol).
>
>> Of those features adapted from the older languages, arbitrary
>> restrictions were removed, making it much easier to write programs.
>
> And much easier to write slow programs.


No, it does not. The removal of arcane restrictions made it easier to
write error-free programs.


It's always easy to write slow programs, even in FORTRAN.
The restrictions removed from the older languages, however,
made it easier to write faster programs.


It also made it easier to write programs in shorter time than
before.


Furthermore, the necessity in FORTRAN of having all storage
as static meant that programs employing large arrays or lots of arrays
used the processor inefficiently in that the executable programs
tied up more memory than was necessary. Compared to PL/I,
which provides dynamic arrays, considerably less run-time
memory was required.


[In case it is thought from the above that PL/I provides only dynamic arrays,
may I point out that PL/I provides dynamic and static arrays,
as well as controlled arrays.]


> Simple PL/I expressions can
> require temporary arrays. (Usually with a warning message.)
>
> That didn't happen to Fortran until 1990, when machines were much
> faster.


That's relative, and in any case irrelevant.
Machines were much faster in 1966 compared to 1956.


>> One other point is that the size of machines had increased
>> significantly in that early decade, permitting more language
>> features to be incorporated in PL/I.
>
> But the window was fairly small. IBM had originally expected to
> replace Fortran (and maybe COBOL) with PL/I. The compiler arrived
> late, ran slow, and generated much slower code.


You're wrong on both counts. The hardware was late. All the
compilers were late. The code from IBM's PL/I was just as good as
from IBM's Fortran compilers on the machine that we had. I still have
the results somewhere of test runs in FORTRAN and PL/I. It was the
link editor that took longer with PL/I than with FORTRAN.


>> PL/I can be considered to be the first general-purpose language.
>
>> As to code generation of the early PL/I compilers, that code
>> was reasonably efficient.
>
> For many scientific problems, reasonably isn't enough.


I should have been more explicit. Code generation from IBM's
FORTRAN compilers on the machine that we had was reasonably efficient too.


What is just as important is what happens when a program runs.
FORTRAN programs often halted (division by zero, floating-point
overflow) without any indication of where or why they halted.


Even were a FORTRAN program to run faster than a PL/I program, any
such "saving" would be more than lost by having to re-run the FORTRAN
program to try to find where and why it stopped.


There was (and still is) no need to re-run the PL/I program to do
that, because the location and the reason were printed when the PL/I
program halted. Given that it was also possible to print the values
of any variables along with the above information, the
debugging/development of the program saved a good deal of machine
time.


On the issue of whether PL/I was faster or slower than FORTRAN,
it's clear that those making timing comparisons did not know
how to write or to run PL/I programs.


One published account (D. J. Kewley, "A Comparison between
Pascal, FORTRAN, and PL/I", ACJ, Feb. 1981, pp 27-8)
claimed that Pascal was faster than PL/I,
and the author produced timing figures to "prove" it.
The author failed to specify the PL/I option "REORDER" that would
permit optimisation to take place. Furthermore, he compared
one Pascal program performing complex arithmetic, with a PL/I
program doing the same. Not supporting complex arithmetic,
the Pascal program simulated those operations. When the PL/I
version was rewritten using complex arithmetic,
and with the REORDER option on the PROCEDURE statement,
a 47% increase in speed was obtained. (see my refutation, ACJ, Aug. 1981, p. 107)


In his published accounts of timing comparisons between
COBOL, PL/I, and FORTRAN, A. B. Tucker (Programming Languages",
McGraw-Hill, 1977) neglected to specify the REORDER option.
This neglect again prevented the PL/I compiler
from optimising the object programs, and therefore invalidated
his timing and code comparisons with COBOL and FORTRAN.


In P. J. Jaliks, "COBOL vs PL/I: Some Performance Comparisons",
CACM, April 1984, pp. 216-221, similar errors were made for the PL/I version.
In particular, one PL/I program ran two to three times slower
on account of inappropriate data declarations.


More recently, R. H. Prins criticized IBM's Enterprise PL/I compiler for
optimising poorly. He subsequently retracted that criticism when
he discovered that he had been compiling the program with OPT(0) --
that is, no optimisation !


FORTRAN programmers tended to mimic FORTRAN style in
their PL/I code that was inappropriate in PL/I.
That caused PL/I programs to run slower than they should have.


>> I would agree, however, there were certain situations where much
>> faster code could have been generated, but that opportunity was
>> not taken.
>
>> I refer to operations involving whole arrays or array sections.
>> For instance, where an operation involved a whole array,
>> IBM's first compiler, PL/I-F, could have optimised a matrix statement
>> (trivial example, A=B; where all elements of A and B are accessed)
>> to a single loop, instead of the two equivalent loops that were actually used:
>> do i = 1 to m;
>> do j = 1 to n;
>> A(i,j) = B(i,j);
>> end;
>> end;
>
> In some cases you can do that, but it isn't so easy in a subroutine,
> when the array might not be contiguous.


IIRC, in IBM's F-compiler, elements in arrays were contiguous,
even in subroutines. [Even were that not so, a single loop suffices.]


> Also, since array operations were added to Fortran, they are one of
> the biggest causes for complaints about slow programs.


Fortran 90 introduced array features (in a manner different from PL/I)
that forces temporary arrays to be created, and which results in
Fortran programs running slower than equivalent features not using
the new array features.


> One reason is that people sometimes write array expressions that
> require much more computation than they would written as loops.


That's their choice.


> PL/I only supports call-by-descriptor for arrays and strings. That is
> good, but has more overhead.


Than what? Not having descriptors?
Descriptors are necessary to deal with dynamic arrays.
Without descriptors, it would be back to pre-Fortran 90,
where only the address of the first element of an array was typically passed.


That arrangement impeded or prevented information about
a FORTRAN array being made available to a subroutine.


> For today's machines, that isn't so bad,
> but on slower machines in the early days, it may have been too much.


The "overheads" of passing a descriptor to a subroutine
were (and still are) minimal.


>> Four years later, IBM produced their Optimising Compiler and
>> Checkout Compiler (c. 1970).
>
>>>(Many of those have now been added to Fortran.)
>
>> Some have, but others have not.
>> For example, recent discussion in comp.lang.fortran evolved
>> around a suitable Fortran procedure to convert an integer to a string.
>
>> In PL/I, it requires a simple statement, s = i;
>
> It is one of the fun features of PL/I, but not so often needed in
> production programs.


It's been a recurring chestnut in FORTRAN/Fortran for the past 40 years.
It's an important feature of any program. It's not relevant to mention
"production" programs. Whether a program runs once or a hundred times
is irrelevant.


Conversion to a character string is something that's used often in PL/I
in conjunction with the TRIM function to remove leading blanks.


[Irrelevant material omitted.]


>> [Considering what a rush job PL/I was, it's a remarkably good
>> language. -John]
>
> I didn't know about that until recently when I bought "History
> of Programming Languages", edited by Richard L. Wexelblat, which
> covers the timeline for the PL/I language specification. (Writing
> the actual compiler was a separate timeline.)
>
> As well as I can tell, it was October 1963 that the decision to
> design a new language, instead of going to Fortran VI, was final,
> and the group formed to write the specification. They were told
> that it needed to be done by December 1963. In December, it was
> extended to January 1964, and then slipped to February.


That those early dates slipped is irrelevant, as the S/360 wasn't even
announced until 1964. In any case, a slippage by a few months
was unimportant.


> Then there is the comment:
>
> "While this can never be proven, it is clear that much of the
> long and demanding work in PL/I language development would have
> been made much easier ahd the designing committee been given
> six months or a year at the beginning to lay down a carefully
> defined language base."


Work on designs for the new language had already been in progress
prior to October 1963, so at that point much was known as to what
would be put into PL/I (or New Programming Language as it was called
before it was PL/I.)
[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]

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