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

2024-03-08 Thread vz-gcc at zeitlins dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 --- Comment #16 from Vadim Zeitlin --- (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

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

2024-03-08 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 --- Comment #15 from Jonathan Wakely --- (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

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

2024-03-08 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 --- Comment #14 from Jonathan Wakely --- Thanks! So does that mean mingw-w64 fixed the issue by improving the resolution of CLOCK_REALTIME? In that case, this bug could be closed WORKSFORME. Or maybe the testcase makes invalid assumptions and

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

2024-03-08 Thread vz-gcc at zeitlins dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 --- Comment #13 from Vadim Zeitlin --- (In reply to Jonathan Wakely from comment #11) > (In reply to Jonathan Wakely from comment #8) > > Is this still an issue in 2022? > > > > Using a mingw-w64 cross-compiler and running under Wine I get: > >

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

2024-03-08 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 --- Comment #12 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #10) > GetSystemTimePreciseAsFileTime gives UTC, so would need adjustment for leap > seconds to turn it into a sys_time. That's doable though. Doable, but it

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

2024-03-08 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 --- Comment #11 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #8) > Is this still an issue in 2022? > > Using a mingw-w64 cross-compiler and running under Wine I get: > > CLOCK_REALTIME: 0,100 > CLOCK_MONOTONIC: 0,100 > >

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

2024-03-08 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 --- Comment #10 from Jonathan Wakely --- GetSystemTimePreciseAsFileTime gives UTC, so would need adjustment for leap seconds to turn it into a sys_time. That's doable though. Alternatively, we could use it to implement a high performance

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

2022-07-15 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 --- Comment #9 from Jonathan Wakely --- (In reply to frankhb1989 from comment #4) > For CLOCK_REALTIME, the Windows API GetSystemTimeAsFileTime is used. > GetSystemTimePreciseAsFileTime is an improved version which provide "the > highest

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

2022-07-14 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 --- Comment #8 from Jonathan Wakely --- (In reply to frankhb1989 from comment #4) > With mingw-w64, the following program shows that the monotonic clock is far > more precise: > > #include > #include > > int main() > { > using

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

2022-07-14 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 --- Comment #7 from Jonathan Wakely --- (In reply to frankhb1989 from comment #5) > BTW, what if the clock_gettime call failed? The current implementation does > nothing about error handling... (Though for QPC on Windows it should rarely > fail

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

2014-09-30 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- Maybe we should make high_resolution_clock a typedef for steady_clock on mingw-w64 but maybe only when using winpthreads.

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

2014-09-29 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Target||mingw-w64 ---

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

2014-09-29 Thread frankhb1989 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 --- Comment #2 from frankhb1989 at gmail dot com --- (In reply to Jonathan Wakely from comment #1) Which of macros are defined on mingw-w64? Preprocessing this should tell you #include chrono #ifdef _GLIBCXX_USE_CLOCK_REALTIME #ifdef

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

2014-09-29 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- What libstdc++ is doing is sensible, why is the realtime clock so much coarser than the monotonic clock on mingw-w64?

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

2014-09-29 Thread frankhb1989 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 --- Comment #4 from frankhb1989 at gmail dot com --- (In reply to Jonathan Wakely from comment #3) What libstdc++ is doing is sensible, why is the realtime clock so much coarser than the monotonic clock on mingw-w64? It is not always true that

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

2014-09-29 Thread frankhb1989 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 --- Comment #5 from frankhb1989 at gmail dot com --- BTW, what if the clock_gettime call failed? The current implementation does nothing about error handling... (Though for QPC on Windows it should rarely fail for machines within a decade.)