Re: Optimization techniques

Kaz Kylheku <847-115-0292@kylheku.com>
Fri, 19 Apr 2019 08:49:11 +0000 (UTC)

          From comp.compilers

Related articles
Optimization techniques rick.c.hodgin@gmail.com (Rick C. Hodgin) (2019-04-17)
Re: Optimization techniques haberg-news@telia.com (Hans Aberg) (2019-04-17)
Re: Optimization techniques gneuner2@comcast.net (George Neuner) (2019-04-18)
Re: Optimization techniques rick.c.hodgin@gmail.com (Rick C. Hodgin) (2019-04-18)
Re: Optimization techniques haberg-news@telia.com (Hans Aberg) (2019-04-19)
Re: Optimization techniques 847-115-0292@kylheku.com (Kaz Kylheku) (2019-04-19)
Re: Optimization techniques rick.c.hodgin@gmail.com (Rick C. Hodgin) (2019-04-19)
Re: Optimization techniques gneuner2@comcast.net (George Neuner) (2019-04-19)
Re: Optimization techniques DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2019-04-20)
Re: Optimization techniques rick.c.hodgin@gmail.com (Rick C. Hodgin) (2019-04-19)
Re: Optimization techniques DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2019-04-20)
Re: Optimization techniques gneuner2@comcast.net (George Neuner) (2019-04-20)
[29 later articles]
| List of all articles for this month |

From: Kaz Kylheku <847-115-0292@kylheku.com>
Newsgroups: comp.compilers
Date: Fri, 19 Apr 2019 08:49:11 +0000 (UTC)
Organization: Aioe.org NNTP Server
References: 19-04-004
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="97882"; mail-complaints-to="abuse@iecc.com"
Keywords: optimize
Posted-Date: 19 Apr 2019 10:34:53 EDT

On 2019-04-17, R. C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> Are there resources someone can point me to for learning more about
> time-honored, long-established, safely applied, optimization
> techniques for a C/C++ like language?


Optimization only preserves the meaning of the program to the extent
that the program has a defined meaning, as far as the compiler is
concerned.


Thus, there is one huge pitfall in optimizing C or C++: there is a large
space of possible programs that have unspecified or undefined semantics,
and that programmers actually write.


If you can make your language "C/C++ like" without all the undefined
behavior looming at every corner (i.e. not actually "C/C++ like" at all
in a significant regard), then you've dodged what is probably the number one
optimization pitfall.


For instance, don't have it so that the order of evaluation of
function or operator arguments is unspecified. If you allow side-effects
in expressions, specify when those effects take place in relation to
everything else in the expression.


If you have clear ordering rules, then you honor them when optimizing:
you rearrange the user's calculation order only when it can't possibly
make a difference to the result that is required by the defined
order.


Reordering arithmetic calculations has pitfalls. There are n! orders
for adding together n numbers. Under floating-point, these all
potentially return different results even if nothing overflows.
You can't blindly rely on arithmetic identities to hold.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.