Diit.cz - Novinky a informace o hardware, software a internetu

Diskuse k Elbrus Technologies má x86 emulátor pro ARM, pracuje na zrychlení

Což má ale jeden logický závěr, který autor článku opomenul zmínit: Je jen otázkou času, než zareaguje Intel žalobou (vlastní licence na x86), kterému se rozhodně nebude líbit, že by kód normálních oken běžel na ARMu.

+1
0
-1
Je komentář přínosný?

jenže dle mého SW emulace pod to nespadá, protože se nejedná o fyzický procesor, který by bylo nutno licencovat.

Už se nepamatuju jak to bylo s Transmetou, a ta bych řekl že měla své řešení daleko "closer to metal"

+1
0
-1
Je komentář přínosný?

Pokud se nepletu tak spadá pokud je komerční

+1
0
-1
Je komentář přínosný?

Mě by spíše zajímalo, v čem je takový emulátor odlišný od DosBoxu a QEMU. Mám Pandoru (ARM 600 MHz, přetaktovatelný skoro k 1 GHz a novější verze jsou 1 GHz nativně, přetaktovatelné cca do 1,2 GHz) a obojí na tom funguje OK (přiměřeně výkonu CPU).
Nezkoušel jsem, ale jsou lidi, kteří na Pandoře (přetaktované na 800 - 900 MHz) bootují Windows 95 kvůli některým hrám. Starcraft je údajně použitelný, byť pomalejší, než originál.

+1
0
-1
Je komentář přínosný?

Respektive, vůbec bych se nedivil, kdyby молодци překopali nějaký OSSW emulátor a dali mu svoji nálepku. Tím nechci tvrdit, že to tak je. Ale jak z nich něco vypadne, tak se jim na to určitě někdo z ochránců svobodného SW mrkne.

+1
0
-1
Je komentář přínosný?

:-)

+1
0
-1
Je komentář přínosný?

Pojem Elbrus mi není neznámý, je to nejvyšší hora v Rusku.

+1
0
-1
Je komentář přínosný?
+1
0
-1
Je komentář přínosný?

Po přečtení toho odkazu jsem se už dlouho tak nezasmál, jak byli někteří lidé v roce 2001 naivní :)

+1
0
-1
Je komentář přínosný?

No mně se to zdá jako pohádka vycucaná z prstu. Instrukční sada x86 a ARMu má společného asi jako čeština s němčinou, takže emulátor běžící na ARMu určitě nemůže spouštět kód x86 a mít při tom režiji jen 20% Pokud něco takového vznikne, vyděl bych to na 10% reálně využitého výkonu, zbytek emulace. Leda, že by před spuštěním kódu došlo k nějakému předchroupání. Ale třeba se úplně mýlím.

+1
0
-1
Je komentář přínosný?

Takže simultánní tlumočení z jednoho jazyka do jiného je nemožné? Chápu, je to příměr, ale ta emulace je hodně o překladu instrukcí a trochu o překladu volání HW.

+1
0
-1
Je komentář přínosný?

emulace: načtu instrukci -> rozhodnu, co s ní -> nahradím ji v lepším případě jednou instrukcí, v hořším případě sledem několika instrukcí, které udělají to samé co dělala původní instrukce určená pro jinou architekturu + jiný přístup k HW. Ta rozhodovací režie, bude vždy majoritní. Takže 80% (i těch 40%) mě nepřijde reálných.

+1
0
-1
Je komentář přínosný?

Je fakt, že ARM je RISC, ztímco x86 CISC. Takže máš recht, že ten překlad bude muset často dělat něco navíc...

+1
0
-1
Je komentář přínosný?

Ono se to už dneska tak nebere. Dnešní x86 cpu si drží strukturu "CISC" co to jen jde, ale při konečné operaci výpočtu na ALU už jsou zasílány nekomplexní operace "RISC".

+1
0
-1
Je komentář přínosný?

emulátor by mohl fungovat podobně jako Dalvik VM v Androidu. Dalvik spustí aplikaci v interpretovaném režimu, za běhu identifikuje místa, kde aplikace tráví hodně času, a ty pak přeloží do nativního kódu. Aplikace pak běží skoro stejně rychle jako kdyby byla celá zkompilovaná do nativního kódu.

+1
0
-1
Je komentář přínosný?

