Какво значи "цялостен тест"?

Закачаш трейс емулатор или поне слгаш ОС дето мери CPU usage и ми показваш, че ядрото е натоварено. Като видя, че червени участъци са върху смислен код ще ти повярвм. В момента нямам никаква причина да ти вярвам. Напротив, имам достатъчно причини да се съмнявам че има нещо гнило в твоя тест.

Няма причина СД-картата да товари ядрото. Дори да е без ДМА, дори да е с memcpy, то е нищожен трафик... Изходът също както го описваш не е сериозен товар. Изобщо вход&изход под 1MB/s без значение по какъв начин не може да натовари ядрото.

Остава само кодека... или кофти синхронизация.

ей ти тука спецификация на първия кодек дето ми попадна...


Peak MIPS** = 28

**Peak MIPS are specified for 48 kHz at 320 Kbps

Пак е под 50% cpu usage... колко по-висок битрейт?

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

Кодеците които тествах са MAD и Helix, целочисления вариант, 32-битова аритметика, PCM изхода мащабиран до 16-бита. Другия месец ще намеря време да сваля картинки и цифри с описания на постановката. Ако не ти харесва, моля, дай твой вариант на някой софтуер, с който да им измерим производителността. Но глупости като за сандвича определено не ми се слушат вече. Поздрави, и умната

Аз също не ми се слушат/четат глупости за сандвича, въпросът е какво твърдиш?
Първо каза, че ядрото било слабо, после че не било ядрото ами "цялостния тест"... Последно?

И не става много ясно нито какво си видял на оцилоскопа (предполагам голямо запълване, ама само предполагам), както не става ясно и какво точно се опитваш да измериш, защото ако клатиш пин преди и след началото на процедура дали мериш процедурата или неуместен task switch по средата... пак само може да гадаем.

По принцип много по-чисто се мери чрез cpu usage. В idle просто броиш инструкции/цикли. Повечето ОС-чета го имат и е лесно за имплементация. Макар че най-добре трейс емулатор, щото ти показва реално къде точно се тормози най-много. Ще се види дали са сметки или цикли нейде дето не трябва.


Иначе за сандвича си прав. Всеки си твърди каквото си иска. Ти ми твърдиш разни работи, други хора твърдят друго... В случая аз не съм пускал МП3 и нямам собствен опит, което обаче не значи че ще приема всяко твое твърдение като чиста монета.

Good luck

Не е въпроса в това кое ядро има някой и друг процент пройзводителност в повече. Въпроса е кой седи по-добре маркетингово на пазара. Това ще реши бъдещето на МИПС и АРМ.

Ако ще МИПС да пуснат 10 пъти по добра архитектура, ако нямат маркетинг да го наложат - умират.

А бе и двете са "въпроса", според това какво търси човек. Но и двете са били на
пазара с десетилетия вече като ядра та за близка кончина да приказваме ще е
малко пресилено - надявам се. АРМ заливат всичко прекалено яко и вече са се превърнали
в следващата след x86 спирачка на масовото развитие (15 GP регистъра в risc архитектура
си е практически същата спънка пред load/store ориентирано кодиране каквато
бяха двата регистъра и половина в интел). Но в това е и добрата новина де, светът
оцеля от x86, навярно ще оцелее и от АРМ. Просто масите (светът извън щатите) ще се
бъзикат идните 20 години с АРМ, другото (за мое съжаление и power) ще остане "под тезгяха".

Това че АРМ избутват всички от пазара не е нещо което може да ни радва. Монополът е кофти нещо и по тоя въпрос няма две мнения!

А пък за регистрите това което ми харесва при MIPS са shadow регистрите. Всеки РТОС може да се възползва от такава екстра.

Бройката е най-малкият проблем. И по-скоро проблем е "много" а не малко регистри. Обяснението е просто:
1) Когато регистрите са много или инструкциите са големи (32 бит) или са прости (само movе). При АРМ имаш избор - ако се ограничиш до 8 регистъра повечето инструкции се кодират като 16 битови. Иначе стават 32 битови.
2) Добре написана С функция рядко ползва много променливи. Аз го правя съзнателно и поради тая причина не искам да давам мой код за пример. Но ако погледнете да кажем lwIP стека почти няма функция с повече от 4 променливи. Хайде да не са 4, но 8 регистъра са повече от достатъчни. И 300 регистъра да има процесора просто няма за какво да се ползват.
3) Многото регистри означават повече трасфери към/от паметта при всеки context switch. При контролер с повече периферии и както при мен имам 30-40 нишки, времето за превключване никак не е без значение.

