From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 43ADE385DC0A; Fri,  8 Mar 2024 15:03:51 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 43ADE385DC0A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1709910231;
	bh=UJj62dQnKY+ZzUobdUR2idRDDuvmyPjOwdx3JSkI3nQ=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=XF12TuHhduNhrqmarqo/oG8yZ+DzD5tA8mLU4glPejn8q6oGqOXfGmFT0XDkVCXK7
	 FyTy1mTHnnBVsimK8uPVudFEdYeVgRTavzkPbrmNKjyDpcWEw5o97fIzCMN+ki5AJO
	 o59jcdBZEElxp4hdC3/++2SVTWKtibg9xdn9EB3Q=
From: "vz-gcc at zeitlins dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/63400] [C++11]precision of
 std::chrono::high_resolution_clock
Date: Fri, 08 Mar 2024 15:03:49 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: minor
X-Bugzilla-Who: vz-gcc at zeitlins dot org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-63400-4-n4t0UpfcCa@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63400-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63400-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D63400

--- Comment #16 from Vadim Zeitlin <vz-gcc at zeitlins dot org> ---
(In reply to Jonathan Wakely from comment #15)
> (In reply to Jonathan Wakely from comment #14)
> > Or maybe the testcase makes invalid assumptions and isn't really measur=
ing
> > what it thinks it's measuring?
>=20
> e.g. maybe clock_getres says 100ns even though the clocks aren't really t=
hat
> precise.

No, the clock is not precise. The original test case

int main() {
  for (unsigned long long size =3D 1; size < 10000000; size *=3D 10) {
    auto start =3D std::chrono::high_resolution_clock::now();
    std::vector<int> v(size, 42);
    auto end =3D std::chrono::high_resolution_clock::now();
    auto elapsed =3D end - start;
    std::cout << size << ": " << elapsed.count() << '\n';
  }
}

outputs the following under Linux

% ./a.out=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
1: 436
10: 114
100: 80
1000: 1019
10000: 9499
100000: 104850
1000000: 686436

and this under Windows:

% ./a.exe
1: 1000
10: 0
100: 0
1000: 1000
10000: 9000
100000: 69000
1000000: 523000=