Я собрал в кучу разные методы, которые здесь уже фигурировали. Дополнительным преимуществом является то, что функция запоминает в статических переменных основные вычисления и применяет их, если день совпадает с днем из предыдущего обращения к функции. В реальности таких вызовов будет более 90%. Поэтому выйгрыш будет еще больше, чем в этом рандомном тесте. Но тест показывает, что данная функция примерно в три раза быстрее работает штатной.
Необходимо дополнительно напомнить, что корректно работает до 28 февраля 2100 года, т.к. не учитывается Григорианский календарь, в котором 2100 год не будет високосным.
Необходимо дополнительно напомнить, что корректно работает до 28 февраля 2100 года, т.к. не учитывается Григорианский календарь, в котором 2100 год не будет високосным.
в добавок у меня реализовано через статические переменные, что по идее должно замедлять тест рандомного времени и сильно ускорять на упорядоченном входном потоке времени.
Привет! Меня зовут Александр Каленюк, и я крепко подсел на C++. Пишу на C++ 18 лет кряду, и все эти годы отчаянно пытаюсь избавиться от этой разрушительной зависимости. Всё началось в конце 2005 года, когда мне довелось писать движок для симуляции 3D-пространства. В этом движке было буквально всё, чем язык C++ мог похвастаться в 2005 году...
Спасибо. Но все же в статье демонстрируются разницы в производительности для совсем разных железяк.
Здесь же отличаются Intel-камни.
Intel-камни, разнесенных во времени - это могут быть совсем разные железяки. Один и тот же код может выполняться совсем по разной логике внутри процессора. Система команд любого производителя тоже имеет свою эволюцию
Я собрал в кучу разные методы, которые здесь уже фигурировали.
Для сравнения скоростей предложенных методов (штатный неинтересен) имеет смысл делать только такую контрольную сумму.
uint mm =dt.year+ dt.mon+ dt.day/*+ dt.hour+ dt.min+ dt.sec+ dt.day_of_week+ dt.day_of_year*/;
DayOfYear - не представляю, для чего нужно. Внутрисуточное время (и день недели) - элементарно всегда. А вот первые три слагаемые - основная сложность, поэтому их реализации и стоит сравнивать. Как и обратный функционал.
Более быстрая функция TimeToStruct() для декодирования переменных времени суток, чтобы получить все компоненты даты и времени.
Некоторые части кода могут быть использованы повторно для извлечения интересующих компонентов по отдельности.
Бенчмарк:
Результаты:
думал что предложенный Вами вариант самый быстрый, но оказалось, что можно сделать еще быстрее:
Я собрал в кучу разные методы, которые здесь уже фигурировали.
Необходимо дополнительно напомнить, что корректно работает до 28 февраля 2100 года, т.к. не учитывается Григорианский календарь, в котором 2100 год не будет високосным.Дополнительным преимуществом является то, что функция запоминает в статических переменных основные вычисления и применяет их, если день совпадает с днем из предыдущего обращения к функции. В реальности таких вызовов будет более 90%. Поэтому выйгрыш будет еще больше, чем в этом рандомном тесте. Но тест показывает, что данная функция примерно в три раза быстрее работает штатной.
Я собрал в кучу разные методы, которые здесь уже фигурировали.
Добавил этот. x64.
Необходимо дополнительно напомнить, что корректно работает до 28 февраля 2100 года, т.к. не учитывается Григорианский календарь, в котором 2100 год не будет високосным.
Можно снять это ограничение добавкой эпох.
Можно снять это ограничение добавкой эпох.
Добавил этот. x64.
у меня на более новом камне другая картина
в добавок у меня реализовано через статические переменные, что по идее должно замедлять тест рандомного времени и сильно ускорять на упорядоченном входном потоке времени.
у меня на более новом камне другая картина
Тогда вопрос к разработчикам, почему для оптимального выполнения нужно создавать камне-зависимый код?
Тогда вопрос к разработчикам, почему для оптимального выполнения нужно создавать камне-зависимый код?
читаем эту статью
https://habr.com/ru/amp/publications/811151/
читаем эту статью
https://habr.com/ru/amp/publications/811151/
Спасибо. Но все же в статье демонстрируются разницы в производительности для совсем разных железяк.
Здесь же отличаются Intel-камни.
Спасибо. Но все же в статье демонстрируются разницы в производительности для совсем разных железяк.
Здесь же отличаются Intel-камни.
Я собрал в кучу разные методы, которые здесь уже фигурировали.