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
Ответ на
Список
Дерево обсуждения
[HACKERS] Current int & float overflow checking is slow. Andres Freund <andres@anarazel.de>
Re: [HACKERS] Current int & float overflow checking is slow. Andres Freund <andres@anarazel.de>
Re: [HACKERS] Current int & float overflow checking is slow. Robert Haas <robertmhaas@gmail.com>
Re: [HACKERS] Current int & float overflow checking is slow. Andres Freund <andres@anarazel.de>
Re: [HACKERS] Current int & float overflow checking is slow. Robert Haas <robertmhaas@gmail.com>
Re: [HACKERS] Current int & float overflow checking is slow. ilmari@ilmari.org (Dagfinn Ilmari Mannsåker)
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. Andres Freund <andres@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. Robert Haas <robertmhaas@gmail.com>
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. Andres Freund <andres@anarazel.de>
Re: [HACKERS] Current int & float overflow checking is slow. Robert Haas <robertmhaas@gmail.com>
Re: [HACKERS] Current int & float overflow checking is slow. Andres Freund <andres@anarazel.de>
Re: [HACKERS] Current int & float overflow checking is slow. Greg Stark <stark@mit.edu>
On 2017-10-24 10:09:09 -0400, Tom Lane wrote:
> Andres Freund  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
Дата:
От: Tom Lane
Дата:
FAQ