Re: "Shared" procedure division code

"William M. Klein" <wmklein@xxxxxxxxxxxxxxxxx> wrote in message
news:T9ADe.499087$3V6.422305@xxxxxxxxxxxxxxxxxxxxxxxxx
> As a follow up on another thread ....
>
> It seems to me that the most common place where I *used* to see the same
> source code (paragraph/section) repeated within a single program was in
> OLDER (IBM) CICS code where "locality of code" was an issue. That was
> that it was important that the application not need to "page in and out"
> sections of machine code depending upon application logic flow. Although
> this is still a MINOR consideration in that (and possibly other)
> environments, I don't know where it happens with NEW code today.

With regard to "new code" (and not nescessarily just COBOL, but for
programming in genenral), the advice I typically hear is don't try to
outsmart the compiler. Rather, one should write their code in such a way as
to make it as easy to understand as possible so that the compiler itself can
figure out what you're trying to do, and optimize appropriately (of course,
this assumes you're programming in some language for which code analysis is
easier ;)).

A lot of people who claim to optimize don't bother to actually profile
their code to find out what parts of the program are running slowly, or even
whether or not their "optimizations" haven't actually made the program run
MORE slowly.

If it turns out you ARE smarter than the compiler, you should contribute
your ideas to the compiler developers (this is easier if you're using an
open source compiler), so that you can then write your code clearly, and
still have it perform just as fast as had you optimized it directly.

The only situations I can think of where it might be desirable to do
manual optimizations is for environments where the compilers haven't matured
enough to actually accept optimization contributions even if you had them
(e.g. compilers for cell phone, or "smart refrigerators", and things that
have only recently become programmable).

- Oliver


.

Relevant Pages

  • Re: WaitForSingleObject() will not deadlock
    ... One is to hijack the semantics of volatile to disable compiler optimizations ... and otherwise let the compiler to agressive optimization. ... Agressive optimizations are the ones that work on the edge of the semantics of the ... Because the compiler can see into lock and unlock, it is able to reduce f ...
    (microsoft.public.vc.mfc)
  • Re: WaitForSingleObject() will not deadlock
    ... represent an incorrect implementation of the language. ... the *compiler* does not guarantee this. ... but to state it in terms of the execution instead of the formal semantics of the language ... as long as the optimizations do not change the semantics of the language). ...
    (microsoft.public.vc.mfc)
  • Re: optimized code
    ... > loop invariants are handled by the JIT not by the compiler fron-ends. ... generates the best optimized MSIL of any of the .NET languages. ... standard native code optimizations on MSIL code. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: c compilation - gcc vs visual c
    ... I recently compiled a numerically intensive c project under cygwin gcc ... MS focuses a lot more on specific optimizations, ... the simplest approach, however (and the one I currently use in my compiler), ... (silly code), are ones I focus on fixing. ...
    (comp.lang.c)
  • Re: Migrating ARM9E codebase to ARM11
    ... > optimizations done using hand-coding, only the control code is left to ... You should then consider upgrading to a newer compiler. ... wish to target might be faster than the assembler optimised for the 9E. ... I do not believe that the ARM ARM for architecture version 6 has been ...
    (comp.sys.arm)