Vlákno názorů k článku Intel končí s plány na x86S, navrací se ke standardní x86, Qualcomm vyhrál dílčí bitvu o ARM od MeeGo - no future - Toho zrušené x86S je škoda, svět IT mohl...
-
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.
