Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #2201

Re: Optimization techniques

Show all headers | View raw

On 19/04/2019 17:48, Rick C. Hodgin wrote:
> 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.
>

No, it is not.  In C, there is the concept of "sequence points".  This
has got more complicated in C11 with the handling of multiple threads,
but in C99 (and single-threaded C11) these are points which define the
order of operations.  (Just the logical order - the actual generated
code order can vary, according to the "as if" rule.)

But between sequence points, operations can be carried out in any order
that suits the compiler.  Given "x = A + B;", the expressions "A" and
"B" can be evaluated in any order.

If you have this code:

int x = 0;
int nextX(void) {
	x++;
	return x;
}

void foo(void) {
	printf("%i, %i, %i\n", nextX(), nextX(), nextX());
}

then the compile can give "1, 2, 3", or "3, 2, 1", or (less likely, but
legal) other orders such as "1, 3, 2".

(C++ has recently fixed the ordering of evaluation of function
arguments, but that does not apply to C.  And it does not apply to other
orderings between sequence points.)

Of course, a language following the same basic principles as C could
simply say that the comma between arguments in a function call act as
sequence points - then their evaluation order will be fixed.


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

You'd be surprised - many who take floating point seriously are looking
for absolutely repeatable results, consistent across different systems.
 There is a difference between knowing the results are not perfect
matches for mathematical "real" numbers, and wanting the floating point
calculations to follow the IEEE rules precisely.  People do take care to
write "a + (b + c)" or "(a + b) + c" because they know that one version
gives more precision in their results.  Compilers can't (usually) get
that same knowledge - they have to trust the programmer.

(Or you can have a "fast fp mode" which allows freer optimisation and
re-arrangements.)

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

Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Optimization techniques "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-17 09:42 -0400
  Re: Optimization techniques Hans Aberg <haberg-news@telia.com> - 2019-04-17 18:11 +0200
  Re: Optimization techniques George Neuner <gneuner2@comcast.net> - 2019-04-18 04:07 -0400
    Re: Optimization techniques "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-18 11:22 -0400
      Re: Optimization techniques George Neuner <gneuner2@comcast.net> - 2019-04-19 15:48 -0400
    Re: Optimization techniques Hans Aberg <haberg-news@telia.com> - 2019-04-19 00:52 +0200
  Re: Optimization techniques Kaz Kylheku <847-115-0292@kylheku.com> - 2019-04-19 08:49 +0000
    Re: Optimization techniques "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-19 11:48 -0400
      Re: Optimization techniques David Brown <david.brown@hesbynett.no> - 2019-04-23 09:38 +0200
    Re: Optimization techniques David Brown <david.brown@hesbynett.no> - 2019-04-23 09:18 +0200
  Re: Optimization techniques Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2019-04-20 00:27 +0200
    Re: Optimization techniques "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-19 16:11 -0700
      Re: Optimization techniques Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2019-04-20 19:47 +0200
        Re: Optimization techniques "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-24 10:16 -0400
    Re: Optimization techniques George Neuner <gneuner2@comcast.net> - 2019-04-20 18:59 -0400
    Re: Optimization techniques David Brown <david.brown@hesbynett.no> - 2019-04-23 09:43 +0200
      Re: Optimization techniques Martin Ward <martin@gkc.org.uk> - 2019-04-26 20:10 +0100
        Re: Optimization techniques Kaz Kylheku <847-115-0292@kylheku.com> - 2019-04-26 21:11 +0000
        Re: Optimization techniques David Brown <david.brown@hesbynett.no> - 2019-04-28 17:22 +0200
          Re: Optimization techniques Gene Wirchenko <genew@telus.net> - 2019-04-30 18:07 -0700
            Re: Optimization techniques David Brown <david.brown@hesbynett.no> - 2019-05-01 09:03 +0200
    Re: Optimization techniques "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2019-04-26 13:39 +0100
  Re: Optimization techniques rockbrentwood@gmail.com - 2019-09-26 20:35 -0700

csiph-web