Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!novia!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED!nerds-end From: glen herrmannsfeldt Newsgroups: comp.compilers Subject: Re: PL/I nostalgia Date: Wed, 19 Sep 2012 03:56:35 +0000 (UTC) Organization: Aioe.org NNTP Server Lines: 49 Sender: johnl@iecc.com Approved: comp.compilers@iecc.com Message-ID: <12-09-015@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> NNTP-Posting-Host: news.iecc.com X-Trace: leila.iecc.com 1348195870 5404 64.57.183.58 (21 Sep 2012 02:51:10 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Fri, 21 Sep 2012 02:51:10 +0000 (UTC) Keywords: PL/I, history Posted-Date: 20 Sep 2012 22:51:10 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com X-Original-Bytes: 2830 Xref: csiph.com comp.compilers:751 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. 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