Как вы профилируете приложение .net с учетом влияния кеша ЦП?

Все известные мне профилировщики .net не учитывают влияние кеша процессора.

Учитывая, что чтение поля из кеша ЦП может быть в 100 раз быстрее, чем чтение из основной памяти, это может быть важным фактором. (Мне просто нужно было объяснить это в ответе)

Я видел слишком много людей, которые тратят много времени на ускорение циклов, которые, по словам профилировщика, медленные, тогда как в реальной жизни кэш процессора делает их быстрыми.

Например, я хочу иметь возможность видеть, часто ли при доступе к данным отсутствует кэш процессора, а также просто получать базовые результаты профилирования, которым я могу больше доверять.

В прошлом я обнаружил, что если сделать мои данные более компактными, все они будут помещаться в кэш ЦП, или изменение другого, доступ к данным может иметь большой эффект. Например.

AccessArrarFromStartAndDoSomething()  
AccessArrayFromEndAndDoSomethingElse()

Тогда лучше

AccessArrarFromStartAndDoSomething()  
AccessArrayStartEndAndDoSomethingElse()

если массив не помещается в Кэш ЦП, но очень трудно найти такой тип усовершенствования.

Затрата большего количества циклов ЦП на уменьшение размера данных, чтобы они лучше помещались в Кэш ЦП, может привести к распространению множества систем, но большинство профилировщиков укажут вам другое направление.


.net profiling cpu-cache
person Ian Ringrose    schedule 30.07.2010    source источник
comment
В чем именно заключается ваш вопрос?   -  person Walter    schedule 30.07.2010
comment
.NET — это такой высокоуровневый язык с большим временем выполнения, что заметив, что кэш ЦП может быть возможен, но вы не можете контролировать что-то для его оптимизации.   -  person Bob Fincheimer    schedule 30.07.2010

Ответы (2)


arrow_upward
0
arrow_downward

Я видел слишком много людей, которые тратят много времени на ускорение циклов, которые, по словам профилировщика, медленные, тогда как в реальной жизни кеш процессора делает их быстрыми.

Некоторые профилировщики действительно хороши в подобной ерунде.

Какова ваша общая цель? Вы хотите, чтобы вычисления выполнялись за меньшее время настенных часов?

Если нет, игнорируйте этот ответ.

Если это так, вам нужно знать, на что тратится время настенных часов, от чего вы можете избавиться.

Дело не в точности тайминга. Речь идет о точности определения местоположения. Я предлагаю то, что вам действительно нужно знать, это то, какие строки кода одновременно 1) отвечают за разумную часть затрачиваемого времени и 2) которые можно было бы сделать лучше или не сделать вообще. Это то, что вам нужно знать, потому что если нет таких строк кода, то что вы собираетесь оптимизировать?

Отличным способом найти такие строки кода является любой профилировщик, который 1) берет образцы по настенным часам (не по времени процессора) стека вызовов и 2 ) сообщает вам для каждой строки кода (не функции), которая появляется в стеках вызовов, в каком проценте стеков она появляется. Ваши строки-кандидаты на оптимизацию находятся среди строк, имеющих большой процент. (Пара примеров не из .net: Zoom и LTProf.)

Честно говоря, профилировщик, который я использую, у вас уже есть. Я просто приостанавливаю программу, пока она работает медленно, и смотрю на стек. Мне не нужно много образцов. На самом деле, если есть строка кода, без которой я мог бы обойтись, если она появляется всего лишь в двух сэмплах, я знаю, что ее стоит исправить, и чем меньше сэмплов потребовалось, чтобы добраться до этой точки, тем оно больше. Вот более подробное объяснение.

Почти всегда есть несколько «узких мест». Поэтому я нахожу большую, исправляю ее и делаю все заново. Устранение узких мест делает с оставшимися узкими местами то, что увеличивает их. Этот «эффект увеличения* позволяет вам продолжать движение до тех пор, пока просто не останется скорости, которую можно было бы выжимать.

person Mike Dunlavey    schedule 30.07.2010

arrow_upward
0
arrow_downward

Я могу неправильно понять ваш вопрос, но я думаю, что ответ заключается в том, чтобы просто переключить ваш профилировщик в режим высокой точности и низкой детализации. Примером может служить использование нового режима выборки профилировщика производительности ANTS:

http://www.simple-talk.com/community/blogs/andrewh/archive/2009/11/13/76420.aspx

person Mel Harbour    schedule 30.07.2010
comment
Спасибо, режима выборки до сих пор не было в большинстве профилировщиков .not. - person Ian Ringrose; 30.07.2010
comment
Да, видите, вот где я бы пошел другим путем. - person Mike Dunlavey; 30.07.2010