From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) by sourceware.org (Postfix) with ESMTPS id DBF2D385840A for ; Sat, 12 Feb 2022 23:46:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DBF2D385840A Received: by mail-pf1-x42a.google.com with SMTP id y5so22789248pfe.4 for ; Sat, 12 Feb 2022 15:46:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uvrqcwhyxxNq+s7bMY70CjtXE2mCJlUKbvUXU/A/3iY=; b=aQzEEacNCxmTc7fIfUQZS45sizFt0E9rHIdmayILFRLCt2gZCWNowFhXLrL6/IqYsX eCcnAOW/l3Sa7RLIwQUKAcoj9WlK74824kXFb7PhlgoR6ipW8k3gllc131zt0LqjQwXN mwP5zkMp68uoMHocEkdxjvGAPpGpNZf36cFCXSsLvrXnhWVWOMKjyGUdV3Lk8fHMav0k G9JDBQaqsU60zsUs9Y36t+LkivwZrDndgYQ6HFubrU8UYhNLYowsQfeDwTDmCc0r4Adi Zj9IOESll81C0KmxPqLdX+umGZwGZcOx40nDE7bOihv0hj3fYnd7RWdhZvpMQB6Oht70 5ZVw== X-Gm-Message-State: AOAM531BP2jG8hSjLjy5kiJoevOrQXxAQQSjHGdwU+VzojD1msYfIBm+ nUpuTbX9xk4b+qfFLB+K+SgVLUfur+S1zz4qHlKkP1m/ X-Google-Smtp-Source: ABdhPJyQvay064i8Hf8BSTJ2rP2uOmhY24Yr8DMQ4oNccD9oeLY1YS+lmzlDDOSMLwUTG3072HnAjSPvB1RSNwavfu4= X-Received: by 2002:aa7:824d:: with SMTP id e13mr4413961pfn.11.1644709617006; Sat, 12 Feb 2022 15:46:57 -0800 (PST) MIME-Version: 1.0 References: <20220208224319.40271-1-hjl.tools@gmail.com> <1f75bda3-9e89-6860-a042-ef0406b072c1@linaro.org> <78cdba88-9e00-798a-846b-f0f77559bfd5@gmail.com> <0efdd4fe-4e35-cf1d-5731-13ed1c046cc6@oracle.com> <1ea64f9f-6ce8-5409-8b56-02f7481526d9@linaro.org> In-Reply-To: <1ea64f9f-6ce8-5409-8b56-02f7481526d9@linaro.org> From: Noah Goldstein Date: Sat, 12 Feb 2022 17:46:46 -0600 Message-ID: Subject: Re: [PATCH v2] x86-64: Optimize bzero To: Adhemerval Zanella Cc: Patrick McGehearty , GNU C Library Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2022 23:46:59 -0000 On Fri, Feb 11, 2022 at 7:01 AM Adhemerval Zanella via Libc-alpha wrote: > > > > On 10/02/2022 18:07, Patrick McGehearty via Libc-alpha wrote: > > Just as another point of information, Solaris libc implemented > > bzero as moving arguments around appropriately then jumping to > > memset. Noone noticed enough to file a complaint. Of course, > > short fixed-length bzero was handled with in line stores of zero > > by the compiler. For long vector bzeroing, the overhead was > > negligible. > > > > When certain Sparc hardware implementations provided faster methods > > for zeroing a cache line at a time on cache line boundaries, > > memset added a single test for zero ifandonlyif the length of code > > to memset was over a threshold that seemed likely to make it > > worthwhile to use the faster method. The principal advantage > > of the fast zeroing operation is that it did not require data > > to move from memory to cache before writing zeros to memory, > > protecting cache locality in the face of large block zeroing. > > I was responsible for much of that optimization effort. > > Whether that optimization was really worth it is open for debate > > for a variety of reasons that I won't go into just now. > > Afaik this is pretty much what optimized memset implementations > does, if architecture allows it. For instance, aarch64 uses > 'dc zva' for sizes larger than 256 and powerpc uses dcbz with a > similar strategy. > > > > > Apps still used bzero or memset(target,zero,length) according to > > their preferences, but the code was unified under memset. > > > > I am inclined to agree with keeping bzero in the API for > > compatibility with old code/old binaries/old programmers. :-) > > The main driver to remove the bzero internal implementation is just > the *currently* gcc just do not generate bzero calls as default > (I couldn't find a single binary that calls bzero in my system). Does it make sense then to add '__memsetzero' so that we can have a function optimized for setting zero? > > So to actually see any performance advantage from the optimized > bzero, we will need to reevaluate the gcc optimization to transform > it on memset (which will need to be applied per-architecture base) > which I seem highly unlikely gcc maintainer will accept it. > > Some time ago LLVM tried to do something similar to bcmp, but in the > end it was not a good idea to use an already define symbol and it > ended up with __memcmp_eq instead. > > > > > Using shared memset code for the implementation of bzero > > is worthwhile for reducing future maintenance costs. > > > > - Patrick McGehearty > > former Sparc/Solaris performance tuning person > > > > > > > > On 2/10/2022 2:42 PM, Adhemerval Zanella via Libc-alpha wrote: > >> > >> On 10/02/2022 17:27, Alejandro Colomar (man-pages) wrote: > >>>> We are discussing different subjects here: what I want is to remove the > >>>> glibc *internal* optimization for bzero, which is essentially an > >>>> implementation detail. In a first glance it would change performance, > >>>> however gcc does a hard job replacing bzero/bcmp/bcopy with their > >>>> str* counterparts, so it highly unlike that newer binaries will actually > >>>> call bzero. > >>> Okay, then yes, go ahead and remove bzero(3) from glibc if GCC will > >>> continue supporting it. Just remember that some users keep writing and > >>> wanting to write bzero(3) instead of memset(3) in their .c files, so > >>> it's far from being dead in source code. > >> Again, I am not proposing to *remove* bzero, but rather the internal > >> optimizations that currently only adds code complexity and maintenance > >> burden. My patchset [1] will keep the ABI as-is, the difference is > >> bcopy and bzero will use the default implementation on all architectures. > >> > >> [1] https://patchwork.sourceware.org/project/glibc/list/?series=7243 > >