Re: [HACKERS] Current int & float overflow checking is slow.

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: [HACKERS] Current int & float overflow checking is slow.
Дата
Msg-id 20171024141721.45msqb64hhcg3cp5@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: [HACKERS] Current int & float overflow checking is slow.  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Current int & float overflow checking is slow.  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 2017-10-24 10:09:09 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Gaddam Sai Ram
Дата:
Сообщение: [HACKERS] CurTransactionContext freed before transaction COMMIT ???
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] CurTransactionContext freed before transaction COMMIT ???