...aaa elbrusákov dobre poznám. Svojho času v sovietských/ruských kruhoch procesorovej temnoty vytvorili CPU, ktoré keby bolo komerčne úspešné tak ešte dnes by architektúra bola s minimálnymi zmenami v návrhu výkonnejšia než posledné CPUčka x86. Veľmi som im fandil. Ale ako to už býva v Rusku, je za tým len jeden génius a proti nemu kopec byrokratov. Architektúra sa vyvíjala 25 rokov a prešla 3-ma veľkými genézami. Neviem čo s tým emulátorom majú, ale svojho času mali x86 emulátor aj na ten svoj CPU. A výkon bol vynikajúci.
Procesor E2K, bol explicitne paralélny s pevným inštrukčným IPC navrhnutý istým Borisom Babaianom. Vzhľadom k tomu, že aj v rusku treba z niečoho žiť tak sa začali orientovať neskôr na SPARC arch. a teraz ARM. Paradoxne postupne k slabšiemu a k slabšiemu. Ale ako dnes už všetci vieme s výkonom je to relatívne. S tými E2K tuším mútili vodu len v sovietskej/ruskej armáde.
Tieto emulátory neprekladajú x86 kód simultánne, ale softwarovo si "predkompilujú" celé sekvencie inštrukcií, uložia do pamäte ako vlastný natívny kód a takto "nakešovaný" program potom letí co by dub. Sem tam sa niečo dokompiluje trocha to spomalí ale je to podobné ako s klasickou keškou. Je to síce moc zjednodušený popis moderných emulátorov, ale na ilustráciu ako môže byť iný CPU podobne výkonný s vlastným kódom iného CPU to asi stačí. Len tak pre zaujímavosť:

Procesor E2K má až 2x 256!!! unifikovaných 64-bitových registrov (INT a FP sú dokopy) na to sú pevne napojené 3 paralélne komplexné ALU/FPU, a jedna WLIV inštrukcia ovláda naraz všetky jednotky. Tretia implementácia Elbrusu presne pripomína Buldozer od AMD (a že vraj priekopnícka organizácia výpočotvých jednotiek. Prišla o 10 rokov neskôr!)
To znamená, E2K má jednu inštrukčnú cache 64kB jednu zdvojenú dekódovaciu jednotku, dva trojité ALU/FPU a na jeden registrový súbor pripadá vlastná D-cache 8kB. Takže dokopy 16kB. Až na FPU je to to isté ako u Bulldozera. "FPU" je typu single-clock, takže je vlastne súčasťou komplexnejšej ALU. Ten Boris B. tvrdí, že INT/FPU dokopy s veľkým počtom unifikovaných registrov je lepší. CPU má vysoké IPC (2x3). O vysoké IPC v kóde sa musí postarať už len kompilátor/programátor. Dekóder je len jednoduchý. Ale to je vlastne typická filozofia WLIV procesorov, aby to celé malo nízku spotrebu, vysoké frekvencie, kratšiu pipelinu a málo tranzistorov.
Škoda. Toto mal byť procesor budúcnosti. Pôvodný návrh E2K s 256kB L2 mal hodne vyšší výkon než Itanium od Intelu!!! Súčasné ARM Cortex-i majú vjac tranzistorov než E2K. O výkone ani nehovorím. História ukazuje, že nie vždy to dobré zvíťazí. Pamätáme VHS/Beta, 8086/68000.... Za to si ale asi môže krajina sama odkiaľ ten procesor pochádza.

Sorry za dlhý komentár.

Zopár linkov.

http://www.mcst.ru/2-3.htm
http://sp.cmc.msu.ru/win/courses/e2k.pdf
http://www.itnews.sk/spravy/produkty/2004-03-19/c119612-stane-sa-mikropr...

+1
0
-1
Je komentář přínosný?

Vůbec to nebylo dlouhé, díky za info :-)

+1
0
-1
Je komentář přínosný?

Pěkně popsáno, jen srovnání s BD poněkud nesedí. U BD se každý kluster stará o samostatný thread, kdežto tady ne. Také fpu je řešeno ala Intel, tedy naportované na ALU0,1,3 a 4.
A teď si ale při pohledu na diagram cpu neodpustím jednu poznámku. Kolik asi patentů ti rusáci nakradli po světě, hlavně v počátcích vývoje?

