Учимся правильно бенчмаркать (в том числе итераторы)

[@Himari]

>Процессор C2D, он умеет держать разные частоты на разных ядрах.
Не умеет. Частота меняется сразу для двух ядер.

[@shodan]

Не могу уверенно отрицать, мог перепутать c2d с чем-нибудь типа i7, документация гуглится так себе. Проблема с аффинити впрочем все равно в наличии.

[@BullDER]

В том посте вроде говорилось про вектороский итератор… или я вас недопонял?

[@shodan]

Я не понял вопроса. Речь про бенчмарк преинкрементов и постинкрементов итератора по вектору, из предыдущего в блоге C++ постинга. Сорсы соотв-но www.viva64.com/external-pictures/TestSpeedIterator.zip

[@Andrey2008]

Отличная заметка! Вон оно чё, Михалычь! А я то мучился! Дурак, по нескольку раз мерил, а потом среднее считал.

[@shodan]

Ну. Среднее считать как бы действительно не очень умно, если дисперсия зашкаливает. Тест ведь нерандомизированный нихрена, дрожать в 1.5 раза ну никак не должно. В моей среде исполнения, как видишь, зашкалила. Что было в твоей среде, не могу знать. (Возможно, все было ок, подробности своей методологии замеров ты не приводишь.)

Заметка, соотв-но, именно про борьбу с дисперсией как явлением, а не каким-либо конкретным тестом.

[@Andrey2008]

У меня дрожь не такая страшная. Видимо всё очень зависит от аппаратуры. В любом случае пошёл переделывать механиз замера скорости.

[@Andrey2008]

Предлагаю вместе написать новую на тему измерений. Взять за основу мою старую, вот то что ты накопал добавить и т.д. Ибо ты верно заметил — мерить практически никто не умеет. Даже я.

[@Andrey2008]

Ой. Я имел в виду — habrahabr.ru/company/intel/blog/82832/

[@7vies]

Там SECURE_SCL не только в дебаге, но и в релизе был (он похоже включён по умолчанию в студии 2005 и 2008).
А дрожания на моей машине особого не было, может от процессора или системы сильно зависит. Кстати, можно ещё приоритет процессу поднять, чтобы его не вытесняли.

[@shodan]

Так точно. У меня именно 2005, после #define _SECURE_SCL 0 перед include-ами внезапно становится примерно 0.078 сек на оба теста. Фарш из пяти лишних проверок и вызовов __imp___invalid_parameter_noinfo однако не помогают перформансу ни хрена.

Но вот иллюстрировать дрожание как раз куда лучше с этим фаршем. Нагляднее. ;)

[@7vies]

Ну для иллюстрации наверное и правда удобно, но вообще как-то странно оставлять такие вещи в релизе. К 2010 версии они наконец это поняли и по умолчанию выключили проверки в релизе.
А что, при выключенных проверках дрожит существенно меньше? Если так, то интересно, с чего бы это.

[@shodan]

Нет. Все равно от 0.08 до 0.13 сек колбасится.

[@7vies]

Хорошо хоть здесь без сюрпризов :)

[@7vies]

А почему нужно делать SetProcessAffinityMask, код же не многопоточный? В чём отличие от SetThreadAffinityMask для однопоточного приложения?

[@shodan]

Гляди уже код, там в оригинале SetThreadAffinityMask(0) на каждый старт таймера зачем-то, и восстановление при выходе. Что опять же оказалось удобно для иллюстрации, что первого порыва исправить 0 на 1 в этом месте и успокоиться недостаточно, иначе в промежутка скачки с ядра на ядро дадут эффект. Если убрать SetTAM() из таймера и оставить один удар на процесс, этого должно хватить, конечно.

[@7vies]

Код-то я видел, на affinity просто внимания не обратил. В оригинале кстати вообще странно, там переменная oldmask не инициализирована нигде. В промежутке и правда может перескочить на другое ядро, но думаю что для этого скорее всего понадобится другой требовательный поток, который захочет запуститься именно на этом ядре — при разгруженной машине я такого не наблюдал (не было переключений контекста потока, проверял по системным счётчикам).

[@shodan]

Как бенчмаркать тру-кроссплатформенно (см. включая AIX, z/OS, iOS, Android, и микроконтроллеры вплоть до smart утюгов) я не знаю. Под Linux, а также FreeBSD 7.2 и выше можно мерить время gettimeofday(2), аффинити прибивать либо sched_set_affinity(2) (если строго под Linux), либо pthread_setaffinity_np(3), ну и крутить governor тулзами конкретной дистрибуции. Под Solaris доки читать надо уже про processor_bind(), ну и так далее.