On 01.03.2020 22:36, Joerg Sonnenberger wrote: > On Sun, Mar 01, 2020 at 10:20:44PM +0100, Kamil Rytarowski wrote: >> If that will nor realize, I will request to enable GNU_HASH for NetBSD-11. > > You have so far demonstrated no justification at all beyond handwaving > for why it should be included in first place. Seriously, stop rushing > code without doing your homework to demonstrate that it is (1) correct > (2) an actual improvement (3) understanding concerns raised in the past. > I have limited ressources and having to deal with crap like the > max_align_t commit just costs a lot of time for no good reason. > (1) As it was tested locally and capable to use in the following benchmark it works. Feel free to double check, catch potential bugs in the DT_GNU_HASH implementation inside RTLD and correct them. (2) I linked to benchmarks in my commit message. I have reproduced the ~50% performance boost claim here: http://netbsd.org/~kamil/ld/DT_HASH-DT_GNU_HASH-benchmark-2020-03-02.txt Feel free to tune the benchmark for other scenarios and write your own tests. (3) DT_HASH is generally considered as too slow with raised requirements on dynamically linked libraries over the past 15 years. >> GNU_HASH is industry standard for all modern Linux and any other >> mainstream BSD distribution already for around a decade. > > If you want an industry standard, please use the GNU/Linux distribution > of your choice. Arguing based on industry standards is a non sequitur. > Our current LD and RTLD feature set matrix is at best said.. conservative in the context of all other BSDs and Linux (possibly Solaris) and undemanding in performance. If NetBSD wants to be relevant for development of heavy C/C++ code, it must not be worse compared to alternatives. I'm working on getting us on and get NetBSD on par with industry standard toolchain support (and LLVM lld here). > Joerg > So. Unless there will be a viable alternative materialized as DT_NETBSD_HASH, I will flip DT_GNU_HASH on in NetBSD-11. If we cannot make nice things on our own locally, we shall rely on 3rd party industry standards.
Attachment:
signature.asc
Description: OpenPGP digital signature