glen herrmannsfeldt <g...@ugcs.caltech.edu> writes: > I once had PL/I (F) running on an AT/370, about 5 minutes > to compiler a five line program.
re: http://www.garlic.com/~lynn/2011m.html#61 JCL CROSS-REFERENCE Utilities (OT for Paul, Rick, and Shmuel) http://www.garlic.com/~lynn/2011m.html#62 JCL CROSS-REFERENCE Utilities (OT for Paul, Rick, and Shmuel) http://www.garlic.com/~lynn/2011m.html#63 JCL CROSS-REFERENCE Utilities (OT for Paul, Rick, and Shmuel) xt/370 & at/370 was motorola 68k fiddled to execute 370 instructions at about 100kips. the original cardset had 384k bytes of 370 memory ... which ran special modified vm370 kernel plus the real storage for demand paging of cms. the 370 card had no i/o ... vm370 was modified to send messages to cp88 running on the intel chip ... and all i/o was done by cp88 running on the pc side ... and then transfers between vm370 and cp88. it started out code-named "washington" and the pc/xt had 100ms per transfer disk ... each page transfer or cms file record transfer took 100ms on pc/xt hard disk (maximum aggregate rate would be less than 10 transfer per second with vm370/cp88 overhead & transferlatency). After fix vm370 kernel ... there was very little left of the 384k bytes for paging cms and application virtual memory ... resulting in page thrashing. I benchmarked and showed significant page thrashing even for realy trivial operations. I got blamed for six month schedule slip in washington while they re-engineered the cards to add another 128kbytes of 370 memory (increase from 384kbytes to 512kbytes) to minimize virtual memory page thrashing (i done a bunch of benchmarks showing page thrashing) pli compiler would have both significant virtual memory thrashing (even with the additional 128kbyte real storage ... i don't remember exactly now ... but vm370 fixed kernel storage was possibly something like 150kbytes ... with 512kbyte real storage ... that would leave approx. 350kbytes of real storage for cms virtual memory ... the cms kernel, cms system services ... and the pli compiler and data areas. the upgrade from xt/370 to at/370 met that cp88 ran on somewhat faster processor and the hard disks were faster ... 5 minutes is 300 seconds ... say if you are lucky maybe 15 disk record transfers per second ... 4500 disk record transfers ... which is page thrashing, loading pli compiler execution, and all other file i/o. A big issue was that cms was relatively bloated in terms of its use of file i/o ... and all of the cms compilers were brought over from mvs using simulation of systerm services ... which were really bloated in terms of use of file i/o. remapping that environment to a PC ... using PC disks instead of mainframe disks was quite tramatic ... compared to similar applications developed specifically for pc environment. Even running applications that fit in the available 370 real storage (and didn't page thrash) ... the 100kip 370 processor wasn't usually the bottleneck ... it was the enormous difference between thruput of mainframe disks and pc disks. Of course that wouldn't be a problem these days because both PCs and mainframes use the same disk technology ... PCs using native disk technolgy and many mainframes using emulated CKD on top of native disks (there hasn't been real ckd disks for decades). I did some prototype work for washington with my cms paged mapped filesystem for washington ... on mainframe with 3380 i could possible three times improved (300%) throughput compared to standard cms filesystem for applications that did moderate amounts of file i/o. ... but still couldn't achieve look&feel of cms with real mainframe disks. misc. past posts mentioning memory mapped filesystem for cms ... orginally done for cp67 and then ported to vm370 http://www.garlic.com/~lynn/submain.html#mmap follow-on to at/370 was a74 ... separate box with 4mbytes of 370 real storage and 350kip processor. old long-winded post that includes copy of A74 product description at the bottom http://www.garlic.com/~lynn/2002d.html#4 -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
