From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) by sourceware.org (Postfix) with ESMTPS id C45003858D1E for ; Thu, 10 Feb 2022 20:27:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C45003858D1E Received: by mail-wr1-x434.google.com with SMTP id w11so11625244wra.4 for ; Thu, 10 Feb 2022 12:27:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=pravrDDXt1L5xjT18GlCyLY+xD648rN9JSnYwnDddB8=; b=ewB5KC184StCSYUQsopSFzERH8pj3mcOc2sFwhGoNZJ4pfkVwC7kh3HLvr3kBD7g28 W4AcR+LxZEwyIRli2DxjoSUOFQhoNhLbg8EuBWg4i/+XSOoojCZkojyK/pgctgRedTSf 0ijEpZVeMVcNgajfkNMIrfyaTfton5voJ6ODBhvUaDFQnYkHxaTx0WrFegEQivhq9Tpq XjyBJfX2xn6wKFzz1CG+/vHPlQLT+v5Z5rwAQj+mLEOwUyK8vfXyLeMH5I+lkWaId1bI Q++5iV5UDmA0mHGBzGAB+Ed+meSm61EAJknLYXH5NB2zmVMluWrDkJhKeaZX8fKqz5Vh q+KA== X-Gm-Message-State: AOAM531w2OHYeeytPiGPKEGnFX25iR0LmL/6iZVio4TW6Laps4pAKsnN 48Lyoa7ewYKMvxl0JZJikZfk0uf/Z98= X-Google-Smtp-Source: ABdhPJzbDW4QXpRB6FiepOs1Ze3csQdBWkf2dMkAIBQtBcVKep17PfjIOiDuaxOhFJfQn9ShvOtY+Q== X-Received: by 2002:a5d:6d0e:: with SMTP id e14mr7385773wrq.58.1644524865831; Thu, 10 Feb 2022 12:27:45 -0800 (PST) Received: from [192.168.0.160] ([170.253.36.171]) by smtp.gmail.com with ESMTPSA id n5sm2035933wrm.3.2022.02.10.12.27.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Feb 2022 12:27:45 -0800 (PST) Message-ID: Date: Thu, 10 Feb 2022 21:27:44 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: [PATCH v2] x86-64: Optimize bzero Content-Language: en-US To: Wilco Dijkstra , Adhemerval Zanella , Noah Goldstein , "H.J. Lu" Cc: GNU C Library References: <20220208224319.40271-1-hjl.tools@gmail.com> <1f75bda3-9e89-6860-a042-ef0406b072c1@linaro.org> <78cdba88-9e00-798a-846b-f0f77559bfd5@gmail.com> From: "Alejandro Colomar (man-pages)" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, 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: Thu, 10 Feb 2022 20:27:48 -0000 Hi Wilco and Adhemerval, On 2/10/22 14:01, Wilco Dijkstra via Libc-alpha wrote: > No code uses bzero, no compiler emits bzero. It died 2 decades ago... > >> My point is this is a lot of code and infrastructure for a symbol marked >> as legacy for POSIX.1-2001 and removed on POSIX.1-2008 for the sake of >> marginal gains in specific cases. That was what triggered my fears. I as a user, not a compiler or libc writer, am not really interested in the implementation details, as long as the implementation does the magic for me. I want to be able to keep using bzero(3) in source code, but if the compiler transforms it into memset(3) (or a for loop), I don't even want to know. On 2/10/22 20:19, Wilco Dijkstra wrote: > Hi Alex, > > Don't worry, you're not a bzero user - just check your binaries and > I bet you will find zero calls to bzero! > :) > GCC/LLVM avoid calls to bzero, bcmp, bcopy and mempcpy. The goal is to > avoid unnecessary proliferation of almost identical string functions where > there is absolutely no performance benefit. In fact this duplication is typically > a net loss, partly due to reducing optimization effort and the extra runtime > overhead due to having multiple copies of the same function in caches and > predictors. > > However if you care about having a standardized call to zero memory, just > propose it for the next C/C++ standard. Given we will not agree on naming, > we could just add memzero, memclr, memset_zero and bcopy as synonyms > for memset. Hmm, I'll do so. Will try to press bzero(3) into C3x. On 2/10/22 20:42, Adhemerval Zanella wrote: > The bzero won't go away since glibc will continue to support old POSIX > interfaces, but Wilco has a point: it is an interface that has been > deprecated for more than 2 decades and usually only BSD-like code > still keeps using it (explicit_bzero was initialized from openbsd). > [...]>> >> static inline bzero(s, n) >> { >> memset(s, 0, n); >> } >> >> Is that really a pain to maintain? > > Yes, this is *exactly* what we are trying to remove and I will oppose to > reintroduce it after all the cleanups we did in this front (for instance > 18b10de7ced9e9). > > Besides your code most likely is calling memset under the hoods, gcc by > default converts bzero calls to memset. It seems to be really tricky to > actually force gcc emit a bzero call to libc, I would could make by not > including string.h, adding an explicit prototype to bzero, along with > -fno-builtin: I guess that it's GCC that defines that (or equivalent) code, instead of glibc. As a user-space programmer, that's fine by me :-). >> If libc ever removes bzero(3), it's not like I'm going to start using >> memset(3). I'll just define it myself. That's not an improvement, but >> the opposite, IMO. >> >> Ideally, POSIX would reconsider some day, and reincorporate bzero(3), >> but I don't expect that any soon :(. > > I really think it is unlikely, but it is just my view. > [...]>> Other projects that I have touched (including nginx and shadow-utils), >> seem to have some similar opinion to me, and they define memzero() or >> some other similar name, with an interface identical to bzero(3) (just a >> different name to avoid problems), to wrap either bzero(3) or memset(3), >> depending on what is available. > > 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. Cheers, Alex -- Alejandro Colomar Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/ http://www.alejandro-colomar.es/