Сега за да бъда коректен, сигурно има и случаи в които трябват много регистри едновременно. Примерно за AES бая се озорих докато напъхам всичко в регистри. Сигурно има и DSP приложения дето не бих могъл. Но все пак който иска DSP да се вземе DSP. За MCU е глупаво да удвояваш размера на кода и да ограничаваш мултитаскинга.

При АРМ проблемът изобщо не е в бройката. На тях сериозно им куца ABI-то. Значи от 13 регистъра само един не трябва да се спасява. При MIPS 4К не помня 20 или 21 им бяха общо, но от тях 8 са временни. Както и да го гледаш при едините 13:1 при другите 20:8, а по друг начин може да се каже че MIPS имат 8 докато ARM само един скратч регистър...
Това е зле и води до неефективен код. То не случайно GCC при първа възможност заебават АБИ-то... чак даже префикса на тулчейна стана "arm none eabi".

Ти как мислиш, ако едно ядро е по-слабичко дали ще може да спечели на цялостен тест, дори
по-бързото ядро да има по-кофти периферия, при положение, че натоварването основно идва
от математиката ?? И двете неща, които съм казал са верни, ARM Cortex M3 ядрото е по-слабо
от M4K ядрото на PIC32, и по официална документация на фирмите, които ги произвеждат,
и по реални резултати на това което пуснах на хардуер и измерих и с таймери и с осцилоскоп.

Един ден като ми остане повечко време ще постна резултатите. Всъщност преди време
бях постнал тук резултатите на една фирма правеща CPU Benchmark тестове, от тия тестове
също се виждаше, че M4K е по-пъргаво от Cortex M3, ама и тогава слушах същите приказки де.
Така че, за да няма тая и оная, предложете някакъв код, пускаме го на двете ядра и засичаме.
Няма проблем да го пусна на мой хардуер, имам и за двете ядра достатъчно богат хардуер


@tgi, не съм се занимавал в разплитане на червата на MP3 потока. Ако все пак ти се налага
да го правиш, си мисля, че ще е по-добре да си компилираш наличните библиотеки да обектен
код, след това от асемблера само да викаш 2-3 функции. Иначе е голяма играчка да почваш
от нулата, че и на асемблер. Едната библиотека със сигурност работи на Freescale PowerPC
ядра. Това което го имам като информация, ще го сложа на FTP и ще ти пратя акаунт
да си изтеглиш каквото ти хареса.

Нищо не мисля, просто и аз като теб не приемам общи твърдения от сорта "някой бил ял салам..."

Аз много добре знам къде са слабите и къде са силните страни на АРМ. Имам и някаква представа за MIPS, тъй че имам определени очаквания кое ядро в какво е по-добро. Проблемът е, че твоите твърдения се разминават с моите очаквания и когато се опитам да разбера защо ти не можеш да ми кажеш.



Това са глупости... Пак ти казвам че може и да ти изглежда фукане ама знам какви резултати мога да очаквам. Примерно ако пуснеш най-просто strcmp МИПС ще бие, изобщо за всякакви текстови парсвания няма каква да ги сравняваме. Ако не ми вярваш ми вземи и тествай! Едно strcmp мисля не ти е никакъв проблем да врътнеш.
От друга страна ако пуснеш AES или друг подобен алгоритъм МИПС-а просто няма никакъв шанс. Ако държиш да знаеш причината ето ти кода, дето се повтаря Х-найсет пъти:


АРМ е по-добър, защото в една инструкция прави по две операции xor+shit, адресациите също са с аритметика. При MIPS нямаш такива екстри и кода ти става с повече инструкции, повече клокове, естествено и като размер освен че са повече инструкциите ами и всички са 32 бит. Но най-добре да се убедиш сам... ей ти моя код сравнявай с какъвто искаш МИПС

и после



Е как става така, че имаш представа за MIPS, пък не знаеш, че M4К, както и Cortex М3, може едновременно да използва и 16, и 32-битови инструкции ?? Честно да ти кажа, не ми се спори, ако искаш приемай думите за лъжа, ако искаш за истина.
Факт е, че знаеш едното ядро, но въобще не си запознат с другото. Ето малко история от преди 2 години:


От Окт 2009



От Юли 2011 е


Както виждаш AES се използва в тестовете и явно шанса не е бил на страната Cortex. Всъщност мен ме
боли фара, че M4K e по-бързо от M3, така или иначе не използвам Cortex ядра.


Като намеря време ще направя точно описание какво правя и на двете ядра, как точно меря, и със
снимки от осцилоскопа. Но, както казах, и моите тестове, и тези на www.coremark.org показват едно
и също. Сега е сезона на отпуските и хич не ми се наема да си губя свободното време за такива
неща.

