A multicore lemaradas talan az m1 big/little felepitesenek koszonheto.
Az osszehasonlitasban vedd figyelembe a fogyasztast is.. az amd-nek is bele kell huznia, hogy beerje, bar ez 5nm -en (esetleg zen4-en) nem tunik eselytelennek. Utoljára szerkesztette: Zsoltee_a_bator, 2020.12.06. 23:29:43
Már egy windows Xp is nagyjából 35 millió forráskodnyi program volt C-ben. Egy Windows 10-ben lehet már simán 120-150 millió sornyi forrás kód.
Csak a microsoft-nal voltak olyan hulyek, hogy nem portabilisre irtak a programokat. Pl. a windows-os bitmap (BMP) formatum fejlece az a windows 16 bites valtozatanak akkori microsoft c forditoja altal generalt ram beli adatstruktura, kiirva file-ba. Ha barmilyen mas fordito altal eloallitott koddal akarod elerni, akkor lehet pakolgatni ki/be a kulonbozo agyhalott mezoket.
Ezzel szemben az apple mar a motorola68k/PPC atallaskor megkovetelte a portabilis kodot. Tehat minden programnak fordulnia es futnia kellett minden architekturan. Ezert tudtak kulonosebb nehezseg nelkul x86-os es ARM-os macos-t forditani. (az x86-os macosx kiadasa elott 2 evig csak teszteltek, hogy modositas nelkul forduljon es fusson minden ppc-re irt kod x86-on is) A legtobb unix is ilyen, pl. a linux-ok mindenen elmennek, meg sok modernebb kenyerpiriton is. Az android is csak egy linux disztribucio a Google grafikus feluletevel (es szolgaltatasaival). Ezert van az, hogy az Android is barmin elmegy. Az ios pedig egy lebutitott macosX, ami ugyancsak egy unix valtozat (posix-os mach kernel van alatta)
Na most inntentol ha egy szoftvernek megvan a forraskodja es nem windows-ra keszult, akkor csak ujraforditod az uj platformra es mar megy is. Van olyan agyhalott linux es bsd valtozat is, amik mindent forrasbol raknak fel, mert akkor minden az adott hardverre lesz optimalizalva. Ez persze nem szukseges, boven eleg az adott hardver csaladra optimalizalni, azt barmelyik fordito meg tudja tenni a programozo helyett. Csak portabilis kodot kell irni....
A szoftvergyartokon mulik, hogy belefektetik-e azt az energiat, ami a hordozhato forraskod eloallitasahoz kell es ha igen, akkor barmilyen hardveren, kis extra munkaval szinte barmilyen os-en is elfutnak a programjaik. (a gnu-s kodok es programok pl. ilyenek, az apple is sok helyen hasznalja oket fel, mert ingyen vannak es jok)
Szoval egyedul az x86-hoz kotott windows-os programok keszitoi vannak bajban. (jellemzoen ezek a microsoft altal gyartottak, pl. office)
ps: A mar kiadott jatekokat is ki lehetne adni ARM-ra (is) leforditva, mint ahogy a doom is fut minden platformon. Ezt szinte barmilyen nem windows vagy konzol exkluziv jatekkal meg lehet tenni. Tehat nem kell ujrairni semmit, csak ujra kell forditani a forraskodot, ha a kiado cegnek megvan meg...
"From ATMs to Printers, Hackers Prove You Can Play 'Doom' on Anything" https://www.youtube.com/watch?v=R6k72DI0Qo0
Kinai SoC gyartas sehol sem tart, 20+ nanometeren gyartanak maximum. Taiwan es Del Korea vezeti ezt az ipart es ezt az elonyt legalabb 10 ev Kinanak behozni, ha ez egyaltalan lehetseges. Huawei is TSMC-vel gyartatta a Kirin chipeket.
Ket dolgot tehetnek, vagy sokkal olcsobban adjak a processzoraikat mint amennyibe az azonos teljesitmenyu kinaban gyartott ARM verziok kerulnek vagy csinalnak jelentosen gyorsabb, kisebb fogyasztasu es olcsobb processzort. Na most olcsobban nem igen tudjak adni, mint a filleres kinai cuccokat gyartok, gyorsabbat ha tudnanak mar csinaltak volna, a kisebb fogyasztas meg eleve az ARM oldalan van tortenelmi (arhitekturalis) okokbol.
Az a lenyeg, hogy az ARM nem 3. gyartokent lep be, hanem 3. 4. 5. ... 100.-adikkent, mivel barki licenszelheti a technologiat. Tehat a ket nagy mono- vagy inkabb duopolhelyzetben levo gyarto helyett most hirtelen lett tobb szaz. Egyertelmu, hogy a verseny gyorsabb fejlodest hoz, de raadasul itt mar a kinai arak versenyeznek a nyugati cegekkel, amibol a nyugati ceg csak akkor kerulhet ki gyoztesen ha kinaban gyartat. Akkor viszont a kinaiak lemasoljak a technologiajat, tehat hosszu tavon a kinai beszallitoja veszi at a helyet.
Az apple eseteben picit mas a helyzet, mert ok nem alkatreszeket gyartanak eladasra, hanem kesz rendszereket, tehat a markajelzes szamit, nem az, hogy amerikai, koreai vagy kinai chip van benne.
Szoftveres virtualizacio van. Meg az x86, ppc, m68k, mos65x emulacio is ugy megy. Ha egy virtualis kornyezetnek van lefordithato, architekturafuggetlen valtozata akkor mar meg is van oldva a tamogatasa. A hardveres optimalizacio csak egy bonusz ha lehetseges. A virtualis szoftver gyartok egyllszeruen nem keszultek fel elegge a hardverfuggetlen uzemmodra. (az Apple viszont jellemzoen hazon belul megoldja)
Az Arm egymagos teljesitmenyben is nagyjabol beerte az x86-ot. Nem kerdes, hogy mi a jovo. Ugyanazzal az aktiv hutessel joval nagyobb tobbszalas teljesitmenyre kepes egy Arm processzor.
A csoda az lett, hogy az intel nem tud olyan gyorsan csikszelesseget csokkenteni mint az arm-ot gyartok. Raadasul a kis lapka meret miatt a prociba tudtak integralni a sokmagos videokartyat is, aminek az a mellekhatasa, hogy az egesz rendszer video ram-ban fut, ami sokkal gyorsabb mint amit az x86-ok hasznalnak.
Lehetne-e gyors x86-ost epiteni? Lehet, csak az intelnek vagy az amd-nek egymagaban nincs akkora kapacitasa, hogy ezt megtegye. Mar az x86-64 architektura is az amd talalmanya volt, tehat az intel az utolso 32 bites x86 ota nem nagyon fejlesztett. Mindezek melle mar a gyartastechnologiaban is lemaradtak, mert az arm-ot annyira nagy tomegben gyartjak annyi helyen, hogy egyszeruen sokkal nagyobb piacca valt es sokkal tobb ceg probalkozik egyre gyorsabbat kesziteni belole.
Gamer pc-be is jo az arm, csak 64 bites valtozatban kell gyartani. A 16 es 32 bites arm tamogatast joreszt mar ugy is kivezettek a mikrovezerlok folott. Az x86 a mai napig 16/32/64 bit vegyes uzemmodu. Egyszeruen annyi szemet jott ossze az x86-os architektura nyakara, hogy az aramkorok tobb mint fele csak ul ott es nem csinal semmit, mert a mai modern programok mar nem hasznalnak 16 vagy 32 bites mikrokodot, regisztereket vagy cimzest.
A megoldas itt az, hogy a regi x86-os kodot at kell forditani a betolteskor arm-os kodda, a videokartyan futo kod pedig maradhat a videokartyan. Igy ha egy jatek keves x86-os kodot futtat es a teljesitmenyigeny (grafika, hang, mi) nagyobb resze videokartya alapu, akkor arm-os cpu-val es load time x86 to arm forditassal pont ugyanolyan gyors lesz mint egy x86-os procin. Ha pedig nativ modon arm-ra van forditva, akkor meg gyorsabb is lesz.
Az android esteten most vezetik be az architekturakra optimalizalt binarisokat. Tehat a fejlesztok feltoltik a minden arm (es egyebb proci) valtozatra keszult univerzalis binarisokat a play store-ba es a store osszeallitja a letolto rendszer szamara a celplatformra optimalizalt apk-s binarist. Igy kisebb letoltendo es tarolando binarisokat kapunk es minden arm-os kod az adott proci verziora lesz optimalizalva, szemben az x86-osok altalanos, szinte minden x86-oson futo binarisaival. (ez mellekesen azt is jelenti, hogy egy root-olt telefonrol kimasolt apk innentol jo esellyel mar nem fog futni mas keszulektipuson) Ezt a keszulekenkenti optimalizaciot vegeztek regen el a konzolokra fejlesztok, manualistan. Ma mar ez teljes mertekben automatizalhato.
ps: A tobb risc processzor fer el azonos helyen esetrol nem is irtam, csak tisztan az egymagos nyers teljesitmenyt neztem. Az arm architektura eredetileg arra lett tervezve, hogy munkaallomasokban es szerverekben gyorsabb legyen az x86-nal es azonos vagy jobb gyartastechnologiaval legyartva hozza is ezt az elvarast.