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.
