2017-11-14 10:32 GMT+09:00 Andres Freund <andres@anarazel.de>:
> On 2017-11-13 20:21:47 -0500, Tom Lane wrote:
>> Kohei KaiGai <kaigai@heterodb.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 ...
>
Yes. I don't think PostgreSQL will perform massive calculation intensive
workloads by itself. (If people want, we have PL/CUDA to run advanced
algorithms in UDF, as an aside.)
However, data management is a top priority job for DBMS, and storage
density directly affects to the performance to load data stream onto
multicore processors (like GPUs).
My proposition intends to reduce storage/memory consumption when
user stores massive amount of floating point arrays database.
Thanks,
--
HeteroDB, Inc / The PG-Strom Project
KaiGai Kohei <kaigai@heterodb.com>
