Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Anne & Lynn Wheeler Newsgroups: alt.folklore.computers Subject: Re: iBM System/3 FORTRAN for engineering/science work? Date: Mon, 05 Jul 2021 13:39:18 -1000 Organization: Wheeler&Wheeler Lines: 50 Message-ID: <87mtr05o0p.fsf@localhost> References: <257298b0-715f-465d-94b0-a8b98a4bf8f9n@googlegroups.com> <61a2844e-6902-436a-ac3d-1276db6bdea3n@googlegroups.com> <1260624561.646618562.491585.peter_flass-yahoo.com@news.eternal-september.org> <1faf3699-bbb8-4829-b1e4-deb75fe6c237n@googlegroups.com> <987158719.646770905.339072.peter_flass-yahoo.com@news.eternal-september.org> <281782900.646856626.461544.peter_flass-yahoo.com@news.eternal-september.org> <6008b75f-7196-4734-bdda-0cb70d9a7d2dn@googlegroups.com> <723758665.646872522.971131.peter_flass-yahoo.com@news.eternal-september.org> <465f11f2-5002-4e7e-a114-ea9ea3d30a4en@googlegroups.com> <0e35d23a-163a-47f1-8505-94769193bfb5n@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="1232752b4b6b00a092d9fa41182b9735"; logging-data="23513"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/swERoXNGfraAVscULomZYFgpBXQmr7YM=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:7+Fhtvm0YZjOG7s33NaLkKt6z7Q= sha1:P/0JNrWuEwm+ircyXSPQnK+WFkI= Xref: csiph.com alt.folklore.computers:218274 Robin Vowels writes: > What??!! IBM's FORTRAN G compiled at about the same speed as their PL/I-F > compiler. > FORTRAN H took about twice as long as FORTRAN G, and in addition > required 4 times as much memory as PL/I-F. > . > Link time for PL/I-F took slightly longer than FORTRAN G. > . > WATFOR and PL/C were both high-speed compilers & were > available for S/360 -- and much faster than the corresponding > IBM products. I took two semester hr intro to fortran/computers, univ. ran 709 tape->tape with tapes moved between 709 and 1401 that ran as front-end for unit record (card->tape, tape->printer/punch). Student fortran jobs (30-60 cards) ran under second elapsed time. Univ. was sold 360/67 originally for tss/360, but never quite came to production fruition and so ran as 360/65 with os/360. within year of taking intro class, I was hired fulltime responsible for the ibm mainframe. Initially student jobs ran well over a minute three step fortran G, compile, link-edit, go/execute. I then installed HASP which cut elapsed time about in half (nearly all job step overhead and file open/close). First os/360 sysgen I did was release 9.5. I then started tearing apart stage2 sysgen and reorganizing the cards to optimize placement of files and PDS members for arm seek and PDS directory multi-track search which improved student jobs by nearly another 2/3rds ... 12.9sec elapsed ... approx. 4.3sec/job-step. It wasn't until installed single step, batch WATFOR monitor that student jobs ran faster than 709. WATFOR ran approx. 20,000 card(statements) per min (333/sec) on 360/65. Typically a card tray (2000+ cards, 30-60 student jobs) would be batched in single step ... 4.3sec/single-step + 2000/333 secs ... 10.3sec elapsed for batching 30-60 student jobs ... around .2secs/job. WATFOR would have still been slower than 709 (i.e. 4.5sec/job) if it wasn't for batching multiple jobs per single-step execution (and w/o my careful sysgen and hasp, it would be more like 20secs if ran single student job per invokation). One of the guys up at IBM palo alto science center (that had done much of the work for the 370/145 APL microcode assist ... got APL throughput up close to 370/168) ... did a lot of optimization work on Fortran H that originally was available inside IBM as Fortran Q ... and eventually released to customers as Fortran HX. -- virtualization experience starting Jan1968, online at home since Mar1970