Мне кажется, Вы напрасно уводите разговор в сторону. То, как я работаю дома, это вряд ли кому-то интересно
Ну так и то, что в вашем конкретном случае, после того, как вы проделали некоторую работу, вы смогли автоматизировать runexe никак не значит, что автоматизировать метод из статьи не легче.
И потом только мы получим гарантию, функция из Вашей статьи работает правильно. Так или нет?
Фактически — так. Практически, лично я доверяю системным вызовам и стандартным библиотекам, например.
Абсолютной уверенности в том, что runexe работает лучше или хуже системных функций нет никаких.
Runexe, очевидно, использует системные функции. В частности, версия на которую ссылаетесь вы, использует QueryInformationJobObject, хотя на данный момент, судя по всему, всё уже переписано на Go.
Не знаю, что Вы ещё от меня хотите :)
Собственно от вас ничего больше и не хочу. Весь спор начался из-за вашего необоснованного предположения, что если у вас все работает, значит ваш метод не сложнее.
Так а Вы думаете, что у меня подход чем-то отличается от «запустил и пошёл спать»? :)
Эта проблема уже давно решена.
Думаю, что или вы пишете для этого дополнительный код (скрипты, аргументы), или делаете часть работы вручную (как в вышеупомянутой статье, перекомпилируете вручную N раз)
С этим кодом я и не спорю (пока), я выразил мнение о том, чем закачивается 99% попыток внедрить в свой код что-то другое.
Ну чужой код надо читать, а не бездумно копировать.
По поводу runexe — у меня пока не было нареканий к нему, так что это дело не веры, а проверки на сотнях тысячах запусках.
А вы каким-то образом его проверяли? Или это "по ощущениям"? Если бы вы могли мерить процессорное время "по ощущениям", то и программа не нужна была наверное ;) Вдруг там лишних 5-10% намеряется в особых случаях.
Вы ответили лишь на половину моих замечаний, при этом недооцениваете мой способ работы дома и то, что лично мне удобнее.
Я говорил конкретно об автоматизации бенчмарка — "запустил и пошел спать". Хотя вы и ответили, что автоматизировать со встроенной функцией не легче, но та самая половина замечаний отношения к автоматизации не имеет.
в силу доминирующей криворукости создателей подобного опенсорса
Код включает в себя вызов исключительно системных функций. При этом от криворукости создателя runexe вас никто не спасает, кроме вашей веры в него.
Что касается автоматизации, то со сторонними утилитами она решается, но иным способом, например, через cmd-файл
Если вы хотите сравнить две версии алгоритма, то в лоб еще скриптом не автоматизируешь. Или держать два проекта, или собирать вручную, или использовать аргументы при запуске.
А человечество выживет, если 90% будет бездельничать, а оставшиеся 10% — «создавать невероятные новые продукты и сервисы»? Убирать мусор, ухаживать за больными, строить дома, работать в шахтах и т.д. кто будет? Понятно, что потенциально это все автоматизируемо, но только потенциально ведь.
Так если RDTSC дает количество тактов, то, при условии что частота менялось по ходу выполнения процесса, переводить в секунды их тоже нельзя. Разве не так?
Что касается таких вот жутких функций, то встраивание их в мой код делает программу сложнее и не даёт гарантий, что она запустится у кого-то другого. Это против моих правил — давать код, который тяжело скомпилировать
Почему бы ей не скомпилироваться, если у нее никаких зависимостей, кроме стандартной билиотеки? Что тяжелого в компиляции, которая сводится к запуску компилятора?
runexe, в принципе, не требует поддержки сейчас
И, в принципе, не поддерживается, судя по сайту на мертвом Google Code и отсутсвию даже минимальной инструкции на этом самом сайте.
включать таймер до цикла тестирования и выключать после — это ничем по сути не отличается от тестирования внешней утилитой.
Отличается простотой автоматизации. Залез в ваш аккаунт и обнаружил, что как раз в вашей статье это всплыло.
Если ставить целью сделать код, который будет измерять процессорное время на любой машине и везде запускаться, то я затрачу уйму времени.
Это теория. На практике большая часть бенчмарков работает меньше суток, замеряет отрезки времени меньше суток, не требует абсолютной точности и т.д.
Ну а тот, у кого нестандартные задачи и кто гоняет задачи, съедающие сутки процессорного времени и при этом требующие микросекундной точности, должен разбираться сам.
Вот я и говорю – проработка материала в статье на уровне сообразительного школьника.
Так еще раз — никто и не претендует. Функция будет работать на среднем тесткейсе, запустится
на любой платформе (в отличие от вашего варианта, который даже на достаточно популярном ARM не пойдет). Да, наверняка можно придумать кучу кода, на которой она будет давать неточные результаты. Но при этом заморачиваться не надо, скопировал функцию, два раза вызвал — и вот они результаты. Если же нужно что-то супер-точное — пиши свой код, подходящий под конкретный случай.
Так вот и хочется знать, в частности, чему равен этот вызов функции в микросекундах (учитывая, что он включает неизвестные нам действия внутри libc и ядра).
Так как это зависит от кучи параметров, надо просто сделать замер на той системе, на которой это вас интересует.
Что здесь произойдёт, когда процесс работает более 24 часов?
В худшем случае — вы получите результат, на 86400 отличающийся от реального. Думаю, это не так уж и сложно заметить.
использовать ассемблерную вставку с RDTSC и не париться
А если у меня не только х86 или вообще не х86?
как момент вызова функции и момент возврата из функции соотносятся с моментом фиксации показаний таймера (в том числе, чему равен оверхед от её собственной работы, как разность между этими значениями);
Могу лишь предположить, что общий оверхед будет равен ровно одному вызову функции (мы считаем от фиксации до фиксации, в начальном измерении после фиксации будет учтен "конец" функции, в конечном — будет учтено "начало" функции)
что вызывает очевидный вопрос, что происходит в его функции с переходом через полночь, и менее очевидный вопрос, что происходит с удлинёнными минутами по 61 секунде (чем дальше, тем они появляются чаще в связи с удлинением астрономических суток).
Так как код не мой, то точно ответить вам не могу. Судя по всему, вы правы и результат будет таким же, разве что делить надо на другое число и взять остаток.
Лично я обычно меряю время в бенчмарках, то есть сравниваю результаты работы разных алгоритмов, или версий программы, или программ. Меня мало интересует абсолютная точность, даже если эта функция будет ошибаться каждый раз на 10%, это не важно так как относительные результаты будут верными.
Цели же рассмотреть в общем такую важную и сложную тему, как измерение времени на компьютере, автор перед собой не ставил. Он только описал, как решить конкретную проблему: кроссплатформенно замерить процессорное время процесса. Если вы можете предложить лучшее решение этой проблемы, буду рад его услышать.
Обычно, пользователя всё-таки интересует, какова производительность системы, приведённой к реальным единицам времени, а не с использованием удлинённых или укороченных секунд наугад взятого процессора с поехавшим тактовым генератором.
Обычно пользователя интересует субъективные ощущения от работы (быстро/медленно, тормозит/не тормозит), а не процессорное время.
Разработчика же интересуют либо величины в сравнении (два алгоритма, текущая версия vs. предыдущая и т.д.), либо порядок величины, т.к. скорость работы будет меняться от системы к системе достаточно сильно.
Но если вы хотите как-то распространить результат на другие системы, то единицы процентов, которые при известном стечении обстоятельств можно получить за счёт погрешности генератора, могут оказаться заслуживающими внимания.
Если я хочу распространить результат на конкретную другую систему, возможно. Может быть, при разработке какой-то супер критичной системы реального времени, где еле-еле получается уложится в выделенное время, это может сыграть злую шутку.
Но если я разрабатываю массовый софт и хочу прикинуть время выполнения на множестве других произвольных систем ("как это будет работать у пользователей?"), то эта погрешность будет незаметна.
Ну так и то, что в вашем конкретном случае, после того, как вы проделали некоторую работу, вы смогли автоматизировать runexe никак не значит, что автоматизировать метод из статьи не легче.
Фактически — так. Практически, лично я доверяю системным вызовам и стандартным библиотекам, например.
Runexe, очевидно, использует системные функции. В частности, версия на которую ссылаетесь вы, использует QueryInformationJobObject, хотя на данный момент, судя по всему, всё уже переписано на Go.
Собственно от вас ничего больше и не хочу. Весь спор начался из-за вашего необоснованного предположения, что если у вас все работает, значит ваш метод не сложнее.
Эта проблема уже давно решена.
Думаю, что или вы пишете для этого дополнительный код (скрипты, аргументы), или делаете часть работы вручную (как в вышеупомянутой статье, перекомпилируете вручную N раз)
Ну чужой код надо читать, а не бездумно копировать.
А вы каким-то образом его проверяли? Или это "по ощущениям"? Если бы вы могли мерить процессорное время "по ощущениям", то и программа не нужна была наверное ;) Вдруг там лишних 5-10% намеряется в особых случаях.
Я говорил конкретно об автоматизации бенчмарка — "запустил и пошел спать". Хотя вы и ответили, что автоматизировать со встроенной функцией не легче, но та самая половина замечаний отношения к автоматизации не имеет.
Код включает в себя вызов исключительно системных функций. При этом от криворукости создателя runexe вас никто не спасает, кроме вашей веры в него.
Если вы хотите сравнить две версии алгоритма, то в лоб еще скриптом не автоматизируешь. Или держать два проекта, или собирать вручную, или использовать аргументы при запуске.
К тому же, по крайней мере на Linux
clock_gettime( )использует RDTSC или аналоги там, где это возможно.Так если RDTSC дает количество тактов, то, при условии что частота менялось по ходу выполнения процесса, переводить в секунды их тоже нельзя. Разве не так?
Почему бы ей не скомпилироваться, если у нее никаких зависимостей, кроме стандартной билиотеки? Что тяжелого в компиляции, которая сводится к запуску компилятора?
И, в принципе, не поддерживается, судя по сайту на мертвом Google Code и отсутсвию даже минимальной инструкции на этом самом сайте.
Отличается простотой автоматизации. Залез в ваш аккаунт и обнаружил, что как раз в вашей статье это всплыло.
Собственно вот он это код.
Это теория. На практике большая часть бенчмарков работает меньше суток, замеряет отрезки времени меньше суток, не требует абсолютной точности и т.д.
Ну а тот, у кого нестандартные задачи и кто гоняет задачи, съедающие сутки процессорного времени и при этом требующие микросекундной точности, должен разбираться сам.
Так еще раз — никто и не претендует. Функция будет работать на среднем тесткейсе, запустится
на любой платформе (в отличие от вашего варианта, который даже на достаточно популярном ARM не пойдет). Да, наверняка можно придумать кучу кода, на которой она будет давать неточные результаты. Но при этом заморачиваться не надо, скопировал функцию, два раза вызвал — и вот они результаты. Если же нужно что-то супер-точное — пиши свой код, подходящий под конкретный случай.
Так как это зависит от кучи параметров, надо просто сделать замер на той системе, на которой это вас интересует.
В худшем случае — вы получите результат, на 86400 отличающийся от реального. Думаю, это не так уж и сложно заметить.
как момент вызова функции и момент возврата из функции соотносятся с моментом фиксации показаний таймера (в том числе, чему равен оверхед от её собственной работы, как разность между этими значениями);
Могу лишь предположить, что общий оверхед будет равен ровно одному вызову функции (мы считаем от фиксации до фиксации, в начальном измерении после фиксации будет учтен "конец" функции, в конечном — будет учтено "начало" функции)
Ничего не происходит, читайте внимательнее код.
Отвечу вам, хотя ответ для всех, кто использует сторонние утилиты в бенчмарках.
Почему утилита а не функция? Ведь автоматизировать замеры с функцией обычно гораздо легче, чем с утилитой.
Так как код не мой, то точно ответить вам не могу. Судя по всему, вы правы и результат будет таким же, разве что делить надо на другое число и взять остаток.
Лично я обычно меряю время в бенчмарках, то есть сравниваю результаты работы разных алгоритмов, или версий программы, или программ. Меня мало интересует абсолютная точность, даже если эта функция будет ошибаться каждый раз на 10%, это не важно так как относительные результаты будут верными.
Цели же рассмотреть в общем такую важную и сложную тему, как измерение времени на компьютере, автор перед собой не ставил. Он только описал, как решить конкретную проблему: кроссплатформенно замерить процессорное время процесса. Если вы можете предложить лучшее решение этой проблемы, буду рад его услышать.
Обычно пользователя интересует субъективные ощущения от работы (быстро/медленно, тормозит/не тормозит), а не процессорное время.
Разработчика же интересуют либо величины в сравнении (два алгоритма, текущая версия vs. предыдущая и т.д.), либо порядок величины, т.к. скорость работы будет меняться от системы к системе достаточно сильно.
Если я хочу распространить результат на конкретную другую систему, возможно. Может быть, при разработке какой-то супер критичной системы реального времени, где еле-еле получается уложится в выделенное время, это может сыграть злую шутку.
Но если я разрабатываю массовый софт и хочу прикинуть время выполнения на множестве других произвольных систем ("как это будет работать у пользователей?"), то эта погрешность будет незаметна.
Мы хотим измерить процессорное время.
Эта функция, если я не ошибаюсь, считает реальное время, а не процессорное.
clock_gettime()теоретически может использовать RDTSC.На многоядерных/многопроцессорных системах RDTSC вроде как ненадежен.
Проблема, наверное, в том, что матрица в разы больше.
На поезд, конечно и FPS и буфера средней зеркалки хватит, а вот что-то более быстрое или долгое может и не получиться.
Топовый Canon EOS 1D X Mark II дает 16 FPS максимум. У какой (тем более не особо крутой) зеркалки 30 FPS фото?