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.
