From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12133 Path: news.gmane.org!.POSTED!not-for-mail From: David Guillen Fandos Newsgroups: gmane.linux.lib.musl.general Subject: Re: Do not use 64 bit division if possible Date: Sun, 26 Nov 2017 02:40:24 +0100 Message-ID: References: <424674f0-8460-7807-7366-a87d8588e8bc@davidgf.es> <9716E0B3-B86C-4CFF-8636-6DE4BAA0D716@mac.com> <5575a0c9-0f53-f8e7-e0dc-6c1ff2b594f7@davidgf.es> <20171125235333.GQ1627@brightrain.aerifal.cx> <796e366e-f321-25a3-78e7-8a3800e62eeb@davidgf.es> <20171126005916.GS1627@brightrain.aerifal.cx> <20171126012311.GT1627@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1511660440 17739 195.159.176.226 (26 Nov 2017 01:40:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 26 Nov 2017 01:40:40 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 To: musl@lists.openwall.com Original-X-From: musl-return-12149-gllmg-musl=m.gmane.org@lists.openwall.com Sun Nov 26 02:40:37 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1eIlvt-00048t-65 for gllmg-musl@m.gmane.org; Sun, 26 Nov 2017 02:40:33 +0100 Original-Received: (qmail 22014 invoked by uid 550); 26 Nov 2017 01:40:38 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 21995 invoked from network); 26 Nov 2017 01:40:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=davidgf-es.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=TZKlHly3Oqt+NMMj8zFxR8rDxq8qwgWz3BRfohwS5dU=; b=bzFrmlDhi2l/1nihemUXawnuwoZuMsMfFcs7hEeR2T2ECRu/lt5qEGdzKTnf98gD/l 4SwrXqZ4BwoSE7Jl9KpIiqR3Wa7U7CiTTsK5royOCX45+BKW/7xyGo4FChhfsc8iCZlx aUXh+TUpjoFOZvbjcESBULsS1fxGiARsOLEEFY5TgK9vMm1TECjV8Ij2FmMwSr+zZIbF 0EKtt1Tx8rJVHfIpbNxrui9nSdmoE6EXHTtJWdClaMnKNXOs46M67FJBcrGmj3H69jCi fPTs5Cpoha5SyNFZF95hBW8B9IbrGfKMu5wVQSjY+LMLofJAbTxTZ7rIOR4WM0Kp46kq nAOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TZKlHly3Oqt+NMMj8zFxR8rDxq8qwgWz3BRfohwS5dU=; b=gubzeLvCyc9knwrs+vd9f8y9nzCKwfUApopWJGSIfRQpp+OCRlU2fravHn7dPZAZet huGFZixVqA+/TZ5mry3LP5WWDdvaiZ6N3YMSR3bQuY+dni4Djvlt8vSA+bvex/oj74/Y pyCEzVypPtGeoYCvUa7TZStlEnS2G5N26lgnePYlneUobobnB1ua0Q+ptUfLj/sfa+1t SPknEuxpnq5rou1DYsbPtbMXiNPxc8zcmabavphl3g0vEKvVwgUsDVeXo6RYuFZrUadM 8oW1yqEvTGPDAK3BxC25dAIMFEAHSNzUJhUPbhGM7Yv+uzSn5EJcJp9pMuNGUd1kEVqz Mrxw== X-Gm-Message-State: AJaThX65TLg56dHAIfGglmlg8dX3FZU7OaV5vTufWGluKz1m4njjh6Ze 8MUgOKZUGsjdrlnGW+TaEgI26X2Riw== X-Google-Smtp-Source: AGs4zMbG5ivmMkohC8/KEqVu9GU6r1L9juITcxmaYcW5DKUxUWnilgsV1RFHGrllDyBpYugc4U1o3A== X-Received: by 10.80.138.199 with SMTP id k7mr21673691edk.229.1511660426269; Sat, 25 Nov 2017 17:40:26 -0800 (PST) In-Reply-To: <20171126012311.GT1627@brightrain.aerifal.cx> Content-Language: en-US Xref: news.gmane.org gmane.linux.lib.musl.general:12133 Archived-At: On 26/11/17 02:23, Rich Felker wrote: > On Sun, Nov 26, 2017 at 02:12:58AM +0100, David Guillen Fandos wrote: >> >> On 26/11/17 01:59, Rich Felker wrote: >>> On Sun, Nov 26, 2017 at 01:49:09AM +0100, David Guillen Fandos wrote: >>>> Hey, >>>> >>>> Wow that's an awesome optimization (the a&-a), didn't know gcc was >>>> smart enough to figure that out by itself :D >>> >>> It doesn't seem to be doing any optimizing for me. What it *should* do >>> is optimize the div to ctz+shift. >>> >>> BTW please don't top-reply; it makes threads hard to follow and hard >>> to meaningfully reply to inline. >>> >>> Rich >>> >>> >>>> I just realized that PAGE_SIZE seems indeed to be defined to a >>>> constant for some architectures, did not notice since I was running >>>> on MIPS which has a page size different for each uarch. >>>> >>>> I'd say the (a&-a) is a very simple optimization and we should use >>>> it, since it adds almost no complexity and sames some cycles and >>>> some .text bytes, which is sometimes a bit tight. >>>> >>>> Something like this? Doesn't hurt constants, improves some arches :) >>>> >>>> diff --git a/src/conf/sysconf.c b/src/conf/sysconf.c >>>> index b8b761d0..aa9fc9d1 100644 >>>> --- a/src/conf/sysconf.c >>>> +++ b/src/conf/sysconf.c >>>> @@ -206,7 +206,7 @@ long sysconf(int name) >>>> if (name==_SC_PHYS_PAGES) mem = si.totalram; >>>> else mem = si.freeram + si.bufferram; >>>> mem *= si.mem_unit; >>>> - mem /= PAGE_SIZE; >>>> + mem /= (unsigned)(PAGE_SIZE & -PAGE_SIZE); >>>> return (mem > LONG_MAX) ? LONG_MAX : mem; >>>> case JT_ZERO & 255: >>>> return 0; >> >> Sorry for that, default settings you know :) >> >> Well the main reason is cause in MIPS it requires adding __divdi3 >> which is around 1KB of code, which hey, it's not much, but why would >> we need it right? It makes a difference in embedded tools with >> statically linked musl. >> >> Thanks for your interest! > > If this is a real problem you're hitting, I'm interested in helping, > but it seems unlikely. If your program uses printf or other common > functions it will already be pulling in __divdi3 I think. > > Rich > Not a real problem really, more than binary size. I'm not using printf that's why I was chasing all the big-ish functions that seemed unnecessary in my binary and I was curious about why sysconf actually needed a 64 bit division on mips. Also the (a&-a) doesnt seem to help, gcc is not that smart :) It seems there's no easy way to hint it that a number is a power of two, I guess that's why the kernel uses PAGE_SHIFT. Given that page size is not constants in some arches it might be useful to have page shift, since some operations would be faster maybe? Like page aligning [ & ~(PAGE_SIZE-1) ]? Not sure if we care that much even though we use that in malloc. Thanks for the interest! David