Как я рассматриваю проблемы многопоточности?

Question

Это первый раз, когда я пытаюсь профилировать многопоточную программу.

Я подозреваю, что проблема в том, что она чего-то ждет, но я понятия не имею, что программа никогда не достигает 100% от процессора, графического процессора, ОЗУ или использования ввода-вывода.

До недавнего времени я работал только с проектами с однопоточными или там, где потоки были очень простыми (например, обычно это дополнительный поток, чтобы гарантировать, что пользовательский интерфейс не заблокирован во время работы программы или когда я сделал игровой движок с отдельным потоком для обработки музыкальных файлов .XM и .IT, чтобы основной поток мог делать все, в то время как другой поток в другом ядре мог позаботиться об декодировании этих файлов).

Эта программа имеет несколько потоков, и они не выполняют параллельную работу над одними и теми же задачами, каждый поток имеет свою собственную отдельную цель (например, один поток предназначен для обработки всех вызовов API, связанных с звуком, в ОС) ,

Я загрузил инструменты производительности Microsoft, есть блог сотрудника ex-Valve, который объясняет, что они работают, чтобы сделать это, но хотя мне даже удалось создать некоторые профили и еще много чего, я не совсем понимаю, что я видя, это всего лишь кучка хороших графиков для меня (за исключением графика использования процессора, о котором я уже знал, начиная с создания профилей на основе однопроцессорных приложений), так, как я нахожу, почему программа чего-то ждет? Или как я нахожу, чего это ждет? Как я нахожу, какой поток блокирует других?

Answer 1

Я смотрю на это как чередование между двумя вещами:

а) измерение общего времени, для которого все, что вам нужно, это какой-то таймер, и

б) нахождение ускорений, который делает не означает измерение, несмотря на то, что было сказано много людей.

Каждый раз, когда вы находите ускорение, вы получаете результаты и делаете это снова. Это чередование. Чтобы найти ускорения, метод I и многие люди используют random pausing. Идея заключается в том, что вы запускаете программу под отладчиком и вручную прерываете ее несколько раз. Каждый раз вы проверяете состояние каждого потока, включая стек вызовов. Очень грубая, и это очень эффективно.

Причина, по которой это работает, заключается в том, что единственный способ, по которому программа может идти быстрее, - это то, что она делает операцию, которую вы можете удалить, и если это экономит определенную долю времени, вы, по крайней мере, можете увидеть ее на каждая пауза. Это работает независимо от того, выполняет ли он I/O, ждет чего-то или вычисляет. Он видит то, что профилировщики не выставляют, потому что они делают summaries from which speedups can easily hide.

Answer 2

1. Мастер производительности в Visual Studio Performance and Diagnostics Hub имеет «Resource конкурирующий данные» профилирование режим, который позволяет анализировать параллелизм раздора между потоками, то есть как общая производительностью программы воздействуют потоки, ожидающие на других потоках. Пожалуйста, обратитесь к сообщению this для более подробной информации.
2. PerfView - чрезвычайно мощный инструмент для профилирования, который позволяет анализировать влияние потоков услуг и задач на общую производительность программы. Вот PerfView Tutorial.