Software > User Zone
Void Linux thread
madscientist159:
--- Quote from: q66 on December 10, 2019, 04:32:37 pm ---Currently attempting a 64-bit long double transition to get rid of the messy IBM double-double format used on most distros and unify the representation across targets. Musl has been using it all along, now trying glibc.
I don't want to go with the 128-bit IEEE754 format as that requires VSX and would mean a different one on ppc64le and the rest (and also, when not targeting POWER9, it means basically reverting to soft-float).
--- End quote ---
What kind of performance loss are we looking at though on POWER9 vs. 128-bit IEEE754?
q66:
--- Quote from: madscientist159 on December 10, 2019, 06:22:45 pm ---
--- Quote from: q66 on December 10, 2019, 04:32:37 pm ---Currently attempting a 64-bit long double transition to get rid of the messy IBM double-double format used on most distros and unify the representation across targets. Musl has been using it all along, now trying glibc.
I don't want to go with the 128-bit IEEE754 format as that requires VSX and would mean a different one on ppc64le and the rest (and also, when not targeting POWER9, it means basically reverting to soft-float).
--- End quote ---
What kind of performance loss are we looking at though on POWER9 vs. 128-bit IEEE754?
--- End quote ---
If you mean performance loss with 64-bit ldbl vs 128-bit IEEE754, 64-bit should be faster, because Void is compiled for POWER8 like other distros and therefore can't use POWER9 isns (other than in glibc math functions, which can be chosen at runtime). The actual difference, don't know, I haven't benchmarked it (and won't, as that would mean compiling a set of packages for that).
I kind of don't want to use the 128-bit stuff for long double type in principle, as the hard VSX requirement is there either way (gcc will not compile it without -mcpu set to at least power7) and I'd kind of like the little endian and big endian targets differ mostly in just endianness and baseline -mcpu setting.
I never liked the long double type anyway, as the guarantees you get with it are zero (it's only required to be at least as big/precise as double and that's it). So going with a 64-bit baseline that's covered well in hardware everywhere seems like the sane choice (plus musl won't be adopting 128bit IEEE754 as it would require introduction of a new subarch because musl doesn't version symbols - so that would make glibc little endian the *only* outlier).
People who want 128-bit IEEE754 floating point can easily use the __float128 type in gcc. That is a much better option as it has guaranteed properties (similarly, it works on modern x86 with at least 128-bit wide SIMD as well). People who want the IBM 128bit floating point can also use the __ibm128 type in gcc in a similar manner.
Adopting 64-bit long double in glibc is actually pretty easy right now - because it used to use it in the past (before IBM made them change the default to the silly 128-bit double-double). Therefore, all the compatibility symbols as well as redirects for when you use -mlong-double-64 are set up in glibc, and all it takes is recompiling libraries and programs that use 128-bit IBM long double. You can easily tell which do - they will be tagged like Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double in the ELF attributes. This tag is only introduced when long doubles are used in the binary and it was compiled with those set to 128-bit IBM format.
So, I just went and checked every package containing ELF files for the tag, and compiled a list. It's a relatively small number, only about 330 packages out of 8000+. The rest of them can be left alone.
q66:
After some experimentation, I came to the conclusion that it is currently not practical to switch, as while things will mostly work, using compat symbols ultimately means that some configurations will break; in this case, things that manually declare stuff like math symbol prototypes (which is allowed) for long double math funcs will still use the ibm128 symbols and silently have wrong results... while this is rare, it is a concern.
I searched for potential workarounds but they mostly just introduced new issues elsewhere...
I'll wait until glibc has ironed out its IEEE754 128-bit support and some other distros have switched to it (i know Fedora is planning that) and then I'll reevaluate my options (e.g. possibly see if I could get in a 64-bit ldbl ABI *without* falling back to compat symbols, which would generally solve everything, besides compatibility with ibm128 and glibc is going to need to handle that for the ieee754 transition anyway). Since transition has proved to be less of a problem than expected by itself, it should be relatively easily doable later on.
So, sticking with what I have for now.
q66:
New packages batch; bringing out-of-box support for the Navi GPUs in the 5.4 kernel, further BE expansion, and other cool stuff 8)
q66:
We're now complete (as in the whole repo is built and everything not buildable is properly marked as such) on ppc64le and ppc64le-musl \o/
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version