Re: Re: Adding IEEE 754:2008 decimal floating point and hardware support for it

On 20 June 2013 06:45, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:

> I think a good starting point would be to use the Intel and IBM
> libraries to implement basic DECIMAL32/64/128 to see if they perform
> better than the gcc builtins tested by Pavel by adapting his extension.
>

Just a few notes:

Not sure if this has already been mentioned, but GCC is using the IBM
decNumber library to implement those built-ins so the performance should be
nearly identical.

Unfortunately, many GCC builds shipped by Linux distributions don't
actually seem to have those built-ins configured anyway!

Also, the IBM 'xlc' compiler supports those built-ins (IBM being behind all
of this stuff...), and generates code using hardware instructions for
POWER6/POWER7, or software otherwise (quite possibly the same code again).

One further (undeveloped) thought: the IBM decNumber library doesn't just
support the 754-2008 types, it also supports a more general decNumber type
with arbitrary precision (well, up to 999,999,999 significant figures), so
if it were to finish up being used by core PG then it could also have other
uses. I have no idea how decNumber (which encodes significant figures in
an integer coefficient, so one decimal digit per 3.2(?) bits) compares to
PG's DECIMAL (which encodes each digit in 4 bits, BCD style), in terms of
arithmetic performance and other trade-offs.

> If the performance isn't interesting it may still be worth adding for
> compliance reasons, but if we can only add IEEE-compliant decimal FP by
> using non-SQL-standard type names I don't think that's super useful. If
> there are significant performance/space gains to be had, we could
> consider introducing DECIMAL32/64/128 types with the same names used by
> DB2, so people could explicitly choose to use them where appropriate.

+1 for using the DB2 names.

I am interested in this topic as a user of both Postgres and DB2, and an
"early adopter" of 754-2008 in various software. Actually I had started
working on my own DECFLOAT types for Postgres using decNumber in 2010 as I
mentioned on one of the lists, but life got in the way. I had a very basic
extension sort of working though, and core support didn't seem necessary,
although I hadn't started on what I considered to be the difficult bit,
interactions with the other numerical types (ie deciding which conversions
and promotions would make sense and be safe).

Finally, I recently ran into a 3rd software implementation of 754-2008:
libmpdec (the other two being IBM decNumber and Intel's library), but I
haven't looked into it yet.

Thomas Munro