Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED!nerds-end From: "robin" Newsgroups: comp.compilers Subject: Re: PL/I nostalgia Date: Fri, 21 Sep 2012 13:53:13 +1000 Organization: Compilers Central Lines: 90 Sender: johnl@iecc.com Approved: comp.compilers@iecc.com Message-ID: <12-09-016@comp.compilers> References: <12-04-070@comp.compilers> <12-04-077@comp.compilers> <12-04-081@comp.compilers> <12-04-082@comp.compilers> <12-04-084@comp.compilers> <12-09-014@comp.compilers> <12-09-015@comp.compilers> NNTP-Posting-Host: news.iecc.com Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Trace: leila.iecc.com 1348201434 19299 64.57.183.58 (21 Sep 2012 04:23:54 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Fri, 21 Sep 2012 04:23:54 +0000 (UTC) Keywords: history, PL/I Posted-Date: 21 Sep 2012 00:23:54 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com X-Received-Bytes: 5040 Xref: csiph.com comp.compilers:752 From: "glen herrmannsfeldt" Sent: Wednesday, 19 September 2012 1:56 PM > robin 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.