From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.1 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 5F8571F428 for ; Fri, 24 Mar 2023 16:30:29 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=bkwrJQtB; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id CA5AD3858C33 for ; Fri, 24 Mar 2023 16:30:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CA5AD3858C33 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1679675426; bh=S1savKHPjCWuKke3k9eHYRBc3pYg3lN4PHNzRKzsMBE=; h=References:In-Reply-To:Date:Subject:To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=bkwrJQtBKJBZH80j9fbSkUSMh7iyjhRchUcEJYXI5BZ//k697dW8KOkajPhVIizaw sSMs9+qbCnrkbcilRXGAnL8mztoGBBcoUPrIUzk1A+xQWFbVc6/S9K/dTT7aHiEkPv /Devb/khkJWKJ03vnmKIvAtSn6CMJ7l0McFFMeik= Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) by sourceware.org (Postfix) with ESMTPS id 106163858D1E for ; Fri, 24 Mar 2023 16:30:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 106163858D1E Received: by mail-ed1-x531.google.com with SMTP id ew6so10105337edb.7 for ; Fri, 24 Mar 2023 09:30:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679675402; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=S1savKHPjCWuKke3k9eHYRBc3pYg3lN4PHNzRKzsMBE=; b=WnOsIiyAjzX9jEgHDDr+M5uQ1241WMVfeiUiOApFEXf025tx6267cGCfzcaDq28NLC ektosPTwkoAMAiC4XIkECCbufZFfNEmTJI56m1XRc8BzXlV8r1ehlKFnMIOJ2fLxczlL 2NlzfUp32AwQMuvu33TMqcWpHnO1ohpjjX9HhIeBjx8aqQerbwkb7ezIUHc8rTHVUzrf oWp4MdslnnOFrLsqyvj6rYBZZSSlrkc0mT7U3tPxoW4lUzPW+Ggtqhw0GSPqGlnh0zOD Pq4k2eHeJUy7yiPYe/FCYywv3d4tyWUrYFTN7IalRCxdlKiotoy3OzVsDqgIGuZg23F+ xDHA== X-Gm-Message-State: AAQBX9dt04E2P2Ace/0jOE8B+8xC9oGuGkTGk2OK/RMmWe3i7Fau1cQs I28hmyPTSgPXVoYzZbTqlpooppSuTvE1+r+vt/NNoLEMc4Q= X-Google-Smtp-Source: AKy350YD5M7oTyh/McBSXJaWFRFFoFJM43ICyG14+yt8qoNmWEpOmcOjUN8WjkmyhlftM02V0NmU68oM2wb/BqFWsLA= X-Received: by 2002:a17:907:6e22:b0:932:e546:b8bb with SMTP id sd34-20020a1709076e2200b00932e546b8bbmr1819313ejc.0.1679675401645; Fri, 24 Mar 2023 09:30:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 24 Mar 2023 11:29:50 -0500 Message-ID: Subject: Re: [PATCH] Benchtests: Improve large memcpy/memset benchmarks To: Wilco Dijkstra Cc: GNU C Library Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Noah Goldstein via Libc-alpha Reply-To: Noah Goldstein Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On Thu, Mar 23, 2023 at 6:01=E2=80=AFPM Wilco Dijkstra wrote: > > Hi Noah, > > > >> - align &=3D 63; > > > > Can you replace with `align &=3D getpagesize () - 1`? > > Yes that would make more sense indeed. > > >> - if ((align + len) * sizeof (CHAR) > page_size) > >> - return; > > > > Is there a reason to remove the out of bounds check? > > Well it can't ever go out of bounds. The allocated buffer size is > 2 * page_size (ie. 4 times real page size or 2 times MIN_PAGE_SIZE > due to the incorrect logic in init_sizes). > I disagree, we have a bounds check in nearly all other benchmarks and I think its 1) a convenience so you don't need to add the equivalent code in many other places and 2) a portability thing as page size varies by system but people often write benchmark bounds with constant size bounds. > And if it could go out of bounds it should be an assert so we don't > silently benchmark a bounds check! Then I think the approach would be to output the json parameters and report invalid in some way for the times. In other places benchmarks rely on this bounds check and it seems more error prone than anything else to just leave it unchecked. I would much rather the benchmark not run or fail in some way than report a potentially incorrect time as true. > > >> align2 &=3D 4095; > > > > Might as well fix these up, can you replace 4095 with `getpagesize () -= 1`? > > Sure. > > >> + size_t i, iters =3D (MIN_PAGE_SIZE * 64) / n; > > > > this takes [.5, 10] seconds? > > Yes, it's only 1 GB written per test. It takes ~8.5 seconds on an old slo= w > Cortex-A72. > > Cheers, > Wilco > >