peter.far...@broadridge.com (Farley, Peter x23353) writes: > Attention to details like this (and some similar optimizations) saved > one application I have worked on almost 50% of its previous CPU > utilization without changing the application algorithm in any other way.
the science center had pioneered a lot of performance tools in the 60s & 70s, workload profiling ... and stuff that eventually turned into things like capacity planning. misc. past posts mentioning science center, 4th flr, 545 tech sq http://www.garlic.com/~lynn/subtopic.html#545tech they had activity counter snap shots ... starting with the science center cp67 ... eventually every 5-10 mins, 7x24 for nearly decade. the convention was followed by internal systems installing first cp67 and then vm370 ... so there were hundreds of systems with lots of different workloads & configurations with years of data. another activity was several system simulators ... some written in pli others in apl ... that could simulate effects of different algorithms. one of the apl simulators ... using the enormous amount of snapshot information evolved into the "performance predictor" ... made available on the worldwide sales & marketing hone system; customer support people could enter profiles of their customers workload & configuration ... and then ask what-if questions regarding what happens selling an additional mbyte of memory (or other configurations changes) &/or what happens when there are workload changes. in the 90s, rights to a descendent of the "performance predictor" were sold ... the person ran it thru and apl-to-c convertor and then made a living doing consulting at number of high-end datacenters around the world. the science center also did some number of other kinds of hot-spot monitoring. not at cambridge ... but from palo alto science center (by people that brought you the 370/145 apl microcode assist) ... they gen'ed up a 145 microcode path for me that sampled instruction address. I used this for help in identifying pieces of code to be dropped into microcode for the ECPS performance assist. this is old post with result of some of the other kinds of analysis done on the kernel code as part of selecting what went into the microcode: http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist The science center also did a project that started out with the POK "redcap" instruction simulator (recorded information about each instruction simulated ... was used in helping design processors &/or new instruction). Several changes to the information recording were made at the science center ... which was then used as input into a virtual memory simulator. Science center eventually released this as "vs/repack" product ... which included ability to do semi-automated program re-organization. It was used by a number of corporate products ... both as an instruction "hot-spot" identifier ... as well as helping in transition from real storage environment to virtual memory environment (i.e. products like IMS made a lot of use of it). about the turn of the century had a chance to look at a large, 450+K statement cobol application that ran all night on something like 40+ CECs (billion plus in mainframe equipment). the consultant that was using the descendent of the "performance predictor" had been called in on the project ... to look for possible system and application bottlenecks. the operation also had a large performance group that had been tending the application for years (decades?) ... mostly with hotspot analysis. the consultant turned up some things that had gone unnoticed by the group doing hot-spot analysis ... but there was still strong feeling that there was significant thruput inefficiencies (in part based on cpu processing/operation from decades earlier and currently). One of the things done at the science center decades earlier was multiple regression analysis of the activity counters. I decided to try something similar for this application; collected fairly large number of application counts from several nights run across large number of CECs. It turned up some "meta" level activity that was quite anomolous ... and when reworked, resulted in significant thruput improvement. Part of the issue was that the system analytical models and the hot-spot analysis had been highlighting "micro" level activity ... but didn't catch the application doing several anomolous unnecessary passes of whole operations. misc. past posts mentioning "performance predictor" &/or "vs/repack": http://www.garlic.com/~lynn/94.html#7 IBM 7090 (360s, 370s, apl, etc) http://www.garlic.com/~lynn/99.html#68 The Melissa Virus or War on Microsoft? http://www.garlic.com/~lynn/2000g.html#30 Could CDR-coding be on the way back? http://www.garlic.com/~lynn/2001b.html#83 Z/90, S/390, 370/ESA (slightly off topic) http://www.garlic.com/~lynn/2001c.html#31 database (or b-tree) page sizes http://www.garlic.com/~lynn/2001c.html#33 database (or b-tree) page sizes http://www.garlic.com/~lynn/2001i.html#20 Very CISC Instuctions (Was: why the machine word size ...) http://www.garlic.com/~lynn/2001i.html#46 Withdrawal Announcement 901-218 - No More 'small machines' http://www.garlic.com/~lynn/2002b.html#64 ... the need for a Museum of Computer Software http://www.garlic.com/~lynn/2002c.html#28 OS Workloads : Interactive etc http://www.garlic.com/~lynn/2002c.html#45 cp/67 addenda (cross-post warning) http://www.garlic.com/~lynn/2002c.html#46 cp/67 addenda (cross-post warning) http://www.garlic.com/~lynn/2002c.html#49 Swapper was Re: History of Login Names http://www.garlic.com/~lynn/2002e.html#50 IBM going after Strobe? http://www.garlic.com/~lynn/2002f.html#50 Blade architectures http://www.garlic.com/~lynn/2002q.html#28 Origin of XAUTOLOG (x-post) http://www.garlic.com/~lynn/2003f.html#15 Alpha performance, why? http://www.garlic.com/~lynn/2003f.html#21 "Super-Cheap" Supercomputing http://www.garlic.com/~lynn/2003f.html#53 Alpha performance, why? http://www.garlic.com/~lynn/2003g.html#15 Disk capacity and backup solutions http://www.garlic.com/~lynn/2003h.html#8 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM http://www.garlic.com/~lynn/2003j.html#32 Language semantics wrt exploits http://www.garlic.com/~lynn/2003p.html#29 Sun researchers: Computers do bad math ;) http://www.garlic.com/~lynn/2004.html#14 Holee shit! 30 years ago! http://www.garlic.com/~lynn/2004c.html#21 PSW Sampling http://www.garlic.com/~lynn/2004g.html#42 command line switches [Re: [REALLY OT!] Overuse of symbolic constants] http://www.garlic.com/~lynn/2004k.html#31 capacity planning: art, science or magic? http://www.garlic.com/~lynn/2004m.html#22 Lock-free algorithms http://www.garlic.com/~lynn/2004n.html#55 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2004o.html#7 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2004o.html#10 Multi-processor timing issue http://www.garlic.com/~lynn/2004q.html#73 Athlon cache question http://www.garlic.com/~lynn/2004q.html#76 Athlon cache question http://www.garlic.com/~lynn/2005.html#4 Athlon cache question http://www.garlic.com/~lynn/2005d.html#1 Self restarting property of RTOS-How it works? http://www.garlic.com/~lynn/2005d.html#6 [Lit.] Buffer overruns http://www.garlic.com/~lynn/2005d.html#33 Thou shalt have no other gods before the ANSI C standard http://www.garlic.com/~lynn/2005d.html#41 Thou shalt have no other gods before the ANSI C standard http://www.garlic.com/~lynn/2005d.html#48 Secure design http://www.garlic.com/~lynn/2005h.html#1 Single System Image questions http://www.garlic.com/~lynn/2005h.html#15 Exceptions at basic block boundaries http://www.garlic.com/~lynn/2005j.html#12 Performance and Capacity Planning http://www.garlic.com/~lynn/2005j.html#62 More on garbage collection http://www.garlic.com/~lynn/2005k.html#17 More on garbage collection http://www.garlic.com/~lynn/2005m.html#28 IBM's mini computers--lack thereof http://www.garlic.com/~lynn/2005n.html#18 Code density and performance? http://www.garlic.com/~lynn/2005o.html#5 Code density and performance? http://www.garlic.com/~lynn/2005o.html#30 auto reIPL http://www.garlic.com/~lynn/2005o.html#34 Not enough parallelism in programming http://www.garlic.com/~lynn/2006b.html#15 {SPAM?} Re: Expanded Storage http://www.garlic.com/~lynn/2006b.html#17 {SPAM?} Re: Expanded Storage http://www.garlic.com/~lynn/2006b.html#23 Seeking Info on XDS Sigma 7 APL http://www.garlic.com/~lynn/2006e.html#20 About TLB in lower-level caches http://www.garlic.com/~lynn/2006e.html#46 using 3390 mod-9s http://www.garlic.com/~lynn/2006f.html#22 A very basic question http://www.garlic.com/~lynn/2006f.html#30 A very basic question http://www.garlic.com/~lynn/2006g.html#34 The Pankian Metaphor http://www.garlic.com/~lynn/2006h.html#25 The Pankian Metaphor http://www.garlic.com/~lynn/2006i.html#37 virtual memory http://www.garlic.com/~lynn/2006j.html#18 virtual memory http://www.garlic.com/~lynn/2006j.html#22 virtual memory http://www.garlic.com/~lynn/2006j.html#24 virtual memory http://www.garlic.com/~lynn/2006l.html#3 virtual memory http://www.garlic.com/~lynn/2006l.html#11 virtual memory http://www.garlic.com/~lynn/2006o.html#23 Strobe equivalents http://www.garlic.com/~lynn/2006o.html#25 CPU usage for paging http://www.garlic.com/~lynn/2006o.html#26 Cache-Size vs Performance http://www.garlic.com/~lynn/2006r.html#12 Trying to design low level hard disk manipulation program http://www.garlic.com/~lynn/2006s.html#24 Curiousity: CPU % for COBOL program http://www.garlic.com/~lynn/2006t.html#28 Why these original FORTRAN quirks? http://www.garlic.com/~lynn/2006x.html#1 IBM sues maker of Intel-based Mainframe clones http://www.garlic.com/~lynn/2006x.html#16 The Future of CPUs: What's After Multi-Core? http://www.garlic.com/~lynn/2007g.html#31 Wylbur and Paging http://www.garlic.com/~lynn/2007k.html#65 Non-Standard Mainframe Language? http://www.garlic.com/~lynn/2007m.html#55 Capacity and Relational Database http://www.garlic.com/~lynn/2007o.html#53 Virtual Storage implementation http://www.garlic.com/~lynn/2007o.html#57 ACP/TPF http://www.garlic.com/~lynn/2007r.html#68 High order bit in 31/24 bit address http://www.garlic.com/~lynn/2007s.html#41 Age of IBM VM http://www.garlic.com/~lynn/2007u.html#21 Distributed Computing http://www.garlic.com/~lynn/2008c.html#24 Job ad for z/OS systems programmer trainee http://www.garlic.com/~lynn/2008c.html#78 CPU time differences for the same job http://www.garlic.com/~lynn/2008d.html#35 Interesting Mainframe Article: 5 Myths Exposed http://www.garlic.com/~lynn/2008e.html#16 Kernels http://www.garlic.com/~lynn/2008f.html#36 Object-relational impedence http://www.garlic.com/~lynn/2008l.html#81 Intel: an expensive many-core future is ahead of us http://www.garlic.com/~lynn/2008m.html#42 APL http://www.garlic.com/~lynn/2008m.html#69 Speculation ONLY http://www.garlic.com/~lynn/2008p.html#41 Automation is still not accepted to streamline the business processes... why organizations are not accepting newer technologies? http://www.garlic.com/~lynn/2008q.html#65 APL http://www.garlic.com/~lynn/2009d.html#5 Why do IBMers think disks are 'Direct Access'? http://www.garlic.com/~lynn/2009h.html#76 A Math Geek's Plan to Save Wall Street's Soul http://www.garlic.com/~lynn/2009l.html#43 SNA: conflicting opinions http://www.garlic.com/~lynn/2009r.html#17 How to reduce the overall monthly cost on a System z environment? http://www.garlic.com/~lynn/2010d.html#62 LPARs: More or Less? http://www.garlic.com/~lynn/2010j.html#48 Knuth Got It Wrong -- 42yrs virtualization experience (since Jan68), 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
