Charles Mills wrote: >I am responsible for a z/OS program that runs as a started task and processes >asynchronous "events." (IEFU8x exits being driven with particular SMF records, >but no matter.) After much head-scratching, I figured out that CPU time per >event was GREATLY and fairly predictably affected by how rapidly the events >occurred! I have a "driver" program that I can use to artificially push >simulated SMF records through the program, and I found that if I run that >driver program at a leisurely pace, perhaps 15 events per second, then 1000 >records consume about .2 CPU seconds. But if I drive records through the >program as fast as it can handle them -- about 12,000 records per second -- >then each 1000 records consume about .083 CPU seconds -- LESS THAN HALF as >much. (If you do the arithmetic you can see that at 12,000 records per second >the program is pegging one CPU at 100%.) BTW, the program is single-thread and >cannot exploit multiple CPUs.
Hmmm, very interesting and tasty story! I really enjoyed reading it. Thanks! >I don't really know, but my conclusion is that either "getting interrupted" >consumes a fair amount of CPU time, or else that if the program is busy >continuously it tends to "own" the instruction and data caches, which saves a >lot of CPU time. >I would be interested in any comments on the situation or my analysis of it. >I'm not "unhappy" or terribly surprised -- this is just engineering >intelligence I am after here. It's kind of a good thing: the busier the >program is, the better it runs. A much more favorable situation than the other >way around. One possible reason is : "prediction of next instruction, so it can be pre-fetched/cached [L2 or L1 cache or similar cache ] before it is executed" or something like that. If your exit is small or compact enough and all code and data areas are sitting in a somewhat smallish block, I would not be surprised that you get a benefit. Good for you! ;-) Hmmm, you're a better programmer than me. ;-D Groete / Greetings Elardus Engelbrecht ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
