Re: Optimization techniques

"Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Fri, 19 Apr 2019 11:48:52 -0400

          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)
Re: Optimization techniques david.brown@hesbynett.no (David Brown) (2019-04-23)
[27 later articles]
| List of all articles for this month |

From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Newsgroups: comp.compilers
Date: Fri, 19 Apr 2019 11:48:52 -0400
Organization: Liberty Software Foundation
References: 19-04-004 19-04-009
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="24525"; mail-complaints-to="abuse@iecc.com"
Keywords: optimize, design
Posted-Date: 19 Apr 2019 11:53:32 EDT
Content-Language: en-US

On 4/19/2019 4:49 AM, Kaz Kylheku wrote:
> 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.


I think UB is unavoidable in any C/C++ language. It is too low-level
for speed purposes to be bogged down with things that would prevent UB.
Even something simple like pointer use after free. It can be difficult
to catch statically.


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


I do have very clear ordering rules. I'm actually surprised to learn
that other systems do not. I would've thought it would be absolutely
essential.


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


I think people who use floating point recognize it is not an exact
numbering system.


I have introduced native support for arbitrary precision integers
(bi) and floating point (bfp) to address this, but even then it's
still limited precision and not exact.


--
Rick C. Hodgin


Post a followup to this message

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