+1
0
-1
Je komentář přínosný?

Ne, ne.. S BDčkom to má hodne. Zabudol som ešte dodať: E2K má pochopiteľne 2thready. Na VLIW procesory sa musíš dívať truchu ináč. Svet x86 sa posudzuje už dnes cez zabehnuté šablony a tieto CPUčka sú z hľadiska architektúry iný "svet". Základ u týchto CPU je snažiť sa vykonať všetko programovo na jeden takt a neskákať v programe hore/dole. Superskalárne FPU ako samostatnú jednotku s vlastným shedulerom tu nenájdeš. Proste SIN/COS/LOG si musíš naprogramovať, pretože ALU je jednoduchá. Na úrovni hradiel tam realizované hradlá len pre ADD, AND/NAND, OR/XOR, inv. ADD, rotáciu, jednoduchú násobičku pre exponent a mantisu napojené až na šesť portov RF a to je vsjo. Nepchať tam do inštrukcií všeliaké ROTácie, v ľavo v pravo, SHIFTy, cez carry bez carry....keď takú rotáciu v ľavo urobíš aj s XORom a jedničkou, na nulovanie máš Zero register, NOP inštrukciu urobíš ako ADD R0,R0,R0 a HaLT urobíš cez JMP.... Márne tu budeš hľadať podľa nejakej šablónky FPU alebo niečo podobné. To je typická ALU plnokrvného RISCu.

Stiahni si sympatický freewarový programik Logisim na simuláciu jednoduchých hradlových polí a procesorov. Tam pochopíš prečo je ALU v dnešných procesoroch taká prťavá a okolo toho je len balast presahujúci xx-násobok tejto plochy, len aby si mohol efektívne kŕmiť túto výkonnú jenotku. Jednotlivé združené hradlové polia ovládaš logikou cez porty a vytváraš množstvo kombinácií (iných inštrukcií) z elementárnych aritmetických a logických operácií v jednom takte v malom počte hradiel. Inštrukcie x86 niesu tomu výnimkou len táto architektúra ako predstaviteľ CISCov obsahuje už také inštrukcie, ktoré musia byť shedulerom skládané ako postupnosť logických operácií. VLIW idú naopak proti tejto filozofii. Ohlodať to až na kosť a RISC inštrukcie vykonávať čo najviac paralélne. Obrovské množstvo registrov sú samozrejmosťou.

Čo sa týka tych rusákov, vyzerá to tak, že boli tlačený oveľa skôr do optimalizácie návrhu vlastných CPU než západ pretože nemali technológiu výroby. To prvnenstvo v patentoch by som im až tak nebral. "Hotový" E2K tu bol už na prelome rokov 2000/2001. Budem ti oponovať, ale...
Ako keby Inteláci pajcli tento návrh a prispôsobili ho na x86. Širokú VLIW inštrukciu "vyrobý" celý ten balast prídavnej logiky na Core2(a neskorších CPU) a simultánne prispôsobuje/preskupuje... inštrukcie do paralélnych ALU/FPU špecificky upravených pre potreby sveta x86 v jeden takt. Ako tak sa to intelu podarilo priblížiť k výkonu VLIW procesorov skrz sveta X86.

Koniec koncov nakradnúť patenty to nie je len tak. Čo sa mi marí z toho debilného americké patentového práva, pokiaľ by som aj čerpal rozum z tých najmúdrejší a najšikovnejších amerických odborníkov a obchodníkov, pokiaľ si to doma nechám na papiery a nebudem to predávať tak som sa ničoho nedopustil. A nechápem prečo by to mala byť potupná hamba pre Ivana, že čerpal rozum zo západu. Zopár nobeloviek na rozdiel od nás tam majú, takže prečo by to aj nezvládli. To nerieš, ak to predávajú, a Intel, AMD, ARM a pod. proti tomu nič nemajú tak je to ošetrené! Len si musia dať pozor na to aby ich čip nemal obdlžnikový zaoblený tvar, lebo by s nimi mohol zatočil Apple. :D

sorry, zase kilometer textu.

+1
0
-1
Je komentář přínosný?

