From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-4.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (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 ED0A41F8C6 for ; Tue, 13 Jul 2021 18:47:51 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1C608396E84B for ; Tue, 13 Jul 2021 18:47:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1C608396E84B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1626202071; bh=lqDSb9u6F1ThE57HhF99VEEUefJisiAFeEXX4jlMLC0=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=EIslV/IVJXkRQypB7RIC79BRsLLy9dxSfyb5QLZhcTs1HpKtjNYV2FyDKYQLXALbl h4aygNY+FzfZd/KBfV5LTIUkXVQ1WLzHDc8zZiAbAkugQIY04zQiN3Z52SDj70Wz1R 5psDu+dM13R3ZkZiM8nURHaMB6S2qY/p9qBMsQ5g= Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) by sourceware.org (Postfix) with ESMTPS id F2838384C007 for ; Tue, 13 Jul 2021 18:47:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F2838384C007 Received: by mail-lj1-x230.google.com with SMTP id u25so31456034ljj.11 for ; Tue, 13 Jul 2021 11:47:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HKT/AUYgS78kfxUv2Nv37XGdone1z5IVZQaIWkoLNkg=; b=Vbj/IbArL8Olm/DYeCq9sXelNp5j3rs0Uigd2JeN5UqxjK5sK3R7hzZBP0IwwLHihr bk0rtAdL/tvRohMX6RtWr69HUOLUntXsI/RmxxAjHYHzdThsqk+K44kH6EbpmUj2xsMa mRDksNDgI7AU2KFYBXoxRynrWc3PXsnTEanDILKdBjtObBJX4XGigHZq7NU/coQIUXJm FUfNZ9m0CQN/OFl3Xta3OC8aN3ZdEA3KZIWlGu//g8Miva6qi+GXiuctJEIXELuVYgoQ +u6u9U2IJbGFZCoJfo6Cbd5ov9fnHxUDfQdMqqmgLKO3J3+80LzopiPosKCLqiKSoKH3 zRwg== X-Gm-Message-State: AOAM533OdHVXfBk2OVQ2JfbEOu6vp177tHkJaVsrPF5TBVS99R7C2YtQ BULeQMOkBlOuAwvfMpMgtu/2pzmVjJTjSRvZiJoiFrImDXo= X-Google-Smtp-Source: ABdhPJxx7YFYyVdckuAY1oWe2YHNvHtQIG6aVEaET21ihx01maB1bkSR2PTfp6c+44HhZwJoawrj3xxMoRJaJf9aywI= X-Received: by 2002:a05:651c:b0c:: with SMTP id b12mr5473653ljr.190.1626202044853; Tue, 13 Jul 2021 11:47:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 13 Jul 2021 14:47:12 -0400 Message-ID: Subject: Re: [PATCH] benchtests: Add memset zero fill benchmark tests To: Wilco Dijkstra Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 Cc: GNU C Library Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On Tue, Jul 13, 2021 at 12:15 PM Wilco Dijkstra via Libc-alpha < libc-alpha@sourceware.org> wrote: > Hi, > > > I like the idea of a benchmark specific for 0 on memset. However having > two > > implementations seems too much. I would rather see just one > > bench-memset-zerofill.c. What I guess would be even better is to have > this > > performance test inside bench-memset.c and bench-memset-large.c. > > I agree just copying the files is not a good idea. Currently bench-memset > and > bench-memset-walk already test zero memsets. Bench-memset-large could just > test zero since that is the most common, especially for large sizes. > Reducing the > number of non-zero tests in bench-memset would make it more representative > - > you could do the main set of tests with zero only and then have a small > selection > where it alternates between zero and non-zero. > I'm in favor of a seperate file. On some x86_64 systems writing zeros to a cacheline that has not been modified can leave the cacheline in an unmodified state[1] which affects memory bandwidth on the writeback to DRAM for larger regions. I can imagine we might want to test memset zero on unmodified vs modified region which will require unique setup that I think justifies a separate file (at least for memset-large-zero). [1] https://travisdowns.github.io/blog/2020/05/13/intel-zero-opt.html > > > Quoting Naohiro Tamura via Libc-alpha (2021-07-13 05:22:14) > >> Memset takes 0 as the second parameter in most cases. > >> More than 95% of memset takes 0 as the second parameter in case of > >> Linux Kernel source code. > > The Linux Kernel does not use glibc, it has his own memset > implementation. > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/string.c#n784 > > Therefore IMO this argument is not suited for this commit. > > The argument is true in general - you could simply state that almost all > memset > calls are zeroing without mentioning the Linux kernel. In some old stats > from > SPEC I saw about 1.8% non-zero memsets. > > Cheers, > Wilco