В современной разработке на C++ управление временем и точность измерения интервалов играют ключевую роль. Особенно это важно при создании многопоточных приложений, работе с таймингом и планировщиками задач, где от качественного отсчёта времени зависит корректность всей системы. В стандартной библиотеке C++17 и выше для этой цели предусмотрен набор классов в пространстве имён std::chrono, среди которых существует std::chrono::high_resolution_clock — часы с максимально возможной точностью, предоставляемые конкретной реализацией платформы. Однако, несмотря на распространённость высокоточных часов, многие разработчики задаются вопросом: почему в стандарте отсутствует аналог low_resolution_clock, который бы предоставлял часы с низкой точностью, но меньшими затратами на вычисление времени? Рассмотрим эту дилемму подробнее, обсудим технические аспекты и узнаем, каким образом можно эффективно решать подобные задачи в реальных условиях. Для начала важно понять, что std::chrono::high_resolution_clock — это тип часов, который предоставляет таймер с наименьшим периодом тика на данной платформе.
Это означает максимально мелкие временные шаги, аж вплоть до наносекунд, если это поддерживается аппаратной частью и операционной системой. Такие часы удобны для измерения коротких временных интервалов, профилирования кода, или задач, где критична точность. Но с повышением точности приходит и ценник — время получения текущего значения часов может вырасти, ведь аппаратно-программный механизм может требовать затрат на системные вызовы, чтение специальных регистров, синхронизацию и т.п. В некоторых случаях, особенно когда высокий уровень детализации не нужен, использование высокоточных часов — это просто излишняя трата ресурсов.
К тому же, нередко разработчики хотят измерять большие интервалы времени с «грубой» точностью, например, с шагом миллисекунд, десятков миллисекунд или больше. Для таких задач не обязательно заморачиваться слишком точным счётчиком. Тогда и возникает логичный вопрос — зачем нет встроенного low_resolution_clock, который бы отдавал текущее время максимально быстро, пусть с меньшей точностью? Ответ частично кроется в философии стандарта C++. Стандарт стремится предоставить разработчикам надёжные и максимально общие средства, которые одинаково хорошо работают во всех системах. Концепция low resolution clock весьма относительна — «низкая точность» зависит от конкретного случая, устройства и ОС.
Например, на Windows есть функция GetTickCount64, которая возвращает время в миллисекундах с относительно небольшой частотой обновления, порядка 10-16 миллисекунд. На Linux можно использовать CLOCK_MONOTONIC_COARSE, дающий сглаженные усреднённые показания с приблизительной точностью в миллисекунды. Но в разных системах и процессорах детали будут различаться. Принципиально, стандарт не захотел вводить новый тип часов с неопределённым поведением или критично низкой точностью без чёткого контракта. Поэтому оставил разработчикам право самим решать эту задачу, используя платформенно-специфичные средства, когда это необходимо.
Железо и ОС предоставляют нужные интерфейсы, но стандартизованные средства — только высокоточечные и системные часы. Однако, разработчики часто нуждаются именно в быстром и достаточно стабильном и основанном на steady-clock, но при этом «дешёвом» решении. В своем блоге Рэймонд Чен, известный сотрудник Microsoft, рассказал о практическом подходе к решению этой проблемы. Он предложил создать собственный тип cheap_steady_clock, который бы обеспечивал достаточно приемлемую пунктуальность (steadiness) и при этом был бы максимально лёгким по стоимости. Для Windows в качестве источника времени использовалась именно GetTickCount64: он предоставляет значение в миллисекундах, обновляется примерно раз в 10-16 мс, что вполне достаточно для планирования спящих интервалов и менее критичных по времени задач.
Сами часы cheap_steady_clock реализованы так, чтобы поддерживать типы и интерфейсы, совместимые с std::chrono, включая duration и time_point. Это позволяет интегрировать их напрямую с остальным кодом, не меняя логику работы, при этом снизив накладные расходы на получение времени. Аналогично, в Linux предложено использовать CLOCK_MONOTONIC_COARSE через вызов clock_gettime — эта возможность доступна в современных ядрах. Он обеспечивает монотонность и разрешение в районе 1-4 миллисекунд, что приемлемо для большинства сценарием, где точность в наносекундах не требуется, а главное — ускорено чтение таймера. При этом нестандартная ситуация с необходимостью бросать исключение в noexcept методе now, если считывание времени не удалось, подчёркивает серьёзность подхода — подчеркивается, что при невозможности получить время происходит аварийное завершение программы, поскольку невозможно продолжать корректную работу.
Это отражает баланс между простотой API и реальными ограничениями низкоуровневых вызовов. Еще один момент, который стоит учитывать — стабильность (steadiness) часов. В C++ steady_clock гарантирует, что время не снизится, а только растет с течением процесса или системы. Использовать системные часы, которые могут прыгать или синхронизироваться, во многих задачах нежелательно. Предложенный cheap_steady_clock соответствуют этому требованию, что позволяет избежать неожиданных откатов времени из-за синхронизации часов или изменений в системных настройках.
Разумеется, высокоточные часы не всегда и не всем нужны. В системах реального времени или при профилировании кода важно измерять время до наиболее точных единиц, однако если задача — просто приостановить поток на одну секунду или отследить приблизительное время, достаточно millisecond accuracy, что позволит сэкономить ресурсы и упростить логику. С технической точки зрения, если говорить про существующие стандартные часы, в C++ их три основных типа: system_clock, steady_clock и high_resolution_clock. При этом high_resolution_clock может быть синонимом любого из двух предыдущих в зависимости от реализации. Но none делает явного low_resolution_clock.
Поэтому, если нужно именно «низкозатратные» часы с гарантированной устойчивостью, стоит реализовать собственные, опираясь на стандарты и методы операционной системы. В целом отсутствие std::chrono::low_resolution_clock отражает компромисс между универсальностью, переносимостью кода и потребностями большинства разработчиков. Производители ОС предоставляют разные таймеры с разными характеристиками, а стандарт C++ универсален и не может просто выбрать один «низкозатратный» таймер без риска потери переносимости и возникновения путаницы. Из практики можно порекомендовать при написании кроссплатформенного кода для сервисов и приложений, где время измеряется достаточно примерно, задумываться именно о cheap_steady_clock или аналоге, полностью контролируемом внутри приложения. Такая реализация даёт возможность подстроиться под возможности конкретной ОС и выполнить баланс точности и стоимости получения времени.
Особенно это актуально для систем с ограниченными ресурсами, встроенных приложений и многопоточных задач, где частое получение времени может стать узким местом производительности. В заключение стоит напомнить, что при выборе часов для своего проекта важно понимать требования к точности и нагрузке. Не всегда максимальная точность — залог успеха. Иногда лучше сделать систему предсказуемой и эффективной, пожертвовав несколькими наносекундами. Отсутствие low_resolution_clock — не проблема, а возможность гибко ориентироваться на особенности платформы, создавая для каждой задачи оптимальное решение.
Такой подход, продемонстрированный на примере cheap_steady_clock от Рэймонда Чена, показывает, как можно обойти ограничения стандарта и при этом получить максимально удобный и эффективный инструмент. Благодаря этому разработчики получают шанс строить продуктивные приложения, правильно выбирая между высокоточной синхронизацией времени и лёгкими, дешёвыми таймерами для менее требовательных сценариев. Таким образом, понимание различий между различными видами часов и умение реализовывать собственные адаптированные решения позволяет более эффективно использовать ресурсы системы и писать качественный, оптимизированный код. Важно следить за возникающими нововведениями стандарта C++ и новыми возможностями ОС, поскольку область тайминга — одна из динамично развивающихся, и инструменты постоянно совершенствуются.
