On Monday, 4 August 2014 at 00:34:30 UTC, Andrei Alexandrescu
wrote:
On 8/3/14, 4:51 PM, Mike Farnsworth wrote:
This all seems to have a very simple solution, to use
something like:
expect()
GCC for example has an intrinsic, __builtin_expect() that is
used to
notify the compiler of a data constraint it can use in
optimization for
branches. Why not make something like this a first-class
citizen in D
(and even expand the concept to more than just branch
prediction)?
__builtin_expect is actually not that. It still generates code
when the expression is false. It simply uses the static
assumption to minimize jumps and maximize straight execution
for the true case. -- Andrei
Yes, that's why I pointed out expanding it to actually throw an
exception when the expectation isn't meant. I guess that's
really more like assume() that has been mentioned?
At EA we used two versions of an assertion: assert() which
compiled out in non-debug builds, etc; and verify() that was kept
in non-debug builds but just boiled back down to the condition.
The latter was when we relied on the side-effects of the logic
(used the condition in a real runtime branch), but really we
wanted to know if it ever took the else so to speak as that was
an error we never wanted to ship with.
FFIW, at my current job, in C++ we use assert() that compiles out
for final builds (very performance-driven code, so even the
conditions tested have to scat), and we also have likely() and
unlikely() macros that take advantage of __builtin_expect().
There are only a few places where we do both, where the assertion
may be violated and we still want to recover nicely from it, but
still don't want the performance suck of the else case code
polluting the instruction cache.
