Постпроцес `objdump --disassemble` с брой цикли на ARM

Има ли наличен скрипт за последваща обработка на някои objdump --disassemble изходни данни за анотиране с брой цикли? Специално за семейството на ARM. По-голямата част от времето това би било само съвпадение на шаблон с търсене в таблица за броя. Предполагам, че може да са необходими анотации като +5M за пет цикъла на паметта. Perl, python, bash, C и т.н. Мисля, че това може да се направи общо, но се интересувам от ARM, който има ортогонален набор от инструкции. Ето тема за 68HC11, която прави същото. Скриптът ще се нуждае от опция за модел на процесора, за да избере подходящия брой цикли; Мисля, че тези бройки вече съществуват в описанието на машината gcc.

Не мисля, че има превключвател objdump за това, но RTFM би бил страхотен.

Редактиране: За да поясним, предположенията като най-добрия случай на подсистема на паметта, какъвто ще бъде случаят, когато кодът се изпълнява от кеша, са добри. Целта не е 100% точен брой цикли според някоя работеща машина. Възможно е да се получи разумна оценка, в противен случай дизайнът на компилатора би бил невъзможен.

Както посочва DWelch, проста текуща обща сума не е възможна с дълбока конвейерна архитектура, като по-новите Cortex чипове. Постобработката objdump ще трябва да разгледа околните кодове за операции. Приставката за gcc е по-вероятно да успее да постигне това и тъй като е нова (4.5+), не мисля, че съществува такова нещо. Скрипт за ARM926 със сигурност е възможен и доста прост.

Забавянето на паметта няма значение. Контролерът на паметта е като друг CPU. Той върши работата си, докато процесорът извършва аритметика и т.н. Един добър/добре настроен алгоритъм ще паралелен паметта осъществява достъп с изчисленията. Чрез преброяване на зареждания/запаметяване и цикли можете да определите колко паралелизъм е постигнат, когато активно профилирате с таймер. Конвейерът е значителен поради блокировките между регистрите, но броят на циклите за основни блокове може надеждно да бъде изчислява се и се използва дори на съвременни ARM процесори; това е твърде сложно за прост скрипт.


person artless noise    schedule 18.02.2013    source източник
comment
FYI, ARM не публикува времена на цикъла за последните си процесори (напр. Cortex-A5/A7/A15)   -  person Marat Dukhan    schedule 18.02.2013
comment
@Maratyszcza: Интересно. Погледнах и не виждам. Пише нисък брой цикли за ARM7-a, така че предполагам, че това означава единичен часовник, с изключение на проблеми с паметта. Как тогава някой може да напише компилатор? Gcc изглежда има описание. gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/arm/   -  person artless noise    schedule 18.02.2013
comment
Различните процесори ARMv7-A имат различни времена на цикъла (и кодът, оптимизиран за един процесор, ще бъде неоптимален за друг).   -  person Marat Dukhan    schedule 19.02.2013


Отговори (2)


Има онлайн инструмент, който оценява броя на цикъла на Cortex-A8. Този процесор обаче е доста стар и програмите, оптимизирани за него, може да не са оптимални за по-новите процесори.

AFAIK ARM също така предоставя Cortex-A9 и Cortex-A5 цикъл-точни емулатори в софтуера им RVDS, но е доста скъп.

person Marat Dukhan    schedule 18.02.2013
comment
+1 за нещо, демонстриращо, че е възможно; само глупак би си помислил, че тези инструменти са 100% точни. Надявам се на нещо с отворен код и по-общо; По-конкретно аз нямам кортекс. - person artless noise; 19.02.2013
comment
Бързите модели не са циклично точни. За да се пошегувам, това биха били бавни модели :) -- няма публично достъпни модели с точни цикли. - person Charles; 21.02.2015

Броят на циклите не е нещо, което може да бъде оценено чрез разглеждане само на инструкцията на модерен ARM от висок клас. Има много състояния по време на изпълнение, които влияят на процента на пенсиониране в реалния свят на дадена инструкция. Данните, от които се нуждае, съществуват ли в кеша? Инструкцията има ли някакви зависимости от предишни резултати от инструкции? Ако е така, какви закъснения премахва устройството за препращане? Колко пълен е буферът за зареждане/съхранение? Какъв вид картографиране на паметта докосва? Колко пълни са конвейерите на процесора, от които се нуждае тази инструкция? Има ли инструкции за синхронизиране в потока? Спекулациите изнесоха ли някои данни, от които зависи? Какво е състоянието на преименуващия регистър? Дали условните инструкции са запълвали конвейера или декодерът е бил достатъчно умен, за да ги пропусне напълно? Какви са съотношенията между часовника на ядрото и часовниците на шината и паметта? Какъв е размерът на таблицата за прогнозиране на разклонения?