Пирев,

дадох ти пример показващ предимство на МИПС, дадох ти и за АРМ. И двата примера може да ги анализираш като разгледаш 2-3 инструкции. Доволно просто, няма нужда от осцилоскопи.

Примерите ми не изчерпват всички разлики, но са достатъчно характерни. Ако разбереш защо АРМ е по-бавен в един прост strcmp цикъл ще видиш че по същите причини ще му куцат и целия клас от текстообработващи приложния. И обратно, ония 3 инструкции правят шифтер с обратни връзки. Това е базата на повечето криптиращи алгоритми, т.е. ако това "Y0 ^= RT1[ ( X3 >> 8 ) & 0xFF" не можеш да го направиш бързо и с малко инструкции забрави да си по-бърз в крайното приложение.


Всичко останало е заяждане на дребно. Примерно това че ПИК32 поддържал 16-бит не го знаех, но аз не съм твърдял че познавам ПИК32, даже и MIPS не познавам - казах че имам "представа" и то "някаква"... Извинявай, ама чети по-внимателно какво ти казвам, не ми преиначавай думите! Ако пък смяташ че представите за МИПС са погрешни - ми много просто, аз ти казах на какво се базират. Аз твърдя че мога направя по-бързо strcmp на МИПС отколкото на АРМ. И обратно AES се търкаля по-добре на АРМ. И в двата случая става дума за няколко инструкции...

Всъщност относно AES може и да стане еднакво бързо. Извинявай. Сега се сетих че има решение да се развият SBox и обратната таблица, така че да се спести шифтването. Но това е за сметка на 4 пъти повече памет за таблиците. Тъй че нека да приемем че говоря за стандартния алгоритъм, т.е. така както е С-кода в коментарите.
Но това няма връзка с тестовете - там се ползва С, а не ръчно оптимизран асемблер. Т.е. ти говориш за съвсем друго нещо което касае и други проблеми примерно сбърканото ABI на ARM. Демек тестовете не зависят само от хардуера.

