...necital som tento clanok , ale aj tak odvadzate skvelu pracu , poklona
no chcel by som sa spytat (urcite to bude hlupost), vacsina (vypada ze laikov) tvrdi ze ARM nemaju dostatocny vykon na spracovavanie aplikacii rovnako komplikovanych ako je na x86 architekture
chapem ze sa to asi neda neak presne povedat, ale ak by bol priamo (bez neakych emulacii) na kazdy architekturu spravena rovnako komplikovana aplikacia dalo by sa povedat ze to ARM dokaze alebo nedokaze spracovat ?
resp da sa neak porovnat vykon medzi RISC CISC a napr MIPS ?
este raz sa ospravedlnujem
Pokud je dostatek pameti tak, prisne vzato, to jestli je mozne nejaky program zpracovat nebo ne, nezalezi na CPU (viz http://www.root.cz/zpravicky/osmibitovy-linuxovy-pocitac-bootuje-dve-hodiny/?odkud=boxik).
Pochopitelne se to ale projevi na rychlosti.
ARM je dnes pomalejsi nez high-end x86 stroje. Castecne proto, ze je 32bitovy, ale i pri porovnani treba s Athlonem XP jsou dnesni implementace pomalejsi. Je to dano tim, ze treba takovy ARM Cortex A8 zpracovava maximalne 2 (integer) instrukce zaroven navic jen jedna z nich muze byt typu load/store, zatimco Athlon muze zacit zpracovavat 3 x86 instrukce kazdy takt, pokud mezi nimi neni zavislost. Novejsi procesory jeste vic.
Takze to musite brat tak ze dnesni ARMy jsou architekturou zhruba na urovni prvniho Pentia.
Vykonostne budou mirne pod Atomy.
Obecne srovnani RISC a CISC --- dnes uz je to jedno (co do vykonu). RISC obvykle vyjde na min transistoru, lip se navrhuje a je jednodussi pro nej kompilovat. Dnes uz ale ta vyhoda neni tak vyrazna, protoze vetsinu transistoru na chipu stejne zabira cache, takze dekoder x86 instrukci i kdyz je obrovsky neznamena zase takovou usporu pro RISC procesory, ktere ho nemuseji mit. Porad je ale uspora v prikonu, protoze zatimco strankam cache ktere se zrovna nepouzivaji je mozne snizit napajeci napeti (tzv. drowsy cache) a tim usporit prikon, tak dekoder musi pracovat porad -- proto ty ARMy zerou min nez intely.
Jako vyhoda CISC se uvadi vyssi hustota kodu a tim lepsi vyuziti instrukcni cache, ale podle me je to blbost, protoze kdyz chcete aby to na tech intelech bezelo rychle tak stejne musite rozrolovat cykly a delat SW pipelining (coz jsou optimalizace ktere za vas udela kompilator) a vysledkem je delsi ale rychlejsi kod, nez kdyby ho psal primo clovek v assembleru jak byl zvykly na i386. Podotykam ale ze i386 nebyl navrhovan s cilem co nejvyssi hustoty kodu.
Navic o rychlost jde vetsinou v celkem makych podprogramech ktere se vetsinou cele vejdou do dnesnich cache. Takze jedina vyhoda je ze CISC program zabere min na disku (a v RAM behem provadeni).
"ARM Cortex A8 zpracovava maximalne 2 (integer) instrukce zaroven navic jen jedna z nich muze byt typu load/store, zatimco Athlon muze zacit zpracovavat 3 x86 instrukce kazdy takt, pokud mezi nimi neni zavislost."
Ve skutečnosti jich zvládne zpracovat zároveň víc (i když tohle je info o verzi starší a novější než A8).
Ono to porovnani je dost tezke: bud se muze porovnavat ten nejlepsi procesor x86 s tim nejlepsim, co ma ARM jadro. Potom, pokud mi neunikl nejaky novy cip, to vyhraje x86_64, ovsem samozrejme jeho cena (http://www.alza.cz/intel-six-core-xeon-x5680-d193417.htm) a spotreba je uplne nekde jinde :-)
Nebo se mohou porovnavat procesory se stejnou cache a vyrobene stejnou technologii (dejme tomu 40nm), potom ARMy (ty superskalarni) dokazou x86 docela dobre konkurovat.
Treti porovnani, ktere asi zajima napriklad vyrobce tabletu: rekne se maximalni spotreba procesoru a porovna se vykon dvou procesoru se zhruba stejnou spotrebou (a idealne i s podobnou cenou). Vysledek vidime vsude okolo sebe ;-)
No a ctvrta vec je ta, ze do cipu s ARM jadrem se dneska bundluji dalsi moduly - GPU, sitovka...
Docela by mne zajimalo, zda nekdo k tomuto ma srovnani beznych MCU zalozenych na MIPS4K a ARM7TDMI ci nejakem Cortexu.
Jsem zrovna ve fazi rozhodovani a zatim to vyhrava lehce MIPS (PIC32), nicmene v rozhodovacim procesu jsou zejmena jina kriteria nez rychlost.
Videl jsem nejakou studii, nicmene ta byla udelana tak neprofesionalne, ze ji neslo verit vubec nic. A potom jednu otevrenou, ktera vysla zhruba nastejno MIPS:ARM (ovsem metodicky take nebyla uplne koser).