[Bug libstdc++/59177] New: steady_clock::now() and system_clock::now do not use the vdso (and are therefore very slow)

[luto at mit dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59177

            Bug ID: 59177
           Summary: steady_clock::now() and system_clock::now do not use
                    the vdso (and are therefore very slow)
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: luto at mit dot edu

std::chrono::steady_clock::now() does this:

#ifdef _GLIBCXX_USE_CLOCK_GETTIME_SYSCALL
      syscall(SYS_clock_gettime, CLOCK_MONOTONIC, &tp);
#else
      clock_gettime(CLOCK_MONOTONIC, &tp);
#endif

I'm not sure what the intent of this condition is, but the effect is that
glibc's clock_gettime (which is very carefully optimized and avoids using
syscalls) is ignored in favor of using syscall(2) (which is very slow).

This appears to have been introduced by this commit:

http://gcc.gnu.org/ml/libstdc++/2013-05/txtfX2KusGj9C.txt

It's a serious slowdown:

steady_clock::now(): 0.0933114µs per iteration
clock_gettime: 0.0230129µs per iteration

as measured by:

#include <chrono>
#include <iostream>
#include <time.h>
using namespace std;

constexpr int iters = 10000;
typedef chrono::duration<double> dsecs;

int main()
{
  auto start = chrono::steady_clock::now();
  for (int i = 0; i < iters; i++)
    chrono::steady_clock::now();
  auto end = chrono::steady_clock::now();

  std::cout << "steady_clock::now(): " << 1e6 *
chrono::duration_cast<dsecs>(end-start).count() / iters << "µs per
iteration\n";

  start = chrono::steady_clock::now();
  timespec ts;
  for (int i = 0; i < iters; i++)
    clock_gettime(CLOCK_MONOTONIC, &ts);
  end = chrono::steady_clock::now();

  std::cout << "clock_gettime: " << 1e6 *
chrono::duration_cast<dsecs>(end-start).count() / iters << "µs per
iteration\n";
}

system_clock appears to behave identically.