Гарантировано ли разрешение gettimeofday () в микросекундах?

Может быть. Но у тебя проблемы посерьезнее. gettimeofday() может привести к неправильному таймингу, если в вашей системе есть процессы, изменяющие таймер (например, ntpd). Однако на "нормальном" Linux разрешение gettimeofday() составляет 10 мкс. Он может перемещаться вперед и назад и, следовательно, во времени, в зависимости от процессов, запущенных в вашей системе. Это фактически дает ответ на ваш вопрос нет.

Вам следует изучить clock_gettime(CLOCK_MONOTONIC), чтобы узнать о временных интервалах. Он страдает от нескольких меньших проблем из-за таких вещей, как многоядерные системы и настройки внешних часов.

Также обратите внимание на функцию clock_getres().

Высокое разрешение, низкие затраты времени для процессоров Intel

Если вы используете оборудование Intel, вот как прочитать счетчик команд процессора в реальном времени. Он сообщит вам количество циклов процессора, выполненных с момента загрузки процессора. Это, вероятно, самый точный счетчик, который вы можете получить для измерения производительности.

Обратите внимание, что это количество циклов процессора. В Linux вы можете получить скорость процессора из / proc / cpuinfo и разделить, чтобы получить количество секунд. Преобразование этого в двойное очень удобно.

Когда я запускаю это на своей коробке, я получаю

11867927879484732
11867927879692217
it took this long to call printf: 207485

Вот руководство разработчика Intel, в котором содержится множество подробностей.

#include <stdio.h>
#include <stdint.h>

inline uint64_t rdtsc() {
    uint32_t lo, hi;
    __asm__ __volatile__ (
      "xorl %%eax, %%eax\n"
      "cpuid\n"
      "rdtsc\n"
      : "=a" (lo), "=d" (hi)
      :
      : "%ebx", "%ecx");
    return (uint64_t)hi << 32 | lo;
}

main()
{
    unsigned long long x;
    unsigned long long y;
    x = rdtsc();
    printf("%lld\n",x);
    y = rdtsc();
    printf("%lld\n",y);
    printf("it took this long to call printf: %lld\n",y-x);
}

@ Бернард:

Должен признаться, большинство ваших примеров пролетело мимо меня. Он компилируется и, похоже, работает. Это безопасно для систем SMP или SpeedStep?

Хороший вопрос ... Думаю, код в порядке. С практической точки зрения мы используем его в моей компании каждый день, и мы работаем на довольно большом количестве компьютеров, начиная с 2-8 ядер. Конечно, YMMV и т. Д., Но это кажется надежным и низкозатратным (потому что он не переключает контекст в системное пространство) методом синхронизации.

В общем, как это работает:

• объявить блок кода ассемблерным (и изменчивым, поэтому оптимизатор оставит его в покое).
• выполнить инструкцию CPUID. Помимо получения некоторой информации о ЦП (с которой мы ничего не делаем), он синхронизирует буфер выполнения ЦП, чтобы на тайминги не влияло выполнение вне очереди.
• выполнить выполнение rdtsc (метка времени чтения). Это извлекает количество машинных циклов, выполненных с момента перезагрузки процессора. Это 64-битное значение, поэтому при текущей скорости процессора оно будет меняться каждые 194 года или около того. Интересно, что в исходном описании Pentium они отмечают, что он обновляется примерно каждые 5800 лет или около того.
• последние несколько строк сохраняют значения из регистров в переменных hi и lo и помещают их в 64-битное возвращаемое значение.

Конкретные примечания:

• выполнение вне очереди может привести к неверным результатам, поэтому мы выполняем инструкцию cpuid, которая помимо предоставления некоторой информации о процессоре также синхронизирует выполнение любой инструкции вне очереди.

• Большинство ОС синхронизируют счетчики на ЦП при запуске, поэтому ответ будет правильным с точностью до пары наносекунд.

• Комментарий о гибернации, вероятно, верен, но на практике вы, вероятно, не заботитесь о времени перехода через границы гибернации.

