IBM Mainframe Forum

Could any one suggest me few CPU usage optimization techniques?

Donald Knuth once wrote

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.”

You want to really save CPU?

Learn to program in assembler...

One general suggestion: Reduce I/O requests. I/O is more expensive in CPU utilization, both directly charged and hidden in system overhead, than most people appreciate. One of the few advantages of IBM's direct access storage architecture is it is readily, and easily, possible to do this. Especially for batch processing, use the largest possible BLKSIZE.

Every language - Cobol, PL/I, C++, whatever, has ways to use the language more efficiently. Even Assembler! Unfortunately, the techniques vary by language, and even the compiler used to process the language, so this is not an appropriate forum to try to discuss this topic.

The z13 has a cycle time of 192 picoseconds, I was reading the other day. Your CPU optimization will have to find a way to dramatically reduce the CPU usage in order to make any noticeable difference. These days, I recommend -- unless there is a known performance issue such as batch jobs not completing in the batch windows -- do not worry about CPU optimization as you'll spend more money worrying about it than you are likely to save.

Robert Sample wrote:The z13 has a cycle time of 192 picoseconds, I was reading the other day. Your CPU optimization will have to find a way to dramatically reduce the CPU usage in order to make any noticeable difference. These days, I recommend -- unless there is a known performance issue such as batch jobs not completing in the batch windows -- do not worry about CPU optimization as you'll spend more money worrying about it than you are likely to save.

Don't be too sure about that. Back in 1990 (for an IBM 3090) I showed some code to a friend. "You can cut an instruction or two from this loop," he said. "Nah," I thought, "I'll never see the difference." But I went ahead and cut the instruction, and, yes, I did see a difference. Not much, but it was there.

Where you can see a huge difference is when you change methods. Many of my applications allocate lots of little storage extents using MVS GETMAIN, and frees them, one at a time, using MVS FREEMAIN at the end. I instrumented one of my programs, and was horrified to find out how long the FREEMAIN section took when I fed my program humongous amounts of data. I think I know why FREEMAIN is so slow; in theory I could change the order the FREEMAINs were done, which would improve its performance, but there was another option.

Years ago I had written a private storage manager that was designed to address this problem. But in a way it was difficult to use, and, with smaller chains it didn't seem to make much difference, so it just gathered dust for many years. I dusted it off and put it in the instrumented program. It changed many CPU seconds to a tiny fraction of a CPU second!

The moral of my case study: before you start to optimize, know what you have to optimize.

These users thanked the author steve-myers for the post:

Aki88 (Sat Mar 19, 2016 12:57 am)

Thanks for that last post Steve, it was informative.
Will it be possible to show a code snippet of how the 'instruction cut' was made; it would be really helpful if you could kindly elaborate on it a tad bit.

Thanks again.

After 26 years you think I remember details? I just remember cutting one or two instructions in a loop. Sorry I can't remember the gory details

Hello Steve,

steve-myers wrote:After 26 years you think I remember details? I just remember cutting one or two instructions in a loop. Sorry I can't remember the gory details