From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14731 invoked by alias); 12 May 2017 19:47:24 -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 14712 invoked by uid 89); 12 May 2017 19:47:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,SPF_PASS autolearn=no version=3.3.2 spammy=representative, perfect X-HELO: mail-oi0-f52.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NwfYCnl6LIYoaApXKImfmZyGmktVgHYuY5UmfLS+Ax8=; b=fC8BaFgmHpYs3xxlZt6+W1B04QfIk46Fw4FD+xVAxnaoG9L8z5ttzhaxSLHDGfhb6H SVDpOGwmzwtsmRIsuJNvCejT67ZLs11iu9pnlpR9LcZ5pEfJYposGxu3+u3kFu24skmp pkCcQhOrDQ3mx083cHmofYcwg6uVHv/kmGT4cYo+9JBMvAts3OakQxHd+iQv4LBIknB5 7dNn/19HDzsZbekzsmtt7ixN9iogqgaB7IdRfo39EPMndMSjkgHPjcJiICG+xYxqWSpK m6eQJTbzGSLDOZiprtosqgLhtbgtJ+XSCrggVfLHWMNJjkFbulnKl882Ign6YkAtYoVA csQA== X-Gm-Message-State: AODbwcDWmHPX9EN01EdEmpCZRKW/wh6UaYkvE/EWqQh1fDJEFqLyYBQ9 wYWS7oMmpofcGqAnn2dEHDP9iiDAo8oE X-Received: by 10.157.49.89 with SMTP id v25mr2647280otd.45.1494618444127; Fri, 12 May 2017 12:47:24 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <28e34264-e8c5-5570-c48c-9125893808b2@redhat.com> References: <9c563a4b-424b-242f-b82f-4650ab2637f7@redhat.com> <28e34264-e8c5-5570-c48c-9125893808b2@redhat.com> From: Erich Elsen Date: Fri, 12 May 2017 19:47:00 -0000 Message-ID: Subject: Re: memcpy performance regressions 2.19 -> 2.24(5) To: "Carlos O'Donell" Cc: "H.J. Lu" , GNU C Library Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2017-05/txt/msg00420.txt.bz2 HJ - yes, the benchmark still shows the same behavior. I did have to modify the build to add -std=c++11. Carlos - Maybe the first step is to add a tunable that allows for selection of the non-temporal-store size threshold without changing the implementation that is selected. I can work on submitting this patch. On Wed, May 10, 2017 at 7:17 PM, Carlos O'Donell wrote: > On 05/10/2017 01:33 PM, H.J. Lu wrote: >> On Tue, May 9, 2017 at 4:48 PM, Erich Elsen wrote: >>> store is a net win even though it causes a 2-3x decrease in single >>> threaded performance for some processors? Or how else is the decision >>> about the threshold made? >> >> There is no perfect number to make everyone happy. I am open >> to suggestion to improve the compromise. >> >> H.J. > > I agree with H.J., there is a compromise to be made here. Having a single > process thrash the box by taking all of the memory bandwidth might be > sensible for a microservice, but glibc has to default to something that > works well on average. > > With the new tunables infrastructure we can start talking about ways in > which a tunable could influence IFUNC selection though, allowing users > some kind of choice into tweaking for single-threaded or multi-threaded, > single-user or multi-user etc. > > What I would like to see as the output of any discussion is a set of > microbenchmarks (benchtests/) added to glibc that are the distillation > of whatever workload we're talking about here. This is crucial to the > community having a way to test from release-to-release that we don't > regress performance. > > Unless you want to sign up to test your workload at every release then > we need this kind of microbenchmark addition. And microbenchmarks are > dead-easy to integrate with glibc so most people should have no excuse. > > The hardware vendors and distros who want particular performance tests > are putting such tests in place (representative of their users), and direct > end-users who want particular performance are also adding tests. > > -- > Cheers, > Carlos.