From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) by sourceware.org (Postfix) with ESMTPS id 0C6C63858C66 for ; Thu, 12 Jan 2023 20:51:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0C6C63858C66 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ej1-x62a.google.com with SMTP id ss4so40461585ejb.11 for ; Thu, 12 Jan 2023 12:51:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=2/HhF0IwvhjDIRjxu7kJQmZOdw/SXScv/UQWY1tsXUg=; b=UPq/0CeK1HBeJ8OHa6Pm7zIjWZPmKr0Yvc75kew3XFUMTuWyMT7YJ2N2kt/S0b30nE KQtuDs3so5LlLWDAUb7hAkWAY4W0EilV6jBrgNPy6YFpF19930+lk0j0DlyXGfDMg3Ye yZxItbVuk/KJHVXZwhv6J2Hw8wJhWCbSXHYWvgmFeT57+zHWfsOZLOE8ARTvHfr3Z71R B06y8iNDqK6aARWtOjGu8FgYLySjHKSA8qPukP6epAJom6ll29Ub9/pmZlVRNlnvGyzC iyf0pXE0sB9eZYQ9jWOLUd8ki6xa0o2zmYyP00nAzegJ25yyEAUruM6Ca7/daQRrIrku B4Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=2/HhF0IwvhjDIRjxu7kJQmZOdw/SXScv/UQWY1tsXUg=; b=qwpjX/lQSXjahbhwva1I90tOynlplMgUMVcn3+jgaTJtF/R0ha4himkS9Sj6B+Dc5B 8cg69z8THcags4PTk94HDZ8U37bc/tF1W9ssRqYaNSJuJM4jFgNh0zAxFXN8tIoLAExl QjC2NFXrodO+hjtKiZyfsOSePfWdQFXBXi4LFBtiX5am6lTZ1YH4NnyS1IrepHjEeQkh 08FxcgenAcBGn8dPsd89hec65KSCcFRZ7FznTO3Oel9nYVEKdxymAwysnY6KQAW+tMDr 1URcMLAT25a5lslKaDczGDrch64N/iuMSMfXS24A9TfkDaGpMJB5edZnwpzMGI5aTZf2 kKUg== X-Gm-Message-State: AFqh2kp7pFXORy6//NN8dy6/hrmJdgAYrl2t1l/+ytrEbs90hnuwqMcC V6KyzkkPm8NYKKhCjTsykhlEEVt2x+Lqy+oA9mimCAhd X-Google-Smtp-Source: AMrXdXvp2L9m70ECnOIwiRwnNsV60358675LPNLbnj1spk43FeaDbrkUKISN/5+uXY8mVmUAxYUIe7jUMYyZYraXcQI= X-Received: by 2002:a17:906:2bce:b0:84c:c4a4:bd4 with SMTP id n14-20020a1709062bce00b0084cc4a40bd4mr2412315ejg.645.1673556711712; Thu, 12 Jan 2023 12:51:51 -0800 (PST) MIME-Version: 1.0 References: <31276f46-5376-4c2c-85c7-ffa08e9a771d@app.fastmail.com> In-Reply-To: From: Noah Goldstein Date: Thu, 12 Jan 2023 12:51:40 -0800 Message-ID: Subject: Re: bug fix for hp-timing.h (aarch64) To: Wilco Dijkstra Cc: Zack Weinberg , "Tang, Jun" , GNU libc development Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, Jan 12, 2023 at 12:32 PM Wilco Dijkstra via Libc-alpha wrote: > > Hi Zack, > > >> On AArch64 the counter is absolutely solid - it's fixed frequency and system > >> wide monotonically increasing. So there are no issues with varying clock > >> frequency or rescheduling to a different core, you get elapsed time at > >> nanosecond accuracy. > > > > ... but that's not what you _want_ for a benchmark! You don't want the time > > to tick up while the benchmark process is preempted (not executing on _any_ > > core), for instance. Or am I misunderstanding what this is used for? > > Basically it is a lower overhead version of clock_get_time (CLOCK_MONOTONIC) > so you can use it to benchmark even small bits of code (since it doesn't insert > extra function calls or affect register allocation in a major way). > > We don't strictly need to scale the result, you could just subtract the counts. > However it makes the result equivalent to clock_get_time and allows one to > compute bytes copied/ns if needed or compare different CPUs. > > It's hard to account for the effects of interrupts or preemption. And GLIBC > benchtests aren't all that smart either, so I often end up having to increase the > iteration count to average out the OS effects (including frequency scaling). > We could improve this, eg. take several samples at lower iteration counts > and only report the fastest one. If it's a long running benchmark (increased iteration count) then the OS preemption effect should scale up and the constant cost of the 2x function calls / going to the OS for getting the time should scale down proportionally. Maybe we just need two timer apis for `TIMING_NOW_LONG` and `TIMING_NOW_SHORT`? > > Cheers, > Wilco