• относительно скорости: новые процессоры Intel компенсируют изменения скорости и возвращают скорректированный счетчик. Я быстро просмотрел некоторые коробки в нашей сети и нашел только одну коробку, на которой этого не было: Pentium 3, на котором запущен какой-то старый сервер базы данных. (это ящики Linux, поэтому я проверил: grep constant_tsc / proc / cpuinfo)

• Я не уверен насчет процессоров AMD, мы в первую очередь магазин Intel, хотя я знаю, что некоторые из наших системных гуру низкого уровня проводили оценку AMD.

Надеюсь, это удовлетворит ваше любопытство, это интересная и (ИМХО) недостаточно изученная область программирования. Вы знаете, когда Джефф и Джоэл говорили о том, должен ли программист знать C? Я кричал им: «Эй, забудьте про эти высокоуровневые C ... ассемблер - это то, что вам нужно изучить, если вы хотите знать, что делает компьютер!»

Возможно, вас заинтересует FAQ по Linux для clock_gettime(CLOCK_REALTIME)

Wine на самом деле использует gettimeofday () для реализации QueryPerformanceCounter () и, как известно, заставляет многие игры для Windows работать на Linux и Mac.

Запускает http://source.winehq.org/source/dlls/kernel32/cpu.c#L312

ведет к http://source.winehq.org/source/dlls/ntdll/time.c#L448

Таким образом, он явно говорит о микросекундах, но говорит, что разрешение системных часов не указано. Я полагаю, что разрешение в этом контексте означает, насколько оно будет увеличено на минимальную величину?

Структура данных определяется как имеющая микросекунды в качестве единицы измерения, но это не означает, что часы или операционная система действительно способны измерять это точно.

Как предполагали другие люди, gettimeofday() - это плохо, потому что установка времени может привести к смещению часов и сбить с толку ваши вычисления. clock_gettime(CLOCK_MONOTONIC) это то, что вы хотите, а clock_getres() сообщит вам точность ваших часов.

Фактическое разрешение gettimeofday () зависит от архитектуры оборудования. Процессоры Intel, а также машины SPARC предлагают таймеры с высоким разрешением, измеряющие микросекунды. В других аппаратных архитектурах используется системный таймер, который обычно устанавливается на 100 Гц. В таких случаях разрешение по времени будет менее точным.

Я получил этот ответ от Измерение времени и таймеры с высоким разрешением, Часть I

В этом ответе упоминаются проблемы с настройкой часов. И ваши проблемы с гарантией тиков, и проблемы с корректировкой времени решены в C ++ 11 с помощью библиотеки <chrono>.

Часы std::chrono::steady_clock гарантированно не будут отрегулированы, и, кроме того, они будут двигаться с постоянной скоростью относительно реального времени, поэтому такие технологии, как SpeedStep, не должны влиять на него.

Вы можете получить типизированные единицы, преобразовав одну из std::chrono::duration специализаций, например std::chrono::microseconds. С этим типом нет двусмысленности в единицах измерения, используемых значением тика. Однако имейте в виду, что часы не обязательно имеют такое разрешение. Вы можете преобразовать продолжительность в аттосекунды, не имея на самом деле точных часов.

Исходя из моего опыта и того, что я читал в Интернете, ответ - «Нет», это не гарантируется. Это зависит от скорости процессора, операционной системы, версии Linux и т. Д.

Чтение RDTSC ненадежно в системах SMP, поскольку каждый ЦП поддерживает свой собственный счетчик, и синхронизация каждого счетчика с другим ЦП не гарантируется.

Я могу предложить попробовать clock_gettime(CLOCK_REALTIME). В руководстве по posix указано, что это должно быть реализовано во всех совместимых системах. Он может обеспечивать счетчик наносекунд, но вы, вероятно, захотите проверить clock_getres(CLOCK_REALTIME) в своей системе, чтобы узнать фактическое разрешение.