From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by sourceware.org (Postfix) with ESMTPS id E11E93858C66 for ; Thu, 12 Jan 2023 15:12:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E11E93858C66 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 C8A0732007D7 for ; Thu, 12 Jan 2023 10:12:12 -0500 (EST) Received: from imap45 ([10.202.2.95]) by compute1.internal (MEProxy); Thu, 12 Jan 2023 10:12:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=owlfolio.org; h= 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=1673536332; x=1673622732; bh=mFNNkhlRhr oRDC0x3N8CYWb/e1cwD8a691pphKlHlPw=; b=nJh9zRuyPqsdeGXnkxtHKor5kH NzQhoDpdOsXVcg6MYwdzdqfFKafAO6PdLzMA6TDZale4ZYO5wwadYYIAx2867QXd IrjlbfRMNAyOpGbn1MTP12kJY7TI+mDIVxnLCfArEg10OQXMVgELxRa7u1/omQJ6 b7sC3fAnEYhdF06EBBrrVafb1TtA+vwsIdrAmJP4JcauPNBcdwvOs2Xiq5nnUH3S L5DK2W1+MhDZqSC6UMPbNBbNVBhEL5gnStBhJfAyoJ98aXDuG4eaJN1DfGY/TfkS G5M0leu0xrtmpJW/BUvw8v4KOiiW3b4h5t80j8JeMU8rwJ+NIYMTjVCuOgOA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=1673536332; x=1673622732; bh=mFNNkhlRhroRDC0x3N8CYWb/e1cw D8a691pphKlHlPw=; b=PjkAT9oZ1HeCkB26dJlv+Cx5m8IxC4lQ/vXwvXe4Ou2l 4Oy7m7Eq4t447BclHE5Na+/xhdNt+E3YZ6NcLDbnrlRYYHjwX821YWVo8LYblo/g tE0R3nESeXAq80jYpUYk//pXADepoelqfJNo8f+vSD6DWhCxM7RJJRjaYHktAAlg W98uNoe2bLtKIFv/k34DDJsT9ffeICvdSPLuk0SHyJclXJj18w7cH4sPC4xwDzaQ e0oREHHWnV+foMBkJSJU7s/+iE9RaCLdIOJfSvdImAQrSR1y5pa2jkQGGSf1QELx uz8Mzl8GRFHOMSzNebvbEfokmFVLg9mU2vtCqE1gnQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrleeigdejfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfkggrtghk ucghvghinhgsvghrghdfuceoiigrtghksehofihlfhholhhiohdrohhrgheqnecuggftrf grthhtvghrnhephfeuhfevueffteffgfejtefgkeekheeftdeflefgheffffevheekleef gfehffdunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epiigrtghksehofihlfhholhhiohdrohhrgh X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1BCAC272007A; Thu, 12 Jan 2023 10:12:12 -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: In-Reply-To: References: Date: Thu, 12 Jan 2023 10:11:46 -0500 From: "Zack Weinberg" To: "GNU libc development" Subject: Re: bug fix for hp-timing.h (aarch64) Content-Type: text/plain X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_LOW,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 Wed, Jan 11, 2023, at 5:49 PM, Wilco Dijkstra via Libc-alpha wrote: >> - (Diff) = ((End) - (Start)) * (UINT64_C(1000000000) / freq); \ >> + (Diff) = (((End) - (Start)) * UINT64_C(1000000000)) / freq; \ >> >> This avoids using floating-point arithmetic but should still do the rescale correctly. > > However this will overflow after about 16 seconds - and that's short > even for basic benchmarking. 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. This isn't a sustained objection to the patch, I just want to understand where you're coming from. zw