Большой Воронежский Форум
Страница 3 из 3
< 123
» Программирование>Ассемблер. Рациональность использования и вопросы.
Spectator 20:43 02.02.2012

Сообщение от aerin:
Клево, а про профайлеры мьсе не слышал?

Безусловно, слышал, и использовал, безусловно В ТОМ ЧИСЛЕ. Одно другому не мешает [Ответ]
Pengvin 21:31 02.02.2012
Я ниразу не специалист. В статье на вики http://ru.wikipedia.org/wiki/Rdtsc , из которой я узнал пару часов назад про rdtsc, инфа посвежее выглядит, и написано как обойти многие проблемы, и про rdtscp написано.
Возвращает значение не в попугаях, а вполне себе в тактах процессора, самый чистый показатель оптимизации. QueryPerformanceFrequency и при желании можно померить и в мкс с погрешностью ( нахрена правда на PC такое делать?).
Вы экономите на вызовах вложенных функций, при этом чистая, незамутненная низкоуровневая операция вам не нравится. Вам шашечки или ехать? [Ответ]
Spectator 21:55 02.02.2012

Сообщение от Pengvin:
Я ниразу не специалист. В статье на вики http://ru.wikipedia.org/wiki/Rdtsc , из которой я узнал пару часов назад про rdtsc, инфа посвежее выглядит, и написано как обойти многие проблемы, и про rdtscp написано.
Возвращает значение не в попугаях, а вполне себе в тактах процессора, самый чистый показатель оптимизации. QueryPerformanceFrequency и при желании можно померить и в мкс с погрешностью ( нахрена правда на PC такое делать?).
Вы экономите на вызовах вложенных функций, при этом чистая, незамутненная низкоуровневая операция вам не нравится. Вам шашечки или ехать?

С интересом заглянул, поскольку меня вопрос крайне интересует не только в контексте разгоревшегося спора, и увидел как раз грамотный и достаточно полный список проблем, связанных с использованием этой инструкции.
Идея то ее использовать - крайне вкусная. И я, безусловно, тестировал эту инструкцию даже на своей одноядерной машинке, результаты меня крайне огорчили, даже врубание максимально возможного приоритета как процессу так и потоку не дали ни капли точности. Один и тот же цикл, специально созданный для тестирования, выполняющий одну и ту же работу давал настолько разнообразные показатели в тактах, что стало просто грустно и обидно за потраченное зря время.
А ведь при таких условиях работает, фактически, только ядро ОС и твоя программа, остальные в пролете.
Так что единственный вариант, который я для себя выбрал.
а) Rdtsc для оценки небольших участков кода, очень небольших, когда шанс переключения на другой процесс минимален. Причем информация суммируется, за счет многократных вызовов (1000+), и впоследствии считается среднее значение, иначе смысла в ней нет ни малейшего.
б) GetTickCount для оценки достаточно серьезных участков кода (отрисовка небольшой экранной области даже на DirectDraw даже с загруженными в видеопамять текстурами занимает времени достаточно, чтобы на погрешность GetTickCount можно было бы наплевать).

Все остальные методы я отмел по разным причинам, хотя испробовал практически все возможные. Не стоит, например, забывать о наводках, вызванных исполнением САМИХ функций замера времени Время входа в функцию соооовсем не равно времени выхода из нее))) [Ответ]
The_God 17:06 04.02.2012
а что вы програмите, где нужна такая точность ? [Ответ]
Спартак21 23:12 04.02.2012
всё бы конечно хорошо, но разговор переходит к проблеме верификации моделей))) [Ответ]
Страница 3 из 3
< 123
Вверх