The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
Neal Eckhardt <[EMAIL PROTECTED]> writes: > We also had the batch window running so long that we were missing > deadlines, and the CIO asked me to review the program stream to see > what could be done to make it run faster (yea, good luck with that, > they were all database programs and that's a different group). I told > him that our new CPU (of essentially the same speed) that was due to > arrive in two weeks had two processors rather than the four processors > our current machine had, and the problem would probably be resolved > with the installation of our new CPU. re: http://www.garlic.com/~lynn/2008c.html#88 CPU time differences for the same job the issue raised in post about disk thruput ... was over a period of years, processors got around 50 times faster in a period that disks only got 3-4 (maybe 5) times faster. Some claims are that the relative abundance of processor power led to a lot of (processor) implementation inefficiencies ... which could be relatively straight forwardly improved if anybody were to pay any attention. as circuit size decreased ... and processor thruput increased ... lots of signal latencies started to play larger and larger factor. the latencies (measured in number of processor cycles) that played a part in processor/disk thruput ... started to also dominant processor & real storage ... and in much the same way that real storage started to be used as caches to compensate for disk thruput ... processor caches became more & more important compensating for memory latency. in fact, using processor cycles as a measure of memory access time ... became one way of easily recognizing the problem (memories got faster, but processors got much, much faster) ... especially when references were to cache-miss and memory latency measured in possibly thousands of processor cycles. for little drift, recent posts mentioning improving application hitting (overnight) batch window limits http://www.garlic.com/~lynn/2008b.html#74 Too much change opens up financial fault lines http://www.garlic.com/~lynn/2008c.html#24 Job add for z/OS systems programmer trainee and for something totally different ... recent discussion of electronic commerce implementations running into problems hitting overnight window limit http://www.garlic.com/~lynn/2008c.html#85 Human error tops the list of security threats multitasking and multithreading have been used in the past attempting to mask disk access latencies ... keeping processor busy while something was wait for disk access. earlier in this decade ... there were chip "hyperthreading" solutions also looking at keeping processor functional units busy ... compensate/mask cache-miss & memory access latency. the number of processor functional units weren't actually increased ... but there was hardware emulation of two processors ... basically two instruction streams, two sets of registers, etc ... but actual execution being done by common functional units. possibly the original in this genre was a project to do a dual i-stream implementation for 370/195 (i.e. emulation of two-processor smp) ... which never actually shipped as product. the issue was that 195 had a 64 instruction pipeline that could execute instructions concurrently with common set of functional units. the pipeline could go a long way towards masking the difference in processor thruput and memory latency (w/o actually having a cache). The problem was that the amount of processor logic/memory supporting this function was rather limited. These days, chip implementations may have several hundred positions for dealing with branch prediction and speculative execution (and backing out instructions not actually branched to). In the 370/195, except in very special cases, branches would drain the pipeline. Normal codes, with typical branch useage, resulted in 195 running at half peak thruput (it took careful programming to keep 195 operating at peak thruput). The "idea" behind the dual i-stream was to have two sets of independent instruction streams ... both operating at half peak thruput ... but combined, capable of keeping the 195 pipeline fully stocked with instructions. misc. past posts mentioning dual i-stream as (one of the) mechanism for compensating/masking increasing memory latencies (as measured in processor cycles) http://www.garlic.com/~lynn/94.html#38 IBM 370/195 http://www.garlic.com/~lynn/99.html#73 The Chronology http://www.garlic.com/~lynn/99.html#97 Power4 = 2 cpu's on die? http://www.garlic.com/~lynn/2000g.html#15 360/370 instruction cycle time http://www.garlic.com/~lynn/2001j.html#27 Pentium 4 SMT "Hyperthreading" http://www.garlic.com/~lynn/2001n.html#63 Hyper-Threading Technology - Intel information. http://www.garlic.com/~lynn/2002g.html#70 Pipelining in the past http://www.garlic.com/~lynn/2002g.html#76 Pipelining in the past http://www.garlic.com/~lynn/2003l.html#48 IBM Manuals from the 1940's and 1950's http://www.garlic.com/~lynn/2003m.html#60 S/360 undocumented instructions? http://www.garlic.com/~lynn/2003p.html#3 Hyperthreading vs. SMP http://www.garlic.com/~lynn/2004.html#27 dual processors: not just for breakfast anymore? http://www.garlic.com/~lynn/2004e.html#1 A POX on you, Dennis Ritchie!!! http://www.garlic.com/~lynn/2004o.html#18 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2005.html#5 [Lit.] Buffer overruns http://www.garlic.com/~lynn/2005.html#19 The Soul of Barb's New Machine (was Re: creat) http://www.garlic.com/~lynn/2005f.html#22 System/360; Hardwired vs. Microcoded http://www.garlic.com/~lynn/2005p.html#1 Intel engineer discusses their dual-core design http://www.garlic.com/~lynn/2005p.html#14 Multicores http://www.garlic.com/~lynn/2006c.html#6 IBM 610 workstation computer http://www.garlic.com/~lynn/2006c.html#29 IBM 610 workstation computer http://www.garlic.com/~lynn/2006d.html#0 IBM 610 workstation computer http://www.garlic.com/~lynn/2006d.html#10 IBM 610 workstation computer http://www.garlic.com/~lynn/2006m.html#51 The System/360 Model 20 Wasn't As Bad As All That http://www.garlic.com/~lynn/2006r.html#2 Was FORTRAN buggy? http://www.garlic.com/~lynn/2006s.html#21 Very slow booting and running and brain-dead OS's? http://www.garlic.com/~lynn/2006t.html#41 The Future of CPUs: What's After Multi-Core? http://www.garlic.com/~lynn/2007f.html#10 Beyond multicore http://www.garlic.com/~lynn/2007r.html#20 Abend S0C0 http://www.garlic.com/~lynn/2007t.html#37 Intel memory latencies ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
