On Sunday, 8 December 2013 at 18:53:07 UTC, Walter Bright wrote:
On 12/8/2013 2:13 AM, Araq wrote:
From this list only (7) is a valid point. All the others can
be trivially dealt
with whole program optimization (1,2,3)
If it's trivial, it's not happening. (1) would require solving
the halting problem.
Well ok when I say "easy" or "trivial" it doesn't mean anything
;-).
(1) doesn't require solving the halting problem at all though.
For optimizations all you need to do is to come up with an
analysis that approximates the runtime behaviour in a
conservative approach. ("When in doubt, assume it modifies this
location.")
(2) is impractical because there's no way for the programmer to
detect if his call stack is pure or not, so he can't reasonably
fix it to make it pure.
Well look at the subject: "inherent" vs "practical".
(3) does require whole program analysis, which is done (as I
said) by the linker, and is not normally done. Will gcc/ld do
it? Nope. (It's not so trivial.)
Both GCC and LLVM can perform link time optimizations.
or coding conventions (4,5,6) (always
pass a (char*, len) pair around for efficient slicing).
(4) just try retrofitting an existing C program to do this. I
have. You'll give it up soon :-)
Again -- the subject is "inherent code performance advantages".
The average C program full of "if (errcode) goto errorHandler" is
irrelevant to this discussion. BTW I would indeed add "D has
exceptions" to your list.
(5) it just doesn't happen in C code - it's too hard
(6) I pretty much never see this happening in real C code -
it's not so trivial
Interestingly, things
that are encouraged in Ada (this is an array of integers of
range 0..30, see
value range propagation) are much harder to recompute with
whole program
optimization and D lacks them.
You can do these in D with a library type.
And get the same (theoretical) advantages for optimizations?
Perhaps.
