Vlákno názorů k článku Nastal čas nahradit uzavřené děravé procesory otevřenou alternativou? od Petr M - Tak rozhodně v článku zazněla jedna podstatná věc...
-
Petr M (neregistrovaný)
Tak rozhodně v článku zazněla jedna podstatná věc - je čas zabít platformu x86. To je naprosto bez diskusí.
Průšvihů je tam plno, nejemenší problém je nedostatek registrů (4 na jádro), emulací CISCu na RISCu pomocí zabugovanýho mikrokódu,... Ono už jenom používání segmentů na 286 byla učebnicová prasárna.No a dneska je všechno podřízeno výkonu. Proč? Protože pitomý řádek kódu v Javě, C#, JavaScriptu,... se spustí interpret, emulující fyzicky nerealizovatelný stroj na x86. Jenomže ten výsledný stroják na x86 nevykonává jádro x86, ale interpreter na kdoví čem... Za sebe bych viděl řešení pomocí několika (až desítek/stovek) RISCových jader s vlastní L1 cache. Hlavně jednoduchý (= líp testovatelný, rychlý) s otevřeným managementem. Jde tam líp škálovat výkon, přiřadit aplikaci jádro v reálným čase, řídit spotřebu,... A dělit to jeden sandbox na fyzický jádro a je jistota, že nic nezdrhne přes cache. Pokud si s tím lepič knihoven nebo pánové z Mozilly nevystačí, smůla.
Otázka je, jestli má být jádro open source. Já si to nemyslím. Pod BSD licencí by to bylo peklo, tam to bude jako closed source - o to horší, že dneska je jasná hranice mezi MIPSem, ARMem, x86, ... Pokud se prosadí taková platforma X pod BSD, tak bude najednou hromada jader X-AMD až X-Zilog, který budou mít společnýho předka a specifikaci, ale jiný erraty, jiný bugy a jiný průšvihy. Aniž by někdo odhalil, co tam je blbě. Z tohohle pohledu je lepší to, co má ARM - licencuje jádra, platí z toho vývoj a hlídá si smluvně kompatibilitu. Přitom na stejný jádro nezávisle musí mrknout všichni, kdo si to jádro koupí a cpou do vlastních brouků.
-
mhi (neregistrovaný)
Binarni translace nemusi byt zdaleka tak pomala jak se zda. Delal jsem hloupy translator x86-ARM a kod bez optimalizaci (a s hloupym prekladem) byl zhruba 3-4x vetsi, coz neni ani radove zpomaleni. Navic jednoduchym optimalizatorem resicim preskupovani/vyhazovani/prepis instrukci metodou "obarvovani registru" to slo srazit s prehledem na kod jen 2* vetsi.
-
j (neregistrovaný)
Sak pisu ze uz to tady bylo ... myslis ze v Intelu se nesnazili aby to fungovalo? Dokonce presvedcili M$ aby jim na to widle udelal nativni. Jenze vsichni na tom chteli provozovat ty x86 aplikace, ktery sice bezely, ale naprosto tragicky, a to navic s bonusem, ze Itanium byla platforma pekelne draha.
Pak prislo AMD se svym amd-64 ... a Itanium chciplo definitivne.
Pokud bys chtel nahradit x86, musel bys udelat chip, kterej bude zaroven x86 a zaroven bude zvladat novou architekturu. Tohle bys musel udrzovat HW nejmin 10 let, a pak nejmin dalsich 10 let bys musel udrzovat SW emulaci.
Pricem mezi tim bys asi musel jeste nalejt nehoraznej ranec penez vsem vetsim vyvojarum, aby svoje core aplikace prepsali na novou architekturu - protoze jinam to proste delat nebudou. A na to proste nema silu ani Intel, natoz kdokoli jinej.
Jedina dalsi moznost je takova, ze prijdes s architekturou, ktera bude aspon o rad vykonejsi a zaroven nebude drazsi.
-
mhi (neregistrovaný)
Itanium melo myslim trosku jine problemy, nez zpetnou kompatibilitu. Spousta lidi by to pouzila i kdyby byly na nej prelozene jen MS produkty (SQL server, ASP.NET, apod.). Rekl bych, ze tam nebyla ta spravna pridana hodnota. Ona tam mozna nebyla skoro zadna.
Srovnal bych to s ARMem, to je architektura, ktera pridanou hodnotu ma a verim tomu, ze kdyby byly opravdu otevrene a nativni Win pro ARM (s odpovidajicimi vyhodami - spotreba, optimalizace na rychlost), tak se problem aplikaci vyresi sam.
Ja treba pouzivam hned 2 ARM desky misto stolniho pocitace (jako takovou soft nahradu pro nenarocne veci) a jsem s nimi naprosto spokojen. Rikam jim nevzdelani delnici, trva jim to dlouho, ale delaji spolehlive, muzou delat i pres noc, atd.
-
mhi (neregistrovaný)
Ono tezko srovnavat "stejne vykonny ARM". Podle me podobne procesory (ale jake to jsou????) ARM jsou tak na 3/4 vykonu Intelu. V mem pripade jsem vzal napr. dva podobne lowcost tablety, ovem ten ARM ma obrovkou vyhodu, ze vydrzi asi 3* tolik co ten Intel :-). V potaz se ale musi vzit, ze jeden je W8,druhy Android.
-
Sten (neregistrovaný)
Tohle byl Asus Zenfone vs. Nexus v době, kdy Asus ještě používal Intel. Výdrž měly oba podobnou (než dostal Nexus aktualizaci na Android 6). Výkon srovnatelný, ať už to překládalo ARM nebo běželo nativní aplikaci, a to šlo o aplikaci hojně využívající SIMD (samozřejmě překlad byl trochu pomalejší, bylo to vidět na statistice latence, ale subjektivně jsem to nerozeznal). Byly tam nějaké problémy se stabilitou, ale to se týkalo hlavně získávání backtrace při pádu aplikace,libhoudini nemělo reimplementované
_Unwind_Backtracepro intelovský stack. -
Petr M (neregistrovaný)
x86 je potvora, kterou dneska už úsporně neuděláš. Těch hradel na zpracování mikrokódu, zkratky v pipeliningu, pomocný registry a další bordel je prostě moc. Žerou, zabírají místo a nedají se odstavit.
Na flek jednoho x86 klidně narveš čtyři jiný jádra. No a když si připomeneme, že nejslabší místo z pohledu výkonu je v dnešní době RAMka a z pohedu zabezpečení sdílený uložení dat (od temp registrů CPU přes cache po systémovou RAM), tak má smysl udělat několik malých RISCových nodů se zlomkem výkonu, vlastní cache a vlastním, fyzicky odděleným kusem RAMky. Ušetří se čekání při cache miss, ušetří se čištění cache při přepnutí kontextu, ušetří se režie při virtualizaci (protože virtuály jsou vlastně fyzický nezávislý stroje), ušetří se energie (pro nepotřebný jádro hodíš clock nebo přeladíš PLLko),...
Prostě něco ve stylu ARMovýho APU od AMD s trochu jiným řízením a sdílením pamětí.
-
Petr M (neregistrovaný)
Jo, jenomže právě tohle je ta hrouda hnědé, mazlavé a zapáchající hmoty, co jim právě teče ze střechy po zdi. Zhurba půl čipu je totiž cache a zatímco konkurence ji poctivě maže když je potřeba, Intel na to tak trochu hází bobek.
Je to jako dvě implementace free() v C, kde jedna označí blok jako volný a druhá ho navíc přepíše nulama...
-
Karel (neregistrovaný)
To ano, ale jak začne Intel také "přepisovat nulama", tak je hnedka oheň na střeše, jak se tím CPU spomaluje a že klesá rank v benchmarku atd. Zkrátka si lidé a firmy zvykli využívat toho, že Intel trochu podvádí a dosahuje lepších výsledků na úkor bezpečnosti. Že je ta cena příliš vysoká se zjistilo až po dvaceti letech.
-
Petr M (neregistrovaný)
Nesouhlasím. Dneska u obou jader narazíš s výkonem na RAMku. Je to už vlastně spíš otázka predikce skoků a velikosti/řízení cache, než samotnýho jádra. Prostě to nabíjení/vybíjení kondíků v RAMce rychlejší neuděláš. Řeší se to přidáním bitů a jejich multiplexem, dual channel RAM,... A snižováním napětí, šlo to postupně z 5V na 3,3V (SDR), 2,5V (DDR1), 1,8V (MDDR1, DDR2), 1,5V (MDDR2, DDR3),...
-
atarist (neregistrovaný)
Taky nemam x86 rad, uz od dob 80286, kdy IMHO uz tak divnou architekturu jeste vic dodrbali, jenze ta architektura ma dneska prakticky nejvykonnejsi dostupne cipy:
https://en.wikipedia.org/wiki/TOP500#Top_10_ranking
https://en.wikipedia.org/wiki/TOP500#/media/File:Processor_families_in_TOP500_supercomputers.svg (ten obrazek je neskutecne hnusnej s tema vzorkama vyplni)"Za sebe bych viděl řešení pomocí několika (až desítek/stovek) RISCových jader s vlastní L1 cache."
Tomu je blizko RISC-V nebo starej dobrej MIPSU ARMu jako jaker asi problem neni, jenze u vetsiny SoC je tam porad ten binarni blob, ktery nikdo neuvolni, protoze patenty a kody tretich stran :( Coz sice souvisi s HW jen castecne, ale otevrena architektura to neni.
