Hlavní navigace

Názor k článku Mikroprocesory ARM a instrukční sada Thumb - dokončení od klusacek - Pokud je dostatek pameti tak, prisne vzato, to...

  • Článek je starý, nové názory již nelze přidávat.
  • 4. 4. 2012 11:09

    klusacek (neregistrovaný)

    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).