Gabriel Sechan wrote:
From: Andrew Lentvorski <[EMAIL PROTECTED]>
I wish language designers would just finally get it through their
heads that int's should have infinite precision and floating point
numbers should be *decimal* floating point instead of *binary*
floating point.
It would save *so* much time and trouble.
Disagree completely. I refuse to pay the performance hit to check for
overflow and deal with it. Its a corner case that happens in less than
.1% of additions, probably an order of magnitude less. Not owrth
optimizing for. For the infrequentness that any program needs to deal
with this, you'd save all the debugging time it required in the past 60
years in one minute of all the computer users in the world waiting due
to the overhead.
Horse-hockey. Both to the frequency of the bug and the time required to
check.
First, frequency of bug: Overflow/underflow has been a source of
constant frustration for security people. The main C libraries have
constantly been fighting this kind of stuff. It may be a corner case,
but it is an *important* corner case and has lots of repercussions. Why
pay the price at all when there is a perfectly good alternative?
Second, performance: Modern CPU's are superscalar, out-of-order
machines--they spend their time *waiting*. All of the data to do the
check is completely local. If you tag integers with upper bits of 0's
(what almost every boxed type language does), then addition is still
just addition (no performance hit) and the check looks at the upper bits
(which should be 0's) with and/compare. With speculative execution and
branch prediction, that will blow right past the comparison 99.999% of
the time and still get stuck on the next memory fetch.
Third, performance: The amount of code that would notice this would be
*extremely* small. You would have to be sitting in hard-core integer
numerics code; that's *very* rare code nowadays. The only applications
for that anymore are CAD systems.
As a side note, even MP3 compression/decompression (and other
DCT/Wavelet schemes) doesn't like silent overflow. It needs saturating
arithmetic and so pays the comparison penalty anyhow.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
