Комментарии 2
Привет!
Я пока ещё не полностью прочитал статью, но у меня уже появился вопрос: почему использовался такой хитрый способ дёрнуть rdtsc?
Сейчас у меня только догадки:
1) Неужели родной Stopwatch даёт столь большие накладные расходы, что эта пляска с бубном того стоила?
2) Может быть были опасения, что SW задействует HPET?
По тому, что успел прочитать сложилось впечатление, что ты не совсем правильно понимашь, что именно он там считает. В статье надо бы уточнение добавить. В интеловском мануале, помнится, довольно чётко написано, как именно он работает. Когда я с ним экспериментировал, лет 5 назад, у меня 2 (почти) последовательных вызова RDTSC иногда приводили к нулевой стоимости кода. Тогда я пришёл к выводу, что после вызова надо ставить Full Fence - иначе короткие интевалы не очень мерять получается.
Спасибо за статью. Довольно познавательный материал. На счёт влияния гранулярности планируемой работы, в реальности я думаю ситуация будет заметно сложнее, так как пул потоков будет загружен делегатами различной гранулярности и мы не увидим такой четкой связи. Не будет ли там своеобразной интерференции?
О Thread и ThreadPool в .NET подробно (часть 2)