From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Kohei KaiGai <kaigai(at)heterodb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: FP16 Support? |
Date: | 2017-11-14 01:32:30 |
Message-ID: | 20171114013230.lxpocndolfvyfnvh@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2017-11-13 20:21:47 -0500, Tom Lane wrote:
> Kohei KaiGai <kaigai(at)heterodb(dot)com> writes:
> > How about your thought for support of half-precision floating point,
> > FP16 in short?
>
> This sounds like a whole lotta work for little if any gain. There's not
> going to be any useful performance gain from using half-width floats
> except in an environment where it's the individual FLOPs that dominate
> your costs. PG is not designed for that sort of high-throughput
> number-crunching, and it's not likely to get there anytime soon.
>
> When we can show real workloads where float32 ops are actually the
> dominant time sink, it would be appropriate to think about whether
> float16 is a useful solution. I don't deny that we could get there
> someday, but I think putting in float16 now would be a fine example
> of having your priorities reversed.
Agree that there's no performance argument. I think you could kinda
sorta make an argument for higher storage density in cases where a lot
of floats are stored in the database. I'd personally still consider
that not worthwhile to invest time in, but ...
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2017-11-14 01:33:30 | Re: FP16 Support? |
Previous Message | Tom Lane | 2017-11-14 01:21:47 | Re: FP16 Support? |