From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2C96629B77F for ; Tue, 29 Apr 2025 10:08:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745921291; cv=none; b=dVpMA7y7XhY5RXt35vviTmkyw8Eabkq1Dv5/v4yvVHJCq0YxNQgw1mQq7bK+/WehDWp9HKu09+xk6bB65PPrXYOT4vMXiINzqvbIACgjl9DrvmPBVtmC+2nfSkiAAv8ONZUggxjyU0rhWPQu0XqKJwj6lnRj0BgCu2/Fd6ZDVHA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745921291; c=relaxed/simple; bh=FNkyaJGp8MfoVlpMeJugXq0KnLpj/jBe07Y8pBAACqE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=W1RfUPq4iY+6fzWYoouC226kvH8wrOupGXE2VI9Myc+tnklECOkgbtlu+VtZYEkF3KKhDxIBb0+wLZX5cYrkXmxs+7wlQAcY3IkhudwRY1lGIW51Mz1T6U8l3xCxWYY7zRcdmcTdLUy4oMk1QGQufy3PWmgR6MB8TRj1tYKm2w8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VZKOu799; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VZKOu799" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C9E22C4CEE3; Tue, 29 Apr 2025 10:08:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745921289; bh=FNkyaJGp8MfoVlpMeJugXq0KnLpj/jBe07Y8pBAACqE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=VZKOu799+4V5pW/WeIPX/qMOLrBUca2dqVJr++ECXW2r6WG/1H+svFEldDbiX7Oo/ DY94o1FtmcdGss/70ZUqk4LKljL1SvgzZ16Pvv24LIf9hBcyY3/XJyf68AQiZDjjnH L59TxFlHG20sFn7drQpXUlPUJ8ThkOni004ozQLvINNZUhpm+KdEjz3/Qpbg7khDuH I3DrOfWwhOeomddlNJ2qQxoiV/uAX1X4erXjcI2/wTWBJc2z9ALHBdlzAJpLs36VLl yOaXD0OWQbj4s1mQ1vUixWVu+yj/43QylJFIKx1Vy87I6Ai25BDi8HqaBo91TVBiwI exBh1/FcloI/Q== Date: Tue, 29 Apr 2025 12:08:03 +0200 From: Ingo Molnar To: Linus Torvalds Cc: Andrew Cooper , Arnd Bergmann , Arnd Bergmann , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Boris Ostrovsky , Alexander Usyskin , Greg Kroah-Hartman , Mateusz =?utf-8?Q?Jo=C5=84czyk?= , Mike Rapoport , Ard Biesheuvel , Peter Zijlstra , linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH] bitops/32: Convert variable_ffs() and fls() zero-case handling to C Message-ID: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: * Linus Torvalds wrote: > On Mon, 28 Apr 2025 at 00:14, Ingo Molnar wrote: > > > > And, just out of intellectual curiosity, I also tried to measure the > > code generation price of the +1 standards-quirk in the fls()/ffs() > > interface as well: > > > > ... and unless I messed up the patch, it seems to have a surprisingly > > low impact - maybe because the compiler can amortize its cost by > > adjusting all dependent code mostly at build time, so the +1 doesn't > > end up being generated most of the time? > > No, I think one issue is that most users actually end up subtracting > one from the return value of 'ffs()', because the "bit #0 returns 1" > semantics of the standard ffs() function really is insane. > > It's not just that it doesn't match sane hardware, it's also that it > doesn't match sane *users*. If bit #0 is set, people want '0', so they > typically subtract 1. > > So when you stop adding one, you aren't actually removing code - > you're often adding it. > > Just see how many hits you get from > > git grep '\ > which is obviously not a very precise pattern, but just look at the > output and see just *how* common that "subtract one" thing is. > > I really don't understand how anybody *ever* thought that the whole > "return one bigger" was a good idea for ffs(). Yeah. No argument from me that it's a badly thought out interface - I was just surprised that it doesn't seem to impact performance as badly as I expected. I have to add that a lot of work went into absorbing the negative effects of the ffs()/fls() interfaces: starship:~/tip> git grep -Ee '__ffs\(|__fls\(' | wc -l 1055 So it impacts code quality negatively, which is arguably the worse side effect. > But maybe people really were poisoned by the Pascal mindset. Or maybe > it was invented by some ancient Roman who hadn't heard of the concept > of zero. Who knows? Hey, ancient Romans didn't even have the concept of *whitespaces* and punctuation to begin with: https://historyofinformation.com/images/Vergilius_Augusteus,_Georgica_121.jpg Lazy stonemasons the lot of them. Romans were the worst ever coders too I suspect. What have the Romans ever done for us?? Ingo