From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 14677 invoked from network); 26 Dec 2020 01:40:11 -0000 Received: from ewsd.inri.net (107.191.116.128) by inbox.vuxu.org with ESMTPUTF8; 26 Dec 2020 01:40:11 -0000 Received: from mimir.eigenstate.org ([206.124.132.107]) by ewsd; Fri Dec 25 20:38:56 -0500 2020 Received: from abbatoir.fios-router.home (pool-74-101-2-6.nycmny.fios.verizon.net [74.101.2.6]) by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id 563510e7 (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO); Fri, 25 Dec 2020 17:38:47 -0800 (PST) Message-ID: To: kemalinanc8@gmail.com To: 9front@9front.org Date: Fri, 25 Dec 2020 17:38:45 -0800 From: ori@eigenstate.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: structured anonymous standard app Subject: Re: [9front] [PATCH] branchless assembly abs() and labs() for amd64 Reply-To: 9front@9front.org Precedence: bulk Quoth Kemal : > hello again, > > on maintainability issue, we can do it on c with bit shifts like this: Simplicity and clarity should win unless the added complexity buys us something. To me, the bit twiddling operation seems less obviously correct than the current: if(a < 0) return -a; return a; I appreciate the effort, but I'd prefer that we leave this patch be unless it's solving a problem Optimization should ideally start with measuring a real program. > on size, the assembly one seems to be the clear winner. the original > abs's object file (unlinked) is around 400~ bytes, assembly one is > 120-140~, the branchless c one is 300~. Note that unlinked sizes don't matter much: our object files do not contain encoded assembly, but instead a simpler "bytecode" that the linker will optimize lightly and then encode.