Ассемблер. Рациональность использования и вопросы.

[Spectator]

Сообщение от aerin

Клево, а про профайлеры мьсе не слышал?

Безусловно, слышал, и использовал, безусловно В ТОМ ЧИСЛЕ. Одно другому не мешает

[Pengvin]

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

[Spectator]

Сообщение от Pengvin

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

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

Все остальные методы я отмел по разным причинам, хотя испробовал практически все возможные. Не стоит, например, забывать о наводках, вызванных исполнением САМИХ функций замера времени Время входа в функцию соооовсем не равно времени выхода из нее)))

[The_God]

а что вы програмите, где нужна такая точность ?

[Спартак21]

всё бы конечно хорошо, но разговор переходит к проблеме верификации моделей)))