Myslím, že se mýlíš. Podle toho schématu je cpu rozděleno na dva klustery pouze z důvodu propustnosti dat a nikoliv threadů.
Pokud je mi známo, tak od VLIW se postupem času upouští právě kvůli nemožnosti HW shedulingu - vše je řízeno SW kompilátorem.
Jinak u x86 jsou také nakonec "CISC" instrukce rozděleny na "RISC" jednoduché instrukce, které jsou (pokud to jde) prováděny paralelně - ILP.
Ať koukám, jak koukám tohle je imho předem odsouzeno k neúspěchu. Stačí vzpomenout na Transmetu, která měla imho mnohem lepší zázemí.

+1
0
-1
Je komentář přínosný?

Jojo, máš pravdu teraz sa od VLIWov upúšťa. Internet je plný príčin ich konca, ale asi medzi najpodstatnejšie príčiny patria tieto:

- ten kompilátor vyzerá ako spásonosné riešenie všetkého, ale vývoj kompilátorov zaostával. Jediné životaschopné VLIW CPU Itanium malo s tým problém. A ani intel po rokoch sa v tom výrazne nezlepšil. Podobne ako aj i860. Škoda. keby bol, tak je to bezpredmetné.

- architektúra je silne zviazaná s inštrukčným formátom a ďalšia paralelizácia, pridávanie ďalších jednotiek alebo inštrukcií u novších generácií CPU je značne obtiažné až nemožné.
(neviem, mne to tak nepripadá, že by som niečo vytkol 13+ ročnej architektúre ktorá má IPC=3 cca ako Sandy, Ivy.. a 256 registrov) Tento argument mi pripadá, že sa to týka 64bitových MIPSov, alebo i860 tie boli také poloVLIW, mali 2 32bitové inštrukcie v jednom 64bit slove. pre IPC=2. Ak sa nejedná o SIMD inštrukcie tak bežný program dostať nad IPC=3 je už až nemožné. Ak by vtedy VLIW/EPIC naštartovali, tak 20 rokov sa nemusí nič riešiť. Snáď tie SIMD)

- brutálne "plytvanie" pamäte inštrukčnej časti programu (nie dát).
Tu si dovolímm poznámku, že v čase keď im bolo odpískané bojovali sme ešte s "megabytmi", dnes v ére gigabytov by to už bolo bezpredmetné..)

Čo sa týka tých threadov.. Nie nie, to nerieš. Svojho času som sa o tom CPUčku toho očítal hodne. Je to na 100% "bullldozerí" dvojjádro. Na to vem jed.
(Rusáci jedný rusácky, že oni už vtedy špijónovali u AMD... ;)

+1
0
-1
Je komentář přínosný?

Celou dobu co jsem teto thread četl jsem chtěl vykřiknout: VLIW je super, ale pokud nemáte programátora (dnes kompilátor) který vyplivne optimální kód co využije všech jednotek, tak máte po výkonu (IPC).

+1
0
-1
Je komentář přínosný?

presne tak.

+1
0
-1
Je komentář přínosný?

Explicitně paralelní architektura - tzn. to samé co Itanic?

+1
0
-1
Je komentář přínosný?

EPIC ano :)

+1
0
-1
Je komentář přínosný?

Myslím, že je to lepší řešení než Windows RT. V mnoha firmách (malých i velkých) pro specifický účel je používán x86 software, který není třeba měnit, nebo ho updatovat (natož upgradovat) je nepřiměřeně nákladné.
Navíc dnešní procesory mají výkon tak velký, že do kanceláří mohou kupovat ty nejlevnější. Z toho úhlu pohledu vítám emulaci x86 na ARM (android/linux).

Bude mít wintel konkurenci = bude se víc snažit.

+1
0
-1
Je komentář přínosný?

Musíš to brát tak, že žádný x86 emulovaný cpu se zatím neuchytil a zřejmě ani nikdy neuchytí.
Řešení MS je elegantní a prosté. WinRT i WMx využívá (krom html a Java) NET framework jehož součástí je také WPF, takže nástroje pro vytváření aplikací a UI. Vytvořená aplikace je překompilována do (MS)IL (abstraktního kódu), který pak běží na jakékoliv platformě, které má JIT překladač z IL pro dané ISA. Jako programátor se vůbec nestaráš, pro jakou platformu vlastně vytváříš aplikaci. Pokud se tedy nezabýváš "close to metal" programováním třeba v C++, pak bys musel kompilovat do binárek daného ISA.
Samozřejmě to ale neřeší již existující aplikace nepsané pro .NET

