Пока у меня была чисто последовательная прога — особо не заморачивался.
Для грубой оценки времени работы использовал просто clock().
Теперь в паре мест появились треды и clock() вроде как выдает не совсем то, что есть на самом деле.
Посоветуйте:
— либо использовать стандартную либу chrono
— либо WinAPI-функцию (кстати, мудреное название — никак не запомню... )
Надо поизмерять время для построения графиков в статью. Поэтому миллисекунды вполне сгодятся...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Пока у меня была чисто последовательная прога — особо не заморачивался. LVV>Для грубой оценки времени работы использовал просто clock().
clock() возвращает CPU-time
LVV>Теперь в паре мест появились треды и clock() вроде как выдает не совсем то, что есть на самом деле.
LVV>Посоветуйте: LVV>- либо использовать стандартную либу chrono LVV>- либо WinAPI-функцию (кстати, мудреное название — никак не запомню... )
чтобы что-нибудь посоветовать, нужно знать что-нибудь про объект измерения, может вам rdtsc нужно использовать?
LVV>Надо поизмерять время для построения графиков в статью. Поэтому миллисекунды вполне сгодятся...
LVV>>Пока у меня была чисто последовательная прога — особо не заморачивался. LVV>>Для грубой оценки времени работы использовал просто clock(). CK>clock() возвращает CPU-time
Ну, дык мне и нормально было... LVV>>Посоветуйте: LVV>>- либо использовать стандартную либу chrono LVV>>- либо WinAPI-функцию (кстати, мудреное название — никак не запомню... ) CK>чтобы что-нибудь посоветовать, нужно знать что-нибудь про объект измерения, может вам rdtsc нужно использовать?
Это вряд ли. LVV>>Надо поизмерять время для построения графиков в статью. Поэтому миллисекунды вполне сгодятся... CK>Если совсем не важно что там да как, то можно просто через time измерять время работы всего приложения, но вообще тема сложная, люди книги по ней пишут (https://www.amazon.com/Guide-Experimental-Algorithmics-Catherine-McGeoch/dp/0521173019/ref=sr_1_1?ie=UTF8&qid=1465551699&sr=8-1&keywords=experimental+algorithmics).
Это все понятно.
Но мне достаточно следующего:
от 0 до 1 с шагом 0.0000...
Заполняется некая решетка.
Надо отследить накопляемое время на каждом шаге.
Если б это было в одном цикле — проблем нет.
Но алгоритм разбит на несколько частей и там под ногами мешаются пара мест с тредами.
Я вот нарыл на MSDN функцию QueryUnbiasedInterruptTime
С другой стороны в стандартной либе chrono есть steady_clock
В общем, я так понимаю, опять надо просто экспериментировать...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Надо поизмерять время для построения графиков в статью. Поэтому миллисекунды вполне сгодятся...
Если достаточно совсем простого, то std::chrono::high_resolution_clock.
Если хочется чего-то посложнее, то можно посмотреть вот в эту статью -- либо на сами фреймворки, либо на их реализации.
LVV>Надо поизмерять время для построения графиков в статью. Поэтому миллисекунды вполне сгодятся...
std::chrono сейчас в моде
мне так больше boost::posix_time понравилось, както понятнее, форматиерование в iso-стринг тут както уже
подходящее было и код короче и яснее получился
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, LaptevVV, Вы писали: LVV>>Надо поизмерять время для построения графиков в статью. Поэтому миллисекунды вполне сгодятся... Pzz>QueryPerformanceCounter() Pzz>Миллисекунды, кстати, не годятся. Рано или поздно захочется померить "расстояние" между принятыми подряд пакетами, а там времена микросекундные.
На многоядерных AMD был прикол с QueryPerformanceCounter
Этот счетчик для каждого ядра свой и ходят они в зависимости от частоты ядра. А она может меняться. Даже патч выпучкали котрый их синхронизировал переодически.
В результате когда на одной из машин стали получать ход времени в обратну сторону все очень повеселились. Пришлось внедрить костыль в виде установки affinity на одно ядро в таких случаях.
В результате в винде самый вменяемый таймер оказался мультимедийный таймер
его точность хода 1мс, у GetTickCount шаг 16мс (но бывает и 10мс)
Здравствуйте, kov_serg, Вы писали:
_>На многоядерных AMD был прикол с QueryPerformanceCounter _>Этот счетчик для каждого ядра свой и ходят они в зависимости от частоты ядра. А она может меняться. Даже патч выпучкали котрый их синхронизировал переодически.
Ну, насколько я понимаю, это так или иначе уже починили.
_>В результате в винде самый вменяемый таймер оказался мультимедийный таймер _>его точность хода 1мс, у GetTickCount шаг 16мс (но бывает и 10мс)
Насколько я помню, евонная точность является глобальным системным параметром, причем невозможно повысить ее временно, пока надо, а потом вернуть взад (т.е., технически, конечно, возможно, но если за это время другая программа сделает то же самое, а мы вернем таймер взад, то у другой программы случится неприятный сюрприз). А держать его все время на высокой точности может быть не очень хорошо в плане увеличения энергопотребления системы (для поделки это терпимо, а для продаваемой массовой программы не очень).
Здравствуйте, LaptevVV, Вы писали:
LVV>Заполняется некая решетка. LVV>Надо отследить накопляемое время на каждом шаге. LVV>Если б это было в одном цикле — проблем нет. LVV>Но алгоритм разбит на несколько частей и там под ногами мешаются пара мест с тредами.
Что получить-то надо ? Астрономическое время, которое все эти потоки работали или же время работы каждого потока ?
Если первое — QueryPerfomanceCounter/QueryPerfomanceFrequency перед запуском всей этой конструкции и после ее завершения.
Если второе — GetThreadTimes по каждому потоку в момент его окончания (делает основной поток в момент, когда дождался окончания дочернего потока)
Pzz>Ну, насколько я понимаю, это так или иначе уже починили. _>>В результате в винде самый вменяемый таймер оказался мультимедийный таймер _>>его точность хода 1мс, у GetTickCount шаг 16мс (но бывает и 10мс) Pzz>Насколько я помню, евонная точность является глобальным системным параметром, причем невозможно повысить ее временно, пока надо, а потом вернуть взад (т.е., технически, конечно, возможно, но если за это время другая программа сделает то же самое, а мы вернем таймер взад, то у другой программы случится неприятный сюрприз).
timeBeginPeriod()/timeEndPeriod() имеют внутренний "счетчик ссылок" и стратегию владения, потому свой timeBeginPeriod отменить можно, а чужой — не выйдет. Более того, неотмененные timeBeginPeriod-ы автоматом отменяются при издыхании процесса. Но надолго его захватывать без необходимости не нужно.
Как много веселых ребят, и все делают велосипед...
) 