Относно coremark... Някъде да си ме видял да оспорвам резултатите от coremark?
Цялата дандания започна от твърдението ти че куртекса се задъхвал на МП3-ки, т.е. нещо което би трябвало да изисква 30-40 DMIPS ти го пускаш на 90 DMIPS и то куца... И пак ти казвам има нещо гнило в тоя тест. Накъсването ти е или резултат от проблем със синхронизации, примерно кодирането блокира четенето и после спира щото няма данни. Или кодека е много зле написан (щото пак казвам че кодеците в нета претендират че 30MHz трябва да са достатъчни за тоя битрейт. Айде да не са 30, нека са 40-50, ама повече от два пъти грешка вече става съмнително. Но забележи, че съмнението ми не е в това кое ядро е по-бързо, а че при теб може би има някакъв проблем. Ти обаче веднага го прие като съмнение относно възможностите на ПИК. Надявам се не си чак толкоз обсебен от идеята да си мерим пишките...

Пирев, даже и да приемем, че МИПС е по - пройзводително ядро от M3, което вероятно е така, то това не му помага въобще в борбата за оцеляване. Щото Куртекс си имат и една камара още по пройзводителни ядра. И ако на някой е припрял за тия 20% сметки повече или ще сложи Куртекс на 120Мхз или ще вземе М4 и т.н.

Както казах - това, че единия има 20% по добър резултат в някакъув тест, съвсем не му гарантира по добър пазарен дял.

То като в живота де - нали знаеш кой кара лъскавите коли и чука манекенките? Определено не са отличниците от училище.

то па голям кеф да чукаш манекенка... все трябва да внимаваш да не се счупи нещо. а на сутринта ни кафе може да направи, ни яйца да свари.

основната тема е интересна, макар че пак се отвя към пишкомерене.
скопения (uClinux) според мен по-скоро за лабораторни упражнения и курсови работи. прекалено тежък софтуеризъм за постигане на посредствени цели. единственото хубаво нещо е донякъде съвместимост и крос-разработката. но ядрото се различава значително и разликата с времето расте.

за нормален linux важи правилото на мечо пух "колкото повече, толкова повече". демек - с малко ресурси жалки резултати. със средни ресурси задоволителни резултати.
самото ядро се развива от комитет от ентусиасти, които в някои отношения са направо непримирими като талибаните, примерно за GPL код навсякъде.
много неща са направени на концептуално ниво твърде сложни, защото се е целяла универсалност. ама като минеш през 10 API-та, често писани от хора непознаващи долното ниво и настава страхотно прахосване на ресурси.
от друга страна драстично съкращаване на ядрото е невъзможно. драйверите, предоставяни от чипо-производителите, често са писани като за панаир - набързо, ден-два преди панаира и имат за цел единствено да покажат, че ги има. отделно имам принципни съображения относно драйвери писани от азиатци. та избора е като при политиците - всички ще имат дефекти, въпроса е да избереш подходящ чип, който да няма фатален ефект точно върху твоите нужди.

но за съжаление, като че ли няма алтернатива...

Не съм ти преиначил думите. Ето ти думите:

Казал си го съвсем ясно и четливо, че M4K няма подходящи инструкции за XOR и едновременно шифтване - добре, приемам го на доверие. След това обаче казваш,че M4K не поддържал 16-битови инструкции в 32-битов поток. Би ли ми посочил какво съм преиначил от думите ти ? Нека XOR и едновременното шифтване да е по-сбито, какво става обаче когато се наложи да съхраняваш резултатите при други аритметични операци ? При M4K
имаш 32 налични 32-битови регистъра, от които реално можеш да ползваш към 24, при ARM имаш само 16, от които реално са ти налични мисля 12 ( поправи ме ако греша ). Ще трябва да правиш обръщения към паметта, което във всички случаи прави по-бавен ARM-а. При M4K имаш възможност за 3 коопроцесора, които Microchip са ги изрязали и реално има само един, но в случая името му подвежда, практически не е коопроцесор с наличието на някаква аритметика, а трябва да се разглежда като разширение на регистровия файл на основното ядро. Коопроцесорите дават възможност за паралелизиране на изчисленията, ако Microchip ги бяха оставили, то тогава M4K в PIC32 щеше просто да размазва ARM Cortex M3 в аритметиката. Не знам защо са ги изрязали, или са гонили цена, или консумация. Та в какво тогава ARM Cortex M3 е по-добър от M4K ??


От това което казваш, излиза че може GCC да генерира по-сбит код за MIPS. Не разбирам от асемблер нито за ARM, нито за MIPS. Единственото нещо, което съм направил за MIPS на асемблер е да оптимизирам парче код, което използва madd инструкции. По спомени в C варианта
генерирания код беше къде 47 инструкции, на асемблер излезна 11 инструкции. Всъщност това е което съм оптимизирал в MAD и Helix декодерите. И с това се изчерпва опита ми на асемблер за MIPS.


Противоречиш си, хем нямаш съмнения отностно резултатите на coremark, хем съмнението ти не е в това кое ядро е по-бързо, а пък грешката видиш ли била при мен, щото съм решил да си мерим пишките. Какви пишки, какви 5 лева ? Ако ще се мерят пишки да си ги мерят MIPS и ARM. Ако ние ще си ги мерим резултата е ясен предварително - моята е по-голяма . Ако се поразровиш малко в мрежата ще видиш, че доста хора пуснали софтуерното декодиране на Cortex M3 и на ARM7 ( при ARM7 мисля основно ставаше дума за LPC на 60MHz ) също са забелязали накъсването. Декодера е един и същ, пардон 2 вида са: MAD и Helix, целочислени декодери. Същите декодери се търкалят и в доста Windows/Linux/Symbian плеъри, последните им редакции са от 2003г. Ако имаше нещо гнило в декодерите при такава интензивна употреба все някой щеше да открие грешките в тях за тези 7 години. Така че изключвам възможността за зле написан декодер, кода и на двата декодера е много читаво написан ( лично на мен повече ми харесва MAD, по-добре е структуриран ), освен това авторите и на двата декодера твърдят, че са го оптимизирали съобразно архитектурата на ARM7, а не спрямо MIPS, x86 или PowerPC. Което е плюс за ARM, но не и за MIPS, където кода е изцяло на C.

Данданията тръгна от там, че хвърляш прах в очите на хората, колко зле било M4K ядрото, а колко по-хубаво било Cortex M3, което въобще не е така.
Дори и да съм объркал някъде в моите измервания, факта, че M4K е по-бързо от Cortex M3 не подлежи на коментар. Това е всъщност, което твърдя. Това може да се прочете и в техническите спецификации на ядрата. Но нека да приемем, че някъде съм объркал и че Cortex M3 възпроизвежда MP3 поток с MAD и Helix без да накъсва. Това мога да го проверя повторно след като мине сезона на отпуските и ще постна резултатите, както обещах и преди това. Кодът, който извиква декодерите, ще го преработя, така че да е един и същ на 100% и за двете ядра, изходното аудио съще ще преминава през един и същ чип - WM8731.

Съжалявам, че наспамихе темата на emilvtc, ако може Реконструктора да я премести в нова тема, примерно "Пишоци"