"Anne & Lynn Wheeler" <lynn@[EMAIL PROTECTED]
> wrote in message
news:m37j8ymnnm.fsf@[EMAIL PROTECTED]
> "robin" <robin_v@[EMAIL PROTECTED]
> writes:
> > FYI, our s/360 was slower than the machine that it replaced for
> > small jobs -- yet the machine it replaced was 50 times slower (add
> > time 64uS). When LCS was put on the S/360, it ran even slower,
> > because the OS took up most of the fast memory, so that user
> > programs were loaded into slow memory.
>
> our 360/67 at the univ. had significantly worse thruput than the 709
> (tube machine) that it replaced. the 360/67 had 8-byte wide 750ns
> memory (and instruction) cycle time (compared to 360/50 2-byte 2mic
> memory, and most LCS was 8mic). 360/67 was essentially a 360/65 that
> had virtual memory hardware bolted on.
>
> a dominate workload was fortran student jobs ... there was 1401
> front-end that handled unitrecord<->tape ... and you carried tapes
> between the 1401 and 709 (this was 40 yrs ago, 1966). the 709 fortran
> monitor ran student jobs (tape to tape) at a couple seconds per.
>
> 360/67 came in with os/360 and 2311 disks. job processing was
> syncronous with unit record process ... read the cards ... write stuff
> to disk, read stuff from disk, eventually execute ... print output
> ... do the next job. this was taking minutes per student job. most of
> the time 360/67 ran as non-virtual memory 360/65 with vanilla os/360.
> the 67 associative array hardware lookup (virtual to real address
> translation) did add 150ns to 750ns basic memory cycle (900ms total).
>
> by os/mft11 release, the univ got HASP, which decoupled the unit
> record processing from the job execution. the other operating system
> gorp of moving lots of stuff back&forth between memory and disk was
> still resulting in student fortran job processing taking over 30
> seconds.
>
> i did a lot of detailed analysis and careful construction/placement of
> operating system stuff on disk for optimized arm seek operation and
> got the typical student fortran job elapsed time to a little under 12
> seconds (still longer than they had run on 709) ... but almost three
> times faster than it had been taking.
>
> it wasn't until we got watfor monitor from univ. of waterloo that
> student fortran job thruput started to exceed what it had been on the
> 709.
Your experiences with LCS, HASP, and WATFOR pretty well match
ours. The time for a small job in Fortran, PL/I, and COBOL using IBM
compilers took about one-and-a-half minutes. Much of that was
taken up by the link editor. We were able to improve on that
somewhat by buffering compiler I/O, but with limited memory
there was an upper bound on buffer size.
The real improvements came with HASP and WATFOR,
as with WATFOR the I/O bottleneck became worse.
> i gave talk at fall '68 share meeting in boston on both the
> optimization work on os/360 as well extensive kernel rewrites that i
> had done to cp/67 (i was still undergraduate) ... previous posting
> referencing part of that talk
> http://www.garlic.com/~lynn/94.html#18
CP/67 & OS MFT14
> http://www.garlic.com/~lynn/94.html#20
CP/67 & OS MFT14
>
> for a little drift ... i had done some of the work on gcard ...
> an ios3270 version of the 360 green card ... and just recently
> did something of a rough conversion to html
> http://www.garlic.com/~lynn/gcard.html
>
> and of course, the 360 functional characteristics do***ents game
> detailed machine timings ... several have been scanned and are
> available here (including 360/65, 360/67, 360/91, and 360/195):
> http://bitsavers.trailing-edge.com/pdf/ibm/360/funcChar/
> http://www.bitsavers.org/pdf/ibm/360/funcChar/
> --
> Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
|
