The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.comupters as well.
Howard Brazee <[EMAIL PROTECTED]> writes: > A lot of our smarts is in seeing patterns, simplifying what we are > looking for. Occasionally this kind of shortcut causes us to miss > things, but pattern recognition allows the chess master to ignore dead > ends that poorer players waste time on. > > I see craftsmen and artists using tools that are difficult to master - > but supply and demand doesn't take that into consideration in setting > prices for their goods. long post warning ... as an undergraduate ... i did fair share scheduler for cp67 ... or actually dynamic adaptive resource management ... with default policy being fair share; minor recent reference: http://www.garlic.com/~lynn/2007h.html#77 Linux: The Completely Fair Scheduler but also did a lot of highly optimized pathlength and fastpath stuff. I made joke about being able to do stuff in zero instruction ... carefully tweaking instructions all over the kernel so that various things happened implicitly ... so scheduler didn't actually have to execute instructions to obtain the desired results (secondary effects of the order of how other things are occruing, of course it helps if you effectively have memorized the source for the complete kernel). over some yrs, there was complaints that nobody could understand how it worked ... which probably contributed to a lot of being dropped (simplified) in the morph from cp67 to vm370. so possibly still part of the recovery in the aftermath of future system project ... recent reference in this thread http://www.garlic.com/~lynn/2007i.html#31 Latest Principles of Operation I was given the opportunity to reintroduce the resource manager for vm370. ... more topic drift ... and they decided that the resource manager should be guinea pig to starting to charge for kernel code ... so i had to spend some amount of time with the business and legal people working on policy for charging for kernel software; i.e. 23jun69 unbundling announcement started charging for application software ... but they used the excuse that kernel software was integral to hardware operation and should still be "free" ... misc. past posts http://www.garlic.com/~lynn/subtopic.html#unbundle ... slightly return to topic ... now, i did fix up some of the more obtuse pieces of code ... but there still was quite a bit of complexity in the resource manager ... and people over the yrs would complain that they didn't understand how it worked ... and periodically somebody would make changes in other parts of the kernel resulting in unexplicable affects on scheduling (there was still quite a bit of convoluted code that I justified on being able to do things in fewer instructions and shorter pathlength). so there was one fly in the oitment, somebody from corporate complained that there weren't any tuning parameters ... which was the state of the art in other products; ... namely the favorite son operating system of the period had a massive table of tuning parameters ... and there were this presentations at SHARE (could put everybody to sleep) about random walks across the tuning parameter table landscape, varying the parameters for all different kinds of workloads and configurations ... attempting to find settings that made some difference. So I was forced to put in some tuning parameters (before product ship), document them and the backup formulas ... as well as detailed code explanation. so we roll forward nearly 20yrs ... we are on a marketing swing thru the far east for our ha/cmp product http://www.garlic.com/~lynn/subtopic.html#hacmp also additional thread drift http://www.garlic.com/~lynn/95.html#13 http://www.garlic.com/~lynn/96.html#15 and http://www.garlic.com/~lynn/lhwemail.html#medusa ... and we are on a call at a large financial institution. One of the people at the meeting (relatively recent graduate) pipes up and asks if i'm the same person associated with the scheduler ... since they had studied me/it at the Univ. of Waterloo. So I respond politely and asked if the "joke" was discussed. Now part of the issue with static tuning parameters is that workloads tend to vary from minute-to-minute, day-to-day, week-to-week ... and there was a whole lot of work that went into the dynamic adaptive implementation to eliminate the requirement for any static tuning parameters. Being force to add static tuning parameters seemed to be a great step backward in the state-of-the-art. So as to the "joke" ... if dynamic adaptive can adjust for changes in configurations and workloads ... as well as a lot of other things ... why couldn't the dynamic adaptive implementation also adjust to compensate for changes in any static tuning parameters. misc. past posts discussing the resource manager "joke": http://www.garlic.com/~lynn/2001b.html#18 Linux IA-64 interrupts [was Re: Itanium benchmarks ...] http://www.garlic.com/~lynn/2001l.html#9 mainframe question http://www.garlic.com/~lynn/2002c.html#16 OS Workloads : Interactive etc http://www.garlic.com/~lynn/2002c.html#54 Swapper was Re: History of Login Names http://www.garlic.com/~lynn/2002i.html#53 wrt code first, document later http://www.garlic.com/~lynn/2004o.html#10 Multi-processor timing issue http://www.garlic.com/~lynn/2005p.html#31 z/VM performance http://www.garlic.com/~lynn/2006b.html#21 IBM 3090/VM Humor http://www.garlic.com/~lynn/2006h.html#22 The Pankian Metaphor http://www.garlic.com/~lynn/2006y.html#17 The Future of CPUs: What's After Multi-Core? http://www.garlic.com/~lynn/2007g.html#56 The Perfect Computer - 36 bits? ---------------------------------------------------------------------- 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
