Názory k článku Intel končí s plány na x86S, navrací se ke standardní x86, Qualcomm vyhrál dílčí bitvu o ARM
-
kopfikStříbrný podporovatelnejde jenom o OS, ne? naopak většina OS je v 64 bitech dostupných. jde o aplikace, ne o OSy. ano, i ty OSy by potřebovaly upravit, protože přestože jsou to 64 bitové OSy, tak například boot proces je stále stejný legacy systém, kompatibilní s 8086, který startuje v real mode který má 16 bitů a umí adresovat 1 MB paměti... následně záleží na tom jestli je nastaveno legacy boot aka MBR anebo UEFI... v prvním případě přepíná bootloader CPU do protected režimu, kde připraví víc paměti a při loadování kernelu se přepne do long režimu... v druhým případě umí rovnou launchovat long mode... stále tam je ale real mode ve kterým načítá bootloader... takové úpravy OSů pro X86S by ale byly relativně snadno aplikovatelné...
podle mě je daleko větší problém kompatibilita aplikací. průmysl není ready na 64bit-only svět. průmyslu může trvat až 50 let se přizpůsobit změnám... prostě nejsou biliony na kompletní výměnu technologií ve firmách.
edit: odepisoval jsem s nepřesnou znalostí. X86S umí spouštět 32 bitové aplikace pomocí speciální kompatibilní vrstvy a kompatibilita by měla být automatická. podpora by vypadla pouze pro 16 bitové aplikace.22. 12. 2024, 23:40 editováno autorem komentáře
-
X86S na aplikace nemá vliv - stačí si o tom přečíst přímo na stránkách Intelu.
Podle mě to je zbytečné neudělat - X86S je jen o OS (dnes všechny 64-bit) a bootu (a to bude vyřešené u nového HW), takže já osobně moc nevidím důvod to neudělat, ale díky tomu, že Intel už nemá ani na kafe pro zaměstnance asi nemají prostředky na to zjednodušit jejich CPU a konečně vyhodit tu nesmyslnou segmentaci.
-
podle mě je daleko větší problém kompatibilita aplikací
Ano a v tomto případě ta kompatibilita jenom škodí. Cca 23 let tady máme desktopový 64b procesor. Stále vidím hromadu procesů v task manageru (ano, widle), které jsou 32b. A ne, nejedná se o procesy microsoftu, jedná se o další software. Jsou to letošní, tedy aktuální, verze - nikoliv 23 let staré :-D. Oni jsou opravdu neschopní to za 23 let zkusit a případně opravit na 64b?
Další méně související věcí je, že cca 18 let tady máme desktopové multijádrové procesory. Kdy přibližně tato informace projde k těm progům?
V tomto je podle mě lepší tu kompatibilitu zahodit (tak jak to dělá třeba apple), jednou za čas změnit HW a tím donutit ty progy nejenom na přepnutí mezi 32b a 64b, ale třeba mezi zcela jinými ISA. A je tam hromada jader, takže jestli chcete, aby vám ty programy vůbec nějak běžely, tak se konečně naučte multithreading.
Takže za mě, Ampere One 192 jader do každé rodiny a od školky vše psát multithreading :-D
Jako vážně. Nezajímá mě průmysl, kde je 50 let stále stejný procesor (je to jednom jaderka, nebo i jedno, max dvě další odvětví?). Bavme se o desktopu. Kde přesně je kompatibilita vhodná? Opravdu dneska někdo potřebuje spouštět 16b appku jako binárku? A opravdu to potřebuje spouštět na nejnovějším threadripperu, když to před tím běželo na 286?
Já žádnou potřebu kompatibility nikde v reálu nepozoruju. Všechny moje unixy jsou od první možné chvíle čistě 64b (zcela bez možnosti spustit 32b) a nikdy jsem nenarazil na software, který by vyžadoval 32b režim. Takže jak na linuxu nebo freebsd jedu jen na 64b a kupodivu to jde zcela bez problémů.
-
Souhlas. Všechno non 64bit by se dalo navázat na vyjímku chybné instrukce a pustit emulátor. Koneckonců takhle už i 486 BIOS emuloval loadall (podobně jde v kernelu takhle emulovat cmov a cmpxchg64 na 486 :-D ).
Vyčistil by se tím prostor pro mikrokód. Teda doufám, že ty přepočty v 16bit módu nejsou natvrdo v hardwaru (jinak by ty sčítačky/nebo bypass pro 32bit teda dělaly pěknou latenci).
Jinak na ryzenu se nedá bez patche spustit ani vanilla win98, zen nějak jinak zpracovává TLB invalidaci.
-
Pokud aplikace nejsou od začátku psané s ohledem na podporu 64bit, tak to není otázka přepínače v kompilátoru. Na 64bit nepojedou a snaha o portaci je jako napsat to znova od nuly. Do toho nikdo neinvestuje.
32bit aplikace zůstanou 32b, dokud za ně uživatel bude ochoten platit a dokud jim bude 32bit adresa stačit. 64bit OS je pro ně výhodou, celých 4GB může využít user space, kernel je jinde.
I na Win11 je MSEdgeUpdate 32bit process.
-
-
x86 je jediná architektura na světě, kde přechod na 64bit znamenal snížení výkonu.
To by mě zajímalo, jak je tohle, alespoň teoreticky, možné. x86-64 má více a širších registrů (16x64b), má povinné SSE2 (dalších 16 registrů, a hned 128b), takže v úplně nejmenším případě při překladu se víc proměnných vejde rovnou do registrů a bude méně výletů do paměti (nebo alespoň do cache).
Zatímco ve 32b nebyl ani spoleh na to, že to má FPU.
Takže už jenom garantovaný počet registrů musí vést k vyššímu výkonu.
-
Říkám: "ne jednoznačný".
Hodně dlouhé pole pointerů s náhodným přístupem je na 64bit pomalejší. Větší struktury, které utečou ze 64B/128B cacheline a podobné drobnosti umí ve specifických případech výkon taky zabrzdit. Někdy to jde přepsat, jindy ne. Obecně je podle mě díky počtu registrů kód rychlejší, ale každý provozujeme trošku něco jiného. -
širšie registre sú úplne zbytočné, ak používaš 32bit int. SSE je tiež využiteľné len na špecifické výpočty kde sa robia rovnaké operácie na veľkom množstve dát. 64 bit kód je dlhší, pointre zaberajú viac ram, je väčšia šanca, že niečo nevojde do cache. Nič z x64 neviem využiť, GUI framework nepotrebuje 64 bit aritmetiku, ten možno používa najviac CPU (veľký stromový grid) + sqlite.
-
Ondra Satai NekolaZlatý podporovatelJak už tu padalo, záleží od toho, co se v apce děje. Rozhodně není pravidlem zpomalení.
-
-
Vis pane hloupej, na tech 8mibitech se typicky cela hra vesla vcetne grafiky do 30kB. A taky naprosto typicky byla radove zajimavejsi a hratelnejsi nez soudoby hnojomety se stovkama GB.
Vlastne upgrejd ... sem si rikal, ze minecraft je (specielne kdyz se pouzijou mody) javove nehorazne rozezranej ... do okamziku, kdy sem otestoval ... Vintage Story, coz je defakto nemlich totez v C#. Bez modu to spapa hnedle po zapnuti 20+GB ramky (ty HW pozadavky na webu jsou totalni blabol).
-
DannyStříbrný podporovatelAkorat v tech 30kB jste byl rad za rozliseni na urovni PALu ;-) Pravda, ono lepsi zobrazovadlo jste tehda asi ani nemel. Srovnavate hrusky a vejce, dneska podobne mazaniny nadchnou mozna jako nejake retro. Ale silne pochybuju o tom, ze i to zobrazovadlo na vasem stole zakrnelo u VGA, jiste i rozliseni vasi obrazovky bude vyssi... a tudiz i naroky na RAM budou jinde, nez s tim osmibitem.
-
Ondra Satai NekolaZlatý podporovatel
Ono nikde neni psano, ze se podobna zmena nespecifikuje v kooperaci s dalsimi firmami. Tohle "zruseni" jen je ukonceni jednostranne specifikace ze strany Intelu, je mozne (pravdepodobne?) ze se neceho takoveho dockame na jinem hlavickovem papire.
-
Tak i ty dekodéry se postupně vyvíjejí (ostatně třeba u Pentia 4 to byla snad jediná solidní část, co pak v kombinaci s mikroarchitekturou Pentia M umožnila vznik Core) s tím, že dneska Zen dokáže ARMu konkurovat jak v efektivitě, tak v IPC. Upřímně smekám před machrama, co ty dekodéry a jádra navrhují, neb je šílený, jak zvládají AMD64 "ždímat" i se zachováním zpětné kompatibility.
-
Ty dekodéry se moc nevyvíjejí, jen se jich přidává víc a spousta z nich dělá zbytečnou práci, protože když začneš dekódovat první instrukci, tak nevíš, kde bude ta další dokud nebude celá dekódovaná.
Řešení je mít mnohem víc dekodérů a práci některých z nich prostě zahazovat, protože se CPU netrefil. Další řešení je uop cache, kterou ty ARMy nepotřebujou (Apple Silicon třeba žádnou nemá, dekodování je tak jednoduché, že by to nic nepřineslo).
Toto všechno ale znamená vyšší spotřebu v případě x86.
27. 12. 2024, 01:08 editováno autorem komentáře
-
Co vím, tak AMD a Intel mají cache na 6 instrukcí pro nejvnitřnější cykl programu. Ale to je jen pro specifické situace (stejně jako třeba Hyperthreading - 2 dekodéry vedle sebe a ať se stará OS a aplikace, musí si samy rozdělit práci na 2 vlákna, pokud to vůbec jde). 8 instrukcí za cykl umožnilo Applu a Qualcommu procesor zjednodušit a dost věcí neřešit. Což usnadňuje zvýšení výkonu "přidáním více tranzistorů" (tj. neroste exponenciálně velikost čipu a spotřeba).
-
Okej, ale pořád se bavíme o situaci, kdy AMD64 APUčko dokáže mít v zátěži srovnatelnou efektivitu jako ARM SoC bez danýho balastu. Buď teda v AMD sedí naprostí machři, co umí navrhnout daná CPU tak, že i s takovou penalizací jedou extrémně efektivně, nebo ta penalizace oproti ARMu není tak velká.
Samozřejmě vidím, že ARM je papírově mnohem elegantnější, než AMD64. Jenže v reálném světě dokáží AMD64 APUčka ARMové stroje dorovnat, v HPC a workstation segmentu pak AMD64 CPU v podstatě nemají konkurenci - AMD64 + GPGPU v posledních dvou dekádách brutálně vyvraždily veškerou RISC konkurenci + Itanium, byť papírově se nic takového nemělo stát. Ostatně proto Intel tolik investoval do Itania a proto bylo uvedení AMD64 a Opteronu pro Intel noční můra, což ilustruje výrok "I hate AMD!", nímž tehdejší senior vice-president Intelu v roce 2006 reagoval na Opteron. Aby to bylo ještě vtipnější, ten SVC se jmenoval Pat Gelsinger. https://forums.overclockers.co.uk/threads/intel-cheif-i-hate-amd.17632997/
-
-
-
kopfikStříbrný podporovatel
drtí je v efektivitě. MIPS/Watt...
ARM by byl určitě lepší volbou, pokud bude na míru šitý a spárovaný se správným HW akcelerátorem pro optimalizaci potřebného výkonu... oproti tomu je ale X86 velice univerzální a takové zařízení má daleko větší možnosti použití i s výhledem do budoucna. stačí aby se ve světě stala jedna významnější změna a systémy s ARMem se speciální hw akcelerací se v critical missions stanou ze dne na den e-waste, protože buď potřebojou novej HW akcelerátor, kterej je často vytisknutej litografickou mašinou na stejnej kus křemíku jako ty ARM CPU, anebo se musí smířit s výkonem 0,0xyz oproti konkurenci. zato při výměně takovýho X86 serveru jde po dvou letech používání server využít na další bambilion use case. zatímco slaboučkej ARM CPU se starým HW akcelerátorem skočí na skládce. -
Intel dokáže mít nízkou spotřebu v idle (AMD s tím zatím bojuje), ale ARM vítězí ve střední zátěži (20 tabů v prohlížeči, Teams, Steam, Discord, mail a office - i ty v moderních verzích v pozadí furt něco dělají). Dále ARM zabírá poloviční plochu pro stejný výkon (srovnání podobného Qualcommu a Intelu), tedy má prostor - a využívá toho hlavně Apple - tam "zadarmo" naflákat akcelerátory pro typické usecasy, kterými pak "podvádí".
-
Intel tu spotřebu v idle naháněl jádry na centrálním čipletu. Jinak okolo plochy nemá smysl brát Intel jako referenci (očividně zrovna tady leží bolístka jejich SW nástrojů na návrh jader), zde má v AMD64 navrch AMD.
Ohledně akcelerátorů jsem pak sám rozpolcený. Na jednu stranu jsou super, na druhou stranu je v reálných use-casech plně nevyužívá ani sám Apple (kupříkladu Apple Intelligence z velké části "louská" GPU, nikoliv NPU).
-
To si upřímně nemyslím. AMD64 / i686 je v podstatě jen front-end pro voodoo, co se děje na samotným jádře. Pochybuju, že by vyházením podpory 32bitového režimu ušetřili dost křemíku na to, aby to udělalo citelný rozdíl v ceně a spotřebě (kór když dneska solidní power-management, co má AMD, umí nepoužívaný křemík efektivně vypínat / uspávat).
Jestli má AMD64 nějakou výraznou výhodu proti ARMu a RISC-V, je to právě gigantická knihovna SW, co se na ni za ty roky nashromáždila a zpětná kompatibilita se skoro vším. Na ARMovém Macu jsem třeba jeden legacy vizualizační SW na výstupy z QM výpočtů musel překládat pod Rosettou (neb tam někdo vnesl AMD64 specifický kód, co mi GCC pro ARM odmítl přeložit) a ještě to dál tunit. Na ThinkPadu s AMD64 CPU to prostě přeložím (akorát jsem musel sáhnout po GCC 13 a starším) a jedu. Pokud by rozbili zpětnou kompatibilitu, přijdou o primární selling-point. Ostatně i díky tomu vytlačilo AMD64 RISCové architektury (MIPS, Alpha, SPARC...) z HPC a workstation segmentu.
-
x86S nerušilo zpětnou kompatibilitu, furt by jsi měl 64bit OS a v něm spouštěl 64 a 32bit aplikace. 16bit tam nejdou spouštět už teď a pro staré 32 a 16bit OS stejně nemáš ovladače ani pro čipset. Význam podle mě byl, že by se hodně zjednodušilo testování - mnohem méně situací (např. jak se chovají instrukce, adresace a práce s pamětí pro různé módy). To by umožnilo rychlejší vývoj jader, aby x86 tolik nezaostávalo, protože by se nebáli do nich více "hrábnout".
A jestli nějaká aplikace má natvrdo kód pro nějakou architekturu, tak to je docela risk. Má se vždy napsat obecný kód, a pak optimalizovat. Získáš tak ověření, že optimalizace nezměnila funkčnost. A zároveň - i když neakcelerovanou - podporu ostatních architektur. Nicméně v tvém případě to stejně problém nebyl, Windows, macOS a nově Linux (první bude Fedora) mají emulátor x86 předinstalovaný.
-
Tak samotná jádra nezaostávají, neb ta jsou od AMD64 ISA víceméně separovaná.
Jinak yep, jakmile jsem zjistil, že je tam ISA-specifický kód, hlasitě jsem nadával. Ale jaksi pozdě nadávat na vývojáře, co to před snad 20 lety psal a upřímně jsem do toho nechtěl hrabat, neb kvůli publikaci potřebuju plnou kompatibilitu s ofiko releasem. I proto pořád držím AMD64 stroj, neb možnost jet nativně starý a bůhvíjak psaný kód, se sakra hodí.
Jinak ze zmiňovaných překladových vrstev (níkoliv emulací) mám dobrou zkušenost jen s Rosettou 2 + Apple Silicon SoC. Překlad ve Windows na Qualcommem poháněných strojích mě poněkud neoslovil.
-
Intel je dead - sám bych si Intel nikdy nekoupil a vypadá to, že Intel na tom nechce nic změnit (můj poslední byl Skylake).
Otázka pro čtenáře, kdo si dnes kupuje Intel a proč? Ta architektura je zastaralá, a kdo chce X86 má možnost koupit si to nejlepší v tomto segmentu - AMD Zen 4/5. Intel dnes prodává vykastrované CPU kde člověk najde 2 různé mikroarchitektury (E/P) a díky tomu nemá ani AVX-512. A pro ty co AVX-512 z nějakého důvodu potřebujou to radši zablokoval přímo v CPU.
A přitom X86 nemá víc co nabídnout - Apple Silicon umí až 8 SIMD instrukcí za 1 cyklus (4 násobení), což umožňuje zpracovat 1024 bitů za cyklus, pokud to člověk umí - Intel už o tom může jen snít a jediná cesta je AVX-512, které aspoň trochu ulehčí dekodéru, ale tady zase kraluje AMD a Intel je někde ve zpětném zrcátku...
No, a kdo chce mobilitu a výkon k tomu má možnost koupit si MBP a dostane něco, co žádný X86 CPU nikdy nebude schopný nabídnout (Lunar Lake opravdu není konkurence).
-
Apple má pěkný HW, ale mně to přijde dost svazující. I pokud odhlédnu od SW, tak variant HW je dost málo a pokud chci víc paměti nebo disku, tak je to nechutně drahé. (už jsem navykl na 32G RAM, například)
A jiné (ne-Apple) non-x86 CPU kompetitivní řekněme s Ryzeny? Moc mi nepřijde. U větších serverů asi jo, nebo nějaké zase více embedded případy.
-
Legacy soft může být emulovaný a nový soft podporuje ARM nativně.
Pokud se bavíme o nějakém legacy softu pro 32-bit nebo 64-bit X86 (většinou kompilovaný pro baseline x86, takže SSE2) tak toto už je dávno vyřešený problém (Rosetta umí spustit Chrome a není to jediný soft, který umožňuje JIT rekompilaci x86 na AArch64).
Ono x86 se rekompiluje snadno, protože třeba AArch64 má víc registrů, takže o registry není nouze a jde to skoro 1:1. Jediný problém je strong memory ordering v případě x86, a ktomu je potřeba extra silicon na CPU a pár bitů navíc co se dají nastavit (Apple M1+ to mají, jiné ARMy netuším).
Co se snažím napsat je, že toto je dávno vyřešený problém a nikdy nebyl lepší čas pro změnu ISA - už to není takový problém jako dřív.
23. 12. 2024, 11:36 editováno autorem komentáře
-
IA64 mělo úplně jiné problémy, spojené s neefektivitou zápisu instrukcí do VLIW instrukce. Tehdejší kompilátory i emulátory si s tím nedokázaly dobře poradit, dnes by možná byly úspěšnější.
Ohledně ARM a emulace Rosetta 2 v Mac, případně později na Windows či Linuxu, doporučuju přečíst nějaké články a benchmarky - například Mac emulovaný software na ARM64 běžel rychleji než na nativním Intel x86.
V samotném porovnání laptop platforem je Mac ARM64 vepředu už čtyři roky. Jediná věc, kde aktuální ARM64 platformy zaostávají, je grafika (což není problem CPU, ale nezájem aktuální cílové skupiny). -
Máte pravdu, že u emulace legacy věcí na výkonu nesejde, takže to problém IA64 nebyl. Ten byl vskutku v tom, že se nedalo kompilovat tak, aby to nějak výrazně využilo nové možnosti.
Neuměli jsme to tenkrát a neuměli bychom to ani dnes. Možná by s tím pomohlo AI, ale u překladačů psaných lidmi to je problém. Ta VLIW vyžaduje úplně jiný přístup a to, na co jsme zvyklí, nepomáhá. Navíc je to jen jedna vrstva problému, kde ta druhá je v tom, že SW není psán tak, aby to dokázal využít. To jsme se sice i díky psaní programů pro GPU naučili, ale kdo by teď začal přepisovat stávající SW, aby to dělal? Byly snahy přepsat alespoň pár knihoven, ale v důsledku to pak nebyl univerzální kód a pro Itanium to byl separátní zdroják.
Šanci na úspěch by to mělo, ale bylo by potřeba do toho předem nalít obrovské peníze a úsilí tak, aby se zákazníkům dodal kompletní produkt včetně překladačů a knihoven. Tak, aby si zákazník koupil procesor, překompiloval vlastní program a ten běžel lépe. Intel stál na rozcestí a rozhodli se, že je moudřejší oplakat dosavadní investice a zaříznout to. Protože měli jasnou představu o tom, kolik by je to ještě stálo.
-
Však kompilátor tam byl a nativní aplikace existovaly. Problém byl, že VLIW přináší výhody i nevýhody a budoucnost ukázala, že nevýhody převážily. Např. pro novou generaci CPU nešlo udělat lepší logiku, protože pak by neuměl provádět kód zkompilovaný pro starou generaci. To je velká nevýhoda nechat vše na kompilátoru. Dále některé prvky rozhodování CPU ví až v momentě provádění kódu.
PS: Emulátor x86 pak vznikl i čistě softwarový a byl výrazně rychlejší než to embedované jádro 386.
28. 12. 2024, 00:51 editováno autorem komentáře
-
"Tak, aby si zákazník ... překompiloval vlastní program"
A presne takhle to nefunguje vubec nikdy. Oni by totiz predevsim vsichni museli ty sve programy cele prepsat. Coz sice neni uplne nerealne, ale pouze a vyhradne za situace, ze by nova arch prinesla radove (ne procenta ale stovky procent) jiny vykon. Coz se nikdy nestale.
I tak by to trvalo desitky let.
Dnes je pak neco takoveho uz davno mimo realitu, protoze je tu pomerne hodne firem a vyvojaru, kteri si i opakovane nabehli na tema ukonceni podpory po nekolika letech.
-
Tady je velký problém v tom, že Apple si udělal vlastní HW, na kterém ta rekompilace běží dobře. Ten bit co povoluje strong memory ordering dělá tu rekompilaci mnohem jednodušší. Windows x86->AArch64 recompiler nic takového nemá a v podstatě je navrhnutý pro jakýkoliv ARM - zápis/čtení je pak mnohem komplikovanější == extra instrukce, co mají právě ten strong memory ordering zachovat. což zabíjí výkon. Jediné místo, kde to není potřeba je stack...
Prostě není ARM jako ARM. Apple si to vychytal, aby ten přechod nebyl problém, Windows asi není ready, ale to je mi třeba celkem jedno.
Pro ARM je teď důležitý hlavně cloud segment, protože tam se točí velké peníze a každý větši cloud provider si dnes navrhuje vlastní efektivní CPU.
24. 12. 2024, 00:35 editováno autorem komentáře
-
Apple si nemůže vymýšlet svoje úpravy ISA, firma ARM to zakazuje, aby nebyl z architektury nekompatibilní bordel. Tedy všechny ty cool features, které Apple má, ve skutečnosti už někdo použil před ním a firma ARM je schválila.
Např. strong memory model vymyslela NVidie (jádra Denver) a je přítomen i v superpočítači Fugaku, protože v tehdejší době 99,9 % vývojářů znalo jen x86 a nechápalo by, proč jejich na x86 odladěný multithread kód blbne (museli by tam přidat dodatečnou synchronizaci dat). Podobně FPU výpočty v ARM, aby vracely i speciální výsledky jako + a - nekonečno.
Tyto "hardwarové akcelerace" emulace x86 má i Qualcomm Snapdragon X (Pro/Elite), který najdete v nových noteboocích Dell, HP, Lenovo apod. Emulátor x86 ve Windows 11 je využívá, takže procesor často překonává Intel i v běhu x86-only aplikací a her. Podobně jako po vydání Maců s Apple Silicon byly články typu "M1: Emulation faster than native".
Bohužel Windows detekuje typ procesoru a kód emulátoru využívající těchto funkcí CPU se vybere jen na Qualcommu. Na Apple Silicon, např. virtuálka, se využije obecný kód pro ARM Cortex. Tzn. až 8x pomalejší, kdy musí vkládat memory barriers pro emulaci strong memory modelu a po FPU výpočtech sekvence instrukcí pro kontrolu výsledku (nejsem si jist, zda problém s floating point na ARM se netýká jen NEON / SIMD výpočty). Uvidíme, až vyprší exkluzivní smlouva Microsoftu a Qualcommu, možná pak přibude i podpora pro Apple Silicon (i když na základní blbnutí ve Windows ve VM to stačí).
24. 12. 2024, 02:48 editováno autorem komentáře
-
Nemáš pravdu - Apple používá nedokumentované instrukce - třeba AMX - Apple matrix extensions je Apple specific a žádný ARM to nemá. Ten bit co povoluje strong memory ordering taky není nic co by ARM navrhnul nebo schválil.
Applu se to prostě toleruje.
Mrkni třeba sem:
Toto není v žádné AArch64 specifikaci, navrhnul si to Apple a je to jen v Apple Silicon (myslím že od M1).
To samé platí u memory ordering - ARM sice nijak nespecifikuje jestli to CPU musí mít weak/strong ordering, ale praktické je aby to bylo weak memory ordering, protože to je lepší pro výkon (pro strong memory ordering jsou atomické operace, které to "zařídí") - takže opět to co navrhnul Apple (bit, který umožní strong memory ordering) to je jejich design.
Otázka je, jestli by ARM kvůli tomu chtěl žalovat Apple... zatím se tak nestalo.
-
Tak on Apple má blízké vztahy s firmou ARM, tak se takhle asi dohodli. V macOS, jak píšeš, je to stejně přístupné až v userspace, a Linux na Apple Silicon je ještě větší minorita než na x86, tak to není problém. V dalších verzích procesoru je to stejně asi už jen emulované kvůli softwarové kompatibilitě se staršími aplikacemi. ARM ISA už umí matice nativně a AS je implementuje: SME (Scalable Matrix Extension).
-
A proto se podíl Apple na trhu zvyšuje, protože lidi chcou funkční noťas co vydrží 10 hodin na baterku a nemá 5kg.
Jen škoda, že není víc ARMů a firem, které by ten ARM dostali i na "PC" trh - toto je jediné co zatím drží x86 při životě - Apple to udělal rychle, ale ekosystém mimo Apple to z nějakého důvodu rychle neumí.
-
Máme tady na klasických PC Windows teď i Qualcomm Snapdragon X (Pro/Elite), příští rok má vyjít Mediatek (s GPU NVidia) a možná i procesor přímo od NVidie. Takže už za rok budeme možná moci vybírat desktop/notebook s procesorem od 6 výrobců, z toho jen dva x86. A jeden z nich pomalejší než všechno, možná kromě Mediateku, který asi půjde tvrdě na cenu.
24. 12. 2024, 02:55 editováno autorem komentáře
-
kopfikStříbrný podporovatel
trochu si z Vašich názorů odnáším že ARM = Apple... doufám že to jenom špatně čtu mezi řádky. Apple je jenom jedna z firem stavějící na ARM, a to ještě k tomu jenom recently. a taky je to jediná firma která dokáže nabídnou nějakou smysluplnou konkurenci. nevím o žádných jiných ARM alternativách, které by se jenom zdálky přiblížily X86.
zároveň jde o zařízení pro smetánku. na světě je většina lidí chudých, chudších nebo-maximálně podprůměrně majetných. pro takové lidi Apple nenabízí NAPROSTO ŽÁDNÝ PRODUKT. jediné co pro ně nabízí, v případě že strašně moc chtějí Apple (asi aby byli in), jsou výhledy na zadlužení, protože si na zařízení od Apple musí půjčit. -
Protože kompilace je kód, kde potřebujete zpracovat hodně skalárních instrukcí za cykl, což v případě moderních CPU se silným out-of-order a velkými cachi visí na dekodéru instrukcí. Je to vlastně pro CPU nevhodný/neoptimální výpočet. Tam má legacy x86 smůlu, proměnná délka CISC instrukcí (i když za dekodérem je RISC) zesložiťuje dekódování exponenciálně (velikost dekodéru na čipu). x86 si pomáhá větší turbo frekvencí, ale je to na úkor spotřeby a hluku. SIMD na kompilaci nevyužijete. Akorát částečně Hyperthreading, ale ten už má jen AMD, a ten je problém získat (malá nabídka u OEM a ve firmách je snazší si říct o MacBook než o AMD laptop - Intel je v korporacích zaháčkovaný a Mac není přímá konkurence, "Mac is not PC", a taky možná máte nějaké pracovní workflow týkající se macOS/iOS, i kdyby jen kouknout, jak vypadá/funguje web firmy v Safari).
24. 12. 2024, 03:14 editováno autorem komentáře
-
Vubec. Apple presvedcil sve ovce, ze jim staci osekane a omezene SBC, zabalene v laptop/NUC krabicce, a ze nic vic nikdy potrebovat nebudou.
Kdepak je nejaky slusny desktop - ktery ma na desce nejake PCIe porty? A ma jich tam tolik, co bezna workstation platforma od intelu/amd? (tj. 64L v souctu) ?
Kdepak je desktop, na ktery si nainstaluji OS dle libosti?
Apple nedela pocitace, ale herni konzole, na ktery se ani hrat neda, nebo spis varne konvice a kavovary. Pokazi se? vyhodit a kup si novej.
-
Ehm, Apple nabízí Mac Pro, kam si můžete dávat PCIe karty. Dále oficiálně podporuje instalaci dalších OS, dokonce opravil bug v BIOSu, který neměl vliv na macOS, jen na Linux. A co se týče hraní, Apple naportoval DirectX 12 do macOS, aby šly i nové hry jako Cyberpunk 2077, Elden Ring či Hogwarts Legacy. Apple se opět stává herní platformou, a tak příští rok vyjde dokonce nativní verze Cyberpunk 2077.
24. 12. 2024, 03:02 editováno autorem komentáře
-
No to je dalsi bastl, kde si musite rucne prirazovat tech 32 pcie linek ke slotum :D a imho na zadnou 3rd party GPU neexistuji ovladace pro apple silicon.
Jediny co tam bude fungovat budou nejspis BMD Decklink karty (nejak chodi s odrenyma usima pres TB, kvuli profikum s macbookama) a maji unifikovane drivery - ale realne jsem nevygooglil pozitivni vysledek.
Ten Mac Pro tower s M2 Ultra proste nikdo nema - cenovka ja dost mimo a pak jsou tam dalsi omezeni, ze lidi radsi zmeni co delaji, nez aby si porizovali neco, co fungovat nebude.
Celkove to je takovy produkt aby se nereklo, ze neni v tom segmentu nahrada za Intely - ale nahrada to realne neni. Existuje to jen s 1 modelem CPU, zatimco se chrli jine produkty s kazdou generaci a variaci apple siliconu.
-
Taky myslím. Ale výkonný ARM SoC pro notebook/desktop už není jen Apple Silicon, měl jsem tu testy nových notebooků s Qualcomm Snapdragon X. Protože je to klasické PC Windows*, tak tam jsou i standardní ovladače DirectX, Vulkan, OpenGL, OpenCL, žádný wrapper na Metal. Hry tam jedou kompatibilněji než na Macu, kde mi např. kreslí ztmavenou trávu v Beam.NG a Kingdom Come: Deliverance a na Qualcommu je to ok. Dokonce není Qualcomm GPU horší ani ve starých hrách než moderní Intel GPU, protože i ta už jen spoléhá na emulaci starých DirectX ve Windows (např. kreslení stromů ve Flatout 2 má stejnou chybu průhlednosti).
*) Díky výkonné emulaci x86 a plné podpoře grafických API nepozná běžný uživatel rozdíl. Tedy kromě toho, že to vydrží déle na baterii a bude tižší.
> blob pre obstarozny kernel.
To se týká Androidu, dokud je založený na Linuxu, který záměrně dlabe na stabilní ABI (vedle toho se interně vyvíjel ještě pro Fuchsii, která to měla řešit, ale půlku týmu už vyhodili).
24. 12. 2024, 03:25 editováno autorem komentáře
-
Ma zmysel porovnavat celu platformu. Co mi je platne, ze Apple to ma vyriesene, ked ma chce zavriet do zlatej klietky s pripajkovanou RAM aj SSD... 99% ARMoveho sveta nie je este ready a myslel som si pred 10 rokmi, ze sa to opravi. Uz necakam. Ta softwarova odladenost na Linux uz mohla byt, ale ked nie je teraz, tak to nebude zo dna na den. Vykon ani spotreba pre mna nie je holy grail, staci ze to funguje. Pouzitelny laptop si viem kupit s x86 za par stoviek a mam aj niekolko zaloh kde mi staci prehodit/skopirovat disk, to je pre mna dolezite.
24. 12. 2024, 06:36 editováno autorem komentáře
