[Bug libstdc++/63400] [C++11]precision of std::chrono::high_resolution_clock

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

Zhongteng Gui <dragon-archer at outlook dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dragon-archer at outlook dot com

--- Comment #17 from Zhongteng Gui <dragon-archer at outlook dot com> ---
(In reply to Vadim Zeitlin from comment #16)
> (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 measuring
> > > what it thinks it's measuring?
> > 
> > e.g. maybe clock_getres says 100ns even though the clocks aren't really that
> > precise.
> 
> No, the clock is not precise. The original test case
> 
> int main() {
>   for (unsigned long long size = 1; size < 10000000; size *= 10) {
>     auto start = std::chrono::high_resolution_clock::now();
>     std::vector<int> v(size, 42);
>     auto end = std::chrono::high_resolution_clock::now();
>     auto elapsed = end - start;
>     std::cout << size << ": " << elapsed.count() << '\n';
>   }
> }
> 
> outputs the following under Linux
> 
> % ./a.out               
> 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

I think this should have been fixed. Tested with GCC 16.2.0 and mingw-w64
14.0.0, it produces:

$ ./a.exe
1: 1500
10: 400
100: 1700
1000: 900
10000: 17700
100000: 81600
1000000: 826500

I think this matches the 100ns resolution.