On 6 Feb 2008 15:28:20 -0800, in bit.listserv.ibm-main you wrote: >>I don't want to offend anyone, but if you're worried about CPU microseconds >>and coding in high-level languages, I would suggest there is a fundamental >disconnect and it makes me think you're not really serious. > >Hear! Hear! >I cannot count the number of times I have overseen an upgrade to a processor, >and had management complain that throughput, or response, had not improved. > >Most of the time, I had already told them that there was an I/O bottleneck, >tape-drive contention, scheduling, etc. issue. >But, they told me to upgrade the processor, anyways. >Yes, we usually needed the processor, but the other issues would usually give >us a better improvement. > >Empirically, I have seen that the I/O content of most processing (online or >batch) has increased since the early 1980's. This is especially true if you >are using DB2. > >I have had a lot of one-hour+ jobs using less than 2 minutes of CPU. We call >these I/O-bound jobs. >So, even if I double the speed of the CPU, I have improved these long running >jobs by one minute. > >Microseconds don't count, any more.
When doing application tuning in COBOL, I checked the CPU time versus run time. A few programs had enough CPU that it was worth while to go further. Most of the time elimination of I-O was the better route and I really did well with monitored use of batch LSR. One large CPU consumer re-read records and wrote out unchanged records so caching by record type and doing a full record compare saved over a million reads and thousands of writes. I also tuned a date routine after warning people that even though it was a somewhat heavy consumer, it was less than 10 percent of the CPU in that program. I could prove that I got a 50 percent improvement in the date calculation speed but in practice it was a nit. Because I had given the warning and also could show the improvement in the date calculation itself, they kept me on for another 4 years. Clark Morris > >- >Too busy driving to stop for gas! > >---------------------------------------------------------------------- >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 ---------------------------------------------------------------------- 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
