From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-88744-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 46360 invoked by alias); 1 Jan 2018 16:41:05 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 46349 invoked by uid 89); 1 Jan 2018 16:41:04 -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=practical, competing, trading, Hx-languages-length:857
X-HELO: relay1.mentorg.com
Date: Mon, 01 Jan 2018 16:41:00 -0000
From: Joseph Myers <joseph@codesourcery.com>
To: Patrick McGehearty <patrick.mcgehearty@oracle.com>
CC: <libc-alpha@sourceware.org>
Subject: Re: [PATCH] Improves __ieee754_exp() performance by greater than 5x
 on sparc/x86.
In-Reply-To: <028264ef-2605-07bd-bea0-aaafbbe8f081@oracle.com>
Message-ID: <alpine.DEB.2.20.1801011636310.2695@digraph.polyomino.org.uk>
References: <1514590916-114435-1-git-send-email-patrick.mcgehearty@oracle.com> <alpine.DEB.2.20.1801010131530.28505@digraph.polyomino.org.uk> <028264ef-2605-07bd-bea0-aaafbbe8f081@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-02.mgc.mentorg.com (139.181.222.2) To
 svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1)
X-SW-Source: 2018-01/txt/msg00048.txt.bz2

On Mon, 1 Jan 2018, Patrick McGehearty wrote:

> With typical L3 caches now measured in Mbytes/thread
> and L2 caches at least 64Kbytes/thread if not 256Kbytes/thread
> having modestly larger tables is a reasonable tradeoff,
> especially since we are trading so much performance improvement
> but giving up some accuracy. I retained the 64 and 128 entry
> versions, so I can switch out the table size easily.

I think L1 cache size is relevant as well (and in practical uses you have 
more than just the exp function and data competing for cache space; what's 
optimal for a benchmark just calling a particular function may not be 
optimal for a typical system as a whole).  I think going back to the 64 
entry version is appropriate.

-- 
Joseph S. Myers
joseph@codesourcery.com