Fri, 19 Apr 2019 08:49:11 +0000 (UTC)

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] |

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.