From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by sourceware.org (Postfix) with ESMTPS id CF0003858C74 for ; Thu, 12 Jan 2023 18:54:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CF0003858C74 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=owlfolio.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=owlfolio.org Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id DF8D0320085B; Thu, 12 Jan 2023 13:54:28 -0500 (EST) Received: from imap45 ([10.202.2.95]) by compute1.internal (MEProxy); Thu, 12 Jan 2023 13:54:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=owlfolio.org; h= cc:cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1673549668; x=1673636068; bh=LY1zEATTZP yz5Hl41zctEpTnUGZNAoXRPllm4wzTi1A=; b=HD1W+GifarPSpdxMC1C1SIBF0P rue6dBaJuwCpge0cMgPzBzjuSPWVUOXOOgmczr0CmYOJG1Jl8uZ5+a4NL3U3UDF+ XqgxQ/kPRqmishTLPnW6OVu9YWhjs5acoVDfFaCdl0HRQTIwvi6ljz7x9AM/x5Yl cpK18QjKzHhDIVvaF0hL35hO3ftztZBBBs8TLRMIWdvf4XXXP0qeagCJZDTRl3YT QKxtg5yway3BBql236WFibjDoSjE07KFkD/nuFkjLrSwEvytMC0a9QtSpy1e2bpi PSgLCoIsBFfZDzhhIuQHACTR4jOiIoUp61jGDn1OxcWUY1eUQUG7iO77aGbw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1673549668; x=1673636068; bh=LY1zEATTZPyz5Hl41zctEpTnUGZN AoXRPllm4wzTi1A=; b=jIunR9uoHgyIVBCu7fGXwCqlu/ylfJ0XyCFZVPY/PVr+ yWt5cmEXczCQFClhipSGcXF3J+/XpiWrCkzal+7Aa3WdFCuCqihKCHtVVoJ5ROdu 4EiWOfNvCwsDlpvMkzfb4QpC31kY4pxxOdQYX/wtOsnF1YBQ4Jm2KdEh1EkH5i8f kBWPDf+gmJgr4Txwsd+0trdQkbDZvn7IFiBvzxh5FVd1d5t93JApD2tjjIi3YjFT rNyxFNwJcrBxNNjpj8eTyYVg7MXgI23xNYxRPjCwPR72pEqviqnxHtNIEgt/Xjoh qLh1XS+C6kFZX+8Iva2kx6BI8sVi/LPNURNF4pKL1w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrleeigdduudelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedfkggr tghkucghvghinhgsvghrghdfuceoiigrtghksehofihlfhholhhiohdrohhrgheqnecugg ftrfgrthhtvghrnhephfelfeehudfhleegheegjeevheeuieehvdfgueeuteetleeiieet heefhfeludeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepiigrtghksehofihlfhholhhiohdrohhrgh X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 20DB8272007A; Thu, 12 Jan 2023 13:54:28 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-1185-g841157300a-fm-20221208.002-g84115730 Mime-Version: 1.0 Message-Id: <31276f46-5376-4c2c-85c7-ffa08e9a771d@app.fastmail.com> In-Reply-To: References: Date: Thu, 12 Jan 2023 13:54:06 -0500 From: "Zack Weinberg" To: "Wilco Dijkstra" , "Tang, Jun" Cc: "GNU libc development" Subject: Re: bug fix for hp-timing.h (aarch64) Content-Type: text/plain X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,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 1:07 PM, Wilco Dijkstra wrote: > Hi Zack, > >> I'm surprised to hear you say that. To me, 16 seconds is an absurdly _long_ >> interval for use of hp-timing.h. For anything longer than a few tens of >> milliseconds, the overhead of two system calls is negligible, but both CPU >> frequency changes and getting descheduled in the middle of the >> measurement become serious concerns. So it seems more appropriate to >> me to use clock_gettime with a per-process or per-thread clock ID for >> measurements on the scale of tens of seconds. > > 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? zw