And the nit on that would be "once loaded". Meaning "not everything in the load module on disk ends up in the loaded program in memory", or so I gather.
Others, who might actually KNOW something :-) , can take this one further. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: [email protected] Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: John McKown <[email protected]> To: [email protected] Date: 03/10/2014 12:49 Subject: Re: Enterprise COBOL v5.1 Implemented? Sent by: IBM Mainframe Discussion List <[email protected]> With one caveat, I agree. That caveat relates to the cache. If the optimizer leaves in too much in the way of "junk instructions", then the efficiency of the cache is decreased. So, IMO, I would argue that it is relevant for a compiler to minimize the number of bytes to perform an action. Especially an action which is in a loop. Now bowing out due to my admitted ignorance of more advanced hardware matters. On Fri, Oct 3, 2014 at 12:18 AM, Timothy Sipples <[email protected]> wrote: > >MOVE "BUBBA" to WS-DESC. > > How about this example instead: > > MOVE "Version 6.3.2. Copyright 2014 BUBBA Coders Inc. Licensed to GUMP > Inc." to WS-DESC. > > With the stipulation that this second example may not be brilliant, should > the optimizer remove that "unreachable" "watermarking" literal? > > Keep in mind also that optimizers have their own performance > characteristics to respect. If you're spending $10 to save $0.01, that's > (also) a waste of resources. Much like compression algorithms, optimizers > ought not do everything possible. They should only do what's "prudent," > "wise," and "reasonable" to do -- no more. There's also some non-zero risk > that if an optimizer takes low comparative reward action it could do so > improperly -- that there's an optimizer bug, in other words. Bugs can be > expensive, too. > > A new optimizer is about the present and future. Today's COBOL compiler is > no longer tasked with optimizing for System/370 machines. It's a fair > generalization that reducing compiled code size by X bytes is much, much > less important in 2014 than it was in 1982 where X is constant, ceteris > paribus. It's also a fair assumption that it will get even less important > over time. And you've also got to consider that everything gets rounded up > to 4 KB, 1 MB, or 2 GB page sizes anyway (and minimum storage block sizes, > relatedly) with the smaller page sizes progressively falling by the wayside > over time. Bytes as bytes "don't matter" to a first, second, and probably > third order approximation. (Maybe the optimizer only takes action if the > next page increment is approached, and then only enough to remain within > the lowest reasonably achievable page count but no more?) > > To net it out, for at least a few reasons I don't think this example > demonstrates that an optimizer isn't properly doing its job. In fact, if > the optimizer were *always* taking preemptive action here you might have > discovered a poor optimizer! The run-time world is nuanced, complicated, > and certainly not static. A sensible optimizer knows when *not* to take > action just as much as when, and this one might be such an example. > "Minimize the compiled code's memory footprint, in bytes" isn't actually a > sensible priority objective for a (modern) optimizer with the possible > exception of an optimizer targeting a comparatively memory constrained > environment, e.g. an embedded "smart card" processor. > > Maybe I'm too often the lonely voice constantly reminding IBM-MAINers that > we no longer live in a "kilobytes world," but it really is true. Yes, on > mainframes, too. These are good *instincts* to have -- performance and > scalability are achieved/achievable through efficiency, yes -- but one > shouldn't get too crazy about this stuff lest one lose the plot entirely. > The boundary between "crazy" and "not crazy" keeps shifting practically > every week -- yes, on mainframes, too -- and so should we. > > Yes, I think it's "crazy" that a typical downloaded smartphone application > occupies more flash storage than the capacity of the entire hard disk I > purchased in 1984 for US$699 -- a bargain! -- had. How wasteful! How > profligate! But it's 30 years later, and no, it really isn't, today. > > > -------------------------------------------------------------------------------------------------------- > Timothy Sipples > IT Architect Executive, zEnterprise Industry Solutions, AP/GCG/MEA > E-Mail: [email protected] > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
