guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU Guile branch, wip-peval-predicates, created. v2.0.5-100-g59c5570


From: David Kastrup
Subject: Re: GNU Guile branch, wip-peval-predicates, created. v2.0.5-100-g59c5570
Date: Sun, 15 Apr 2012 09:53:29 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

Andy Wingo <address@hidden> writes:

> But OK, the question here is, what if another thread is concurrently
> mutating X and Y?  If this were C++ or Java, the answer would be that
> they can still fold, because access to a multithreaded mutable needs
> to be synchronized.  I think this is reasonable.  What do you think?

You don't even need multithreading for undefined effects of sequence
ordering in C/C++.

  i = i++;

is already undefined.  Scheme has several non-guarantees regarding
execution order as well (like the order in which function arguments will
get evaluated).

History time: Fortran specifies that if array arguments to a function do
not point to distinct objects, the results are undefined.  C passes
arrays (actually, vectors) using pointers, and a pointer is a memory
reference that can point anywhere in an array, and there are no
restrictions about the same-object relations (whether at the same
address or with an offset) of several arguments: the behavior is
well-defined either way.

The C99 standard or whatever it was allows passing multidimensional
arrays to functions.  In addition, you can use the "restrict" pointer
syntax (total hell to use, by the way) to tell the compiler that a
pointer argument to a function is not in an aliasing relation to other
pointers accessible to the function.

As a result, it has now become theoretically possible to write C code
for multidimensional array manipulations that can be optimized as well
as naively written Fortran code from 1960.  In practice, however, it
turns out that both code writers as well as compiler writers are not
quite up to the task yet.

Lesson: make hard to find and optimize corner cases undefined behavior
if you don't want to make it almost impossible to write code that can be
optimized well.  The more assumptions an optimizer is allowed to make by
default, the better it can do its work.  _Without_ special help by the
programmer.  And if we wanted to rely on special help by the programmer,
it would be more straightforward if we let the programmer write the
assembly code rather than the compiler.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]