Re: FP16 Support?
От | Kohei KaiGai |
---|---|
Тема | Re: FP16 Support? |
Дата | |
Msg-id | CAOP8fzbnwTomM2q3GC05+y0PQgHqBnOQfJD-Pa82rzqmr18B5A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: FP16 Support? (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
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>
В списке pgsql-hackers по дате отправления: