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

Reply via email to