![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
профайлинг
Sep. 2nd, 2011 11:42 amа вот если так поразмыслить, было бы неплохо, если для треда можно было бы получить не только время, проведенное им на процессоре, но и время, проведенное им в ожидании каких-то ресурсов (синхронизация, ввод-вывод, что там еще), в отличие от времени когда тред просто был отложен диспетчером задач.
Скажем, если я профайлю какую-то функцию, которая занимает 3 секунды абсолютного времени и 1 секунду процессоного, то было б неплохо знать, на что ушли оставшиеся две секунды - на ожидание ресурсов, или на ожидание свободного ядра. Как бы, время на ожидание свободного ядра можно смело выкидывать из статистики по профилированию аппликации, оно не интересно.
К примеру, если у меня есть некоторый конвейер (скажем, передающий и обрабатывающий данные слева направо), то ботлнек в нём можно найти, поискав элемент, на котором висит большую часть времени как тред-писатель, находящийся "слева" от элемента, так и тред-читатель ("справа"). Однако, статистика эта, где тред висит больше - на чтении (из элемента слева от него) или на записи в элемент справа от него, искажается тем, что иногда мы можем думать, что тред висит на записи или чтении, а он реально попросту выгружен диспетчером задач, а не блокирован на ресурсе.
Вроде бы ни юникс, ни винды такую статистику не дают.
----------
Еще вот непонятно, как учитывать время в профайлинге на многоядерном процессоре. Скажем, можно получить процессорное время проведенное в функции (функциях) превышающее реальное время пробега аппликации. С другой стороны при прогоне той же апплиации на одном ядре, процессорное время будет строго меньше абсолютного. Как бы эти данные свести к единообразному формату... Неясно.
Скажем, если я профайлю какую-то функцию, которая занимает 3 секунды абсолютного времени и 1 секунду процессоного, то было б неплохо знать, на что ушли оставшиеся две секунды - на ожидание ресурсов, или на ожидание свободного ядра. Как бы, время на ожидание свободного ядра можно смело выкидывать из статистики по профилированию аппликации, оно не интересно.
К примеру, если у меня есть некоторый конвейер (скажем, передающий и обрабатывающий данные слева направо), то ботлнек в нём можно найти, поискав элемент, на котором висит большую часть времени как тред-писатель, находящийся "слева" от элемента, так и тред-читатель ("справа"). Однако, статистика эта, где тред висит больше - на чтении (из элемента слева от него) или на записи в элемент справа от него, искажается тем, что иногда мы можем думать, что тред висит на записи или чтении, а он реально попросту выгружен диспетчером задач, а не блокирован на ресурсе.
Вроде бы ни юникс, ни винды такую статистику не дают.
----------
Еще вот непонятно, как учитывать время в профайлинге на многоядерном процессоре. Скажем, можно получить процессорное время проведенное в функции (функциях) превышающее реальное время пробега аппликации. С другой стороны при прогоне той же апплиации на одном ядре, процессорное время будет строго меньше абсолютного. Как бы эти данные свести к единообразному формату... Неясно.
