Re: Current int & float overflow checking is slow.

On 2017-10-24 10:09:09 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > There's no comparable overflow handling to the above integer
> > intrinsics. But I think we can still do a lot better. Two very different
> > ways:
>
> > 1) Just give up on detecting overflows for floats. Generating inf in
> > these cases actually seems entirely reasonable. We already don't
> > detect them in a bunch of cases anyway. I can't quite parse the
> > standard's language around this.
>
> There's an ancient saying that code can be arbitrarily fast if it
> doesn't have to get the right answer. I think this proposal falls
> in that category.

Does it? In plenty of cases getting infinity rather than an error is
just about as useful.

This was argued by a certain Tom Lane a few years back ;)
http://archives.postgresql.org/message-id/19208.1167246902%40sss.pgh.pa.us

> > 2) Use platform specific float exception handling where available. We
> > could at backend start, and in FloatExceptionHandler(), us
> > feenableexcept() (windows has similar) to trigger SIGFPE on float
> > overflow.
>
> SIGFPE isn't going to be easy to recover from, nor portable.

Hm? A trivial hack implementing the above survives the regression test,
with the exception of one output change because some functions currently
do *not* check for overflow. What's the issue you're concerned about?

The portability indeed is a problem.

> I think what you actually want to do is *disable* SIGFPE (see
> feholdexcept), and then have individual functions use feclearexcept
> and fetestexcept. These functions were standardized by C99 so
> they should be pretty widely available ... of course, whether they
> actually are widely portable remains to be seen. Whether they're
> faster than what we're doing now also remains to be seen.

I tested it, and they're fairly slow on at least gcc-7 + glibc 2.24.

Greetings,

Andres Freund