From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11528 invoked by alias); 7 Sep 2017 21:05:37 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 11171 invoked by uid 89); 7 Sep 2017 21:05:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=his, risk X-HELO: relay1.mentorg.com Date: Thu, 07 Sep 2017 21:05:00 -0000 From: Joseph Myers To: Patrick McGehearty CC: Subject: Re: [PATCH] improves exp() and expf() performance on Sparc. In-Reply-To: <706fe477-8d85-47d9-d62c-164bba5606ec@oracle.com> Message-ID: References: <1504306749-46787-1-git-send-email-patrick.mcgehearty@oracle.com> <706fe477-8d85-47d9-d62c-164bba5606ec@oracle.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-SW-Source: 2017-09/txt/msg00313.txt.bz2 On Thu, 7 Sep 2017, Patrick McGehearty wrote: > The sysdeps/ieee_754 subtree has a number of direct calls into > ieee754_exp from such places as e_sinh, e_cosh, e_gamma_r, and s_erf. > While I have not found direct calls to __exp in the ieee_754 subtree, > I see overriding w_exp_compat.c as having some risk of > unexpected behavior with the only perceived benefit to be eliminating > a modest number of bytes from libm. Those direct calls don't use the wrapper and so are completely irrelevant to the matter of overriding it. It is quite clear that the wrapper needs to be overridden on any architecture providing its own exp (as opposed to __ieee754_exp) implementation, just as ia64 overrides it. > For expf, the comparison for individual values shows an improvement > in the range of 15x. benchtests does not measure expf(). Presumably you need to test with the benchmark addition Szabolcs points to in his patch submission. > Making this change will provide a clear, immediate gain in expf() > performance. Maintainability is also important, and it points against having lots of architecture-specific versions. Thus, people interested in expf optimization should first be helping with the review of Szabolcs's patch (and the benchtests addition patch it builds on). Once that's done, it can provide a basis for judging the merits of architecture-specific expf versions (which might well also indicate improvements to Szabolcs's code as an alternative to adding an architecture-specific version). For exp, when you have a better-performing C version the question should first be whether it can replace the existing generic C version (possibly then being built multiple times on architectures where that's useful) rather than whether to add it as architecture-specific code. Adding a C version as architecture-specific code (rather than having limited architecture-specific hooks in a generic version) should only be once there is evidence of different architectures' performance characteristics requiring substantially different approaches. -- Joseph S. Myers joseph@codesourcery.com