+1
0
-1
Je komentář přínosný?

Proč používat takovejhle ohejbák na narovnák?? Co je na tom tak těžkého psát multiplatformní kód? Když si pohlídám velikost intů a pointerů, tak mi stačí stávající kód (třeba v C/C++) jenom přeložit pro jinou platformu a program mi poběží na 100% výkonu ARMu nebo čehokoli jiného (teď mě napadá třeba nové x32 Linuxové ABI).

Z praxe vím, že to není zas tak triviální, ale dodžovat (třeba C++) standard moc práce navíc nedá, teď dělám pro Win32, Win64 a MacIntel64.

+1
0
-1
Je komentář přínosný?

Ono ta velikost intu a pointeru na ARMu je mozna dokonce stejna ... problem je v tom, ze zatimco dodrzovat standard tolik prace neda, projit existujici kod (a IMHO je kod spousty firem mene prehledny nez opensource) a opravit co ty standardy nedodrzuje je tezke. Nemluve o te hromade firem, ktere proste nejsou ochotne sve zdrojaky prelozit pro jinou platformu. Nebo se uz polozili a zdrojaky skartovali.

Ale je to vazne smutne. Chtelo by to alespon jednou udelat tlustou caru za veskerym tim zastaralym srotem. Ono i ty dnesni "x86" procesory obsahuji hromadu narovnavaku na ohejbaky, akorat je to integrovane na jednom chipu.

+1
0
-1
Je komentář přínosný?

V C++ se můžeš přiblížit HW blíže, než je zdrávo a to nejen díky ukazatelům.
Navíc výsledná zkompilovaná binárka je platná pouze pro dané cpu(ISA). Platí tedy, že každá ISA bude mít svoji vlastní binárku. To je ale nevýhodné třeba pro MS, musel by si ve svém Windows Store držet vždy dvě binárky jedné aplikace - x86 i ARM. MS to tedy řeší celkem elegantně pomocí NET framework.... viz můj příspěvek výše.

+1
0
-1
Je komentář přínosný?

Nemusi se drzet dve binarky - v jedne muzou byt oba kody :) Sice velikost distribuce naroste ale je to problem? Neni... i Apple to pro prechodnou dobu tak praktikoval, kdy byly PPC i x86 kody v universal-binary.

Zastavam nazor ze jakakoliv virtualni binarka je blbost. At je to java, android nebo winrt. Vzdy je tam omezeni vykonu a omezeni nativity.

+1
0
-1
Je komentář přínosný?

To webwalker: Uff tak .Net bych sem netahal, <rejp>tím nejde udělat pořádná aplikace</rejp>. O tom že Windows umí nějaký druh fat binary nevím, ale nebude mi dělat problém z jednoho kódu generovat dvě binárky, jednu zvlášť pro x86/x86-64 (tam si fatbinary jde udělat ručně) a druhou pro ARM.

To danieel: WinRT je podle mě API Metro-Windows a ARM-Windows, ale nejsem si jistý, a dá se proti tomu programovat v čístém C, takže bych to s Javou nebo .Net nemíchal. S omezením výkonu a nitivity samozřejmě souhlasím.

+1
0
-1
Je komentář přínosný?

Že by v NET framework nešla udělat pořádná aplikace? Hmm, tak to slyším poprvé. Mohu-li se zeptat, už jsi někdy tvořil aplikaci pod NET? Nebo děláš jen kodeky, drivery ap.?
MSIL (nyní CIL) není žádná binárka, nýbrž abstraktní a na platformě nezávislý kód. Binárka z něj vznikne až při kompilaci na danou platformu (JIT nebo AOT). Co se výkonu týče, není nic jednoduššího nežli si to vyzkoušet sám :)
Jen tak mimochodem, HSA od AMD bude pracovat na podobném principu a tam se kompiluje do ISA gpu.
Jinak pokud vím tak ano, WinRT i WM8 podporují nativní C, ale opět pozor - jedná se o unmanaged kód (opět problémy s přenositelností, jak jinak).

+1
0
-1
Je komentář přínosný?

Pro psaní komentářů se, prosím, přihlaste nebo registrujte.