Как профилирате .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 Performance Profiler:

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