Без пълна симулация на процесор всичко, което можете да получите, са предположения. Дали тези числа са значими за вас зависи от това какво се опитвате да постигнете с тях.

person Variable Length Coder    schedule 18.02.2013
comment
няма значение, нулево състояние на изчакване или не. рамковите ядра и периферните устройства около тях и интерфейсът axi/amba на производителите на чипове и т.н. всички определят скоростта на изпълнение. Ако искате да знаете колко бързо е нещо на определена дъска, пуснете го на тази дъска, в противен случай то в най-добрия случай е само грубо предположение и се очаква да бъде неправилно поради някакъв факт или 2x грешно, 4x грешно, 10x грешно и т.н. в двете посоки. - person old_timer; 18.02.2013
comment
това е вярно за повечето конвейерни архитектури, а не само за arm - person old_timer; 18.02.2013
comment
детерминистични архитектури като снимките (разбира се, не снимката на mips) и 8051 и 68hc11, 6502, 8088, 8086 и дълъг списък от други, можете лесно да направите инструмент, който изчислява тези времена за изпълнение. - person old_timer; 18.02.2013
comment
В момента гледам -fdump-rtl-all. Със сигурност gcc има някаква представа колко време отнемат инструкциите. Разбирам, че интерфейсът на AMBA може да варира. Това е памет, нали? Искам да предположа, че ядрото е емисия с инструкции. ARM5 и по-стари със сигурност са детерминирани. Съвсем сигурен съм, че всички те са детерминистични, може би прекалено сложният/дълбок тръбопровод е по-подходящ? Мисля, че е малко вероятно да е 10 пъти погрешно. Ако е така, тогава трябва да погледнете опциите, които предавате на компилатора ИЛИ компилаторът се нуждае от актуализиране на описанието на машината. - person artless noise; 19.02.2013
comment
Броят на циклите плюс I/O броят може да даде добра информация. Циклите на процесора ще бъдат балансирани с шината на паметта в добра рутина. Сигурни ли сте, че сте пораженци? Наистина ли съм откачил? Ще изтрия въпроса, ако е така. - person artless noise; 19.02.2013
comment
@BillPringlemeir: не от вашия рокер и няма нужда да изтривате въпроса, но въпросът е, че по-новите процесори, с големи латентности за достъп до паметта, са твърде недетерминистични, за да бъде статичният анализ надежден. В крайна сметка прекарвате време в оптимизиране на части от кода, които не влияят на действителната производителност, като същевременно пренебрегвате части, които ви осакатяват (т.е. всякакви разрушителни модели за достъп до паметта или разбиващи предиктори на разклонения). - person unixsmurf; 20.02.2013
comment
Разгледайте машинните описания на GCC (gcc.gnu.org/onlinedocs/gccint/ Machine-Desc.html), за да получите по-точна представа каква информация има GCC за дадена инструкция. По-специално, GCC следи слотовете за забавяне, изисквани от дадена инструкция, и процесорните конвейери, осигурени от дадена архитектура. Не изглежда да предсказва броя на часовника на инструкциите; той просто използва атрибути на инструкциите и тръбопровода за подобряване на подреждането на инструкциите. - person mkfs; 05.05.2013
comment
@mkfs Мислех за arm.c в gcc и част от информацията за цената, кодирана там. Изглежда, че в някои случаи се броят инструкции? Не че те са цикълно точни, но те са това, което компилаторът изглежда използва за избор на операционни кодове в някои случаи. - person artless noise; 17.05.2013
comment
RE: arm.c -- това изглежда предоставя информация на GCC оптимизатора, така че може да имате достъп до него, когато компилирате с -ftree-vectorizer-verbose=3 и/или -fdump-tree-vect. Тази информация обаче не е налична в objdump, защото не е включена в модула binutils libopcodes за ARM: repo.or.cz/w/binutils.git/blob/HEAD:/opcodes/arm-dis.c . Това означава, че ще трябва да извлечете кода за генериране на разходи от GCC или (може би) да предадете на GCC необработения asm и да го накарате да излъчи информацията за разходите, като използва опциите GCC -fdump (ако се поддържа). - person mkfs; 04.06.2013