https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
Bug ID: 63400 Summary: [C++11]precision of std::high_resolution_clock Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: frankhb1989 at gmail dot com ISO C++ specifies high_resolution_clock "represent clocks with the shortest tick period". The comment in <chrono> also says it is "with the shortest tick period". However, the current implementation in <chrono> simply treats high_resolution_clock as an alias of system_clock, which does not actually meet it well in some platforms like MinGW-W64 and leads to strange problem. For example, the following program (copied and modified a little from http://sourceforge.net/p/mingw-w64/mailman/message/31672495/) does not work well using MSYS2 G++ 4.9.1: 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'; } } If 'high_resolution_clock' is changed back to 'steady_clock' as the original one, it performs significantly better. This is indeed misleading for users who have not dig deeply into the implementation details. The workaround for client code is straightforward: just use a new alias to wrap and to replace the current 'std::high_resolution_clock'. But only libstdc++ can fix it, e.g. use some templated black magic to detect which clock is preferred for "high resolution", or at least make it configurable for specific targets. Note: 1. The original program *did not* have this problem when using G++ 4.7.x (before the inline namespace std::chrono::_V2 introduced in libstdc++), because 'steady_clock' was then a buggy alias of 'system_clock', so both were *equally* badly implemented on MinGW-W64. 2. The suggested fix may have impact on current implementation, e.g. PR 54562.