From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Wilco Dijkstra Newsgroups: gmane.comp.lib.glibc.alpha Subject: Re: [PATCH] v11 Improves __ieee754_exp() performance by greater than 5x on sparc/x86. Date: Thu, 8 Feb 2018 11:40:37 +0000 Message-ID: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1518089926 9997 195.159.176.226 (8 Feb 2018 11:38:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 8 Feb 2018 11:38:46 +0000 (UTC) Cc: "libc-alpha@sourceware.org" , nd To: "patrick.mcgehearty@oracle.com" , "Szabolcs Nagy" Original-X-From: libc-alpha-return-90139-glibc-alpha=m.gmane.org@sourceware.org Thu Feb 08 12:38:42 2018 Return-path: Envelope-to: glibc-alpha@blaine.gmane.org DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:date:message-id :content-type:content-transfer-encoding:mime-version; q=dns; s= default; b=NsGozguAtmze6+gp/+ugsPO57hbMyWQ8gL5yPrsfw5rE0aFZUUeXC 6s8Zf6tGrd7N4zY8lyYaAFeqmFUiHSsFhxgI0/zG5G6umrhvBajDtK3B1YfZyXAo fBUqbO9OWwFzQw7gd3fBL78ChPvZIR+Hk2tzqR8Noyib0weqTl67Fs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:date:message-id :content-type:content-transfer-encoding:mime-version; s=default; bh=FCMgfLsUv3yus9fydCsjdk+pVsw=; b=i9uckgCKlR7lZZAr7x4bbZMa0irZ I/0iCThQk/2hOiY931HZzQDR9dDtbrzKWeB0ixehkI7jQL6CTZEwerBii0wetcMY w8Hz/57MwXktItM8IuD7ZFGzBksHibcloljVvIHzXykLCSo0EwQnwx2VeDIRAs3N uVWMlsSohJxXLJo= Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Original-Sender: libc-alpha-owner@sourceware.org Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=million X-HELO: EUR01-HE1-obe.outbound.protection.outlook.com authentication-results: spf=none (sender IP is ) smtp.mailfrom=Wilco.Dijkstra@arm.com; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;DB6PR0801MB2007;7:YEKf9xGbcHyiZOGyWrKf0XR1eurR9YXGPfAO3+IH37crfhK8aEaG/ADz+sGs0/6VXo2JcaHYQP1J69dF9T+NNU5COgAQzgMXhS980xu0osG3g9rMTvsYaQHATfhXkf4bVDTbMl7X91T4DAgIoxfUL5cnC1tevYu5YYVLwPqHPtkHOYucrf/Z+gGHKpF2fotAc7e8uWBbWCnpOTy9CxJZxOQ9v57ASuj22isnghmG9GPmYjAbBuRRyWm/1rCaPVSq x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: ed5bda58-e1d5-434b-d7c7-08d56ee8c5dc x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020);SRVR:DB6PR0801MB2007; x-ms-traffictypediagnostic: DB6PR0801MB2007: nodisclaimer: True x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040501)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231101)(2400082)(944501161)(3002001)(6055026)(6041288)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011);SRVR:DB6PR0801MB2007;BCL:0;PCL:0;RULEID:;SRVR:DB6PR0801MB2007; x-forefront-prvs: 0577AD41D6 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(366004)(396003)(39380400002)(39860400002)(346002)(376002)(189003)(199004)(66066001)(102836004)(3660700001)(55016002)(316002)(478600001)(68736007)(6246003)(14454004)(9686003)(53936002)(7696005)(110136005)(6116002)(105586002)(99286004)(5660300001)(3846002)(3280700002)(229853002)(54906003)(6636002)(72206003)(8936002)(2900100001)(7736002)(33656002)(305945005)(74316002)(186003)(6506007)(6436002)(26005)(81166006)(106356001)(81156014)(2906002)(4326008)(8676002)(97736004)(86362001)(5250100002)(25786009)(2501003);DIR:OUT;SFP:1101;SCL:1;SRVR:DB6PR0801MB2007;H:DB6PR0801MB2053.eurprd08.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: VWBx59flIdqP71BuJkP7N4D5qIRU3Ix/sK8x15Y34/J2ZKL8KDjye2uQNr/Rk79O6aSP3+degK5c/dCRqzGoMA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: ed5bda58-e1d5-434b-d7c7-08d56ee8c5dc X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2018 11:40:37.3220 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0801MB2007 Xref: news.gmane.org gmane.comp.lib.glibc.alpha:82487 Archived-At: Received: from server1.sourceware.org ([209.132.180.131] helo=sourceware.org) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ejkXJ-0002Dh-Cg for glibc-alpha@blaine.gmane.org; Thu, 08 Feb 2018 12:38:41 +0100 Received: (qmail 26379 invoked by alias); 8 Feb 2018 11:40:43 -0000 Received: (qmail 26365 invoked by uid 89); 8 Feb 2018 11:40:42 -0000 Hi Patrick, > Has there been a serious discussion in the past of to what degree > of accuracy glibc/libm should support other rounding modes than > round-to-nearest? If a concensus decision were made that > other rounding modes were allowed slightly greater ulp diffs, > we could remove all the rounding mode checks and get > faster code. Failing that concensus, I don't see how we > can bypass the rounding mode checks for the generic code. There have been various discussions, but nothing conclusive. I believe the rounding mode changes can be removed from all the key math functions if we accept 1 extra ULP in non-nearest rounding modes. As Szabolcs mentioned there are some round-to-int idioms used by math functions which rely on a specific rounding mode, but we can fix those. If rounding errors in the more complex functions go up (some are very sensitive to ULP), we could consider adding the rounding mode changes there= - that means you only do it where absolutely necessary, and also in cases whe= re the relative overhead is much lower. Or alternatively we could agree that we don't have a requirement to optimiz= e math functions for absolute best possible ULP with different rounding modes= , and accept larger ULP errors. > I'll look into comparing removing the slow path on Sparc and > x86, including running my own "10 million values" test to > get a sense of how frequently the slow path is triggered > and what the largest relative error that test observes. > I'll also run timing tests. Yes I noticed that even when the slow path doesn't trigger, it has a signif= icant overhead (log is 18% faster without the slow paths). Note we'll likely post= patches for removing slow paths in exp, pow as well. Wilco=