Copyright © 1998-2026 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2026 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Článek vyšel před 2 hodinama a žádný komentář, NVidia už nikoho nezajímá. :-D
Každej nemá takové nutkání komentovat každý jeden článek, co se tu objeví jako ty.
to bude narazka na comment od ddr0 u minulyho clanku..
Touché! Potopeno! 😂
By mě docela zajímalo, v čem je problém. Že windoze jsou sračka ví každej, ale na x86 se s tím výrobci (včetně nVidie) už nejak poprali, ale evidentně ARM verze ještě tak doladěná není a jak nVidia tak Qualcomm s tím bojujou a zatím prohrávaj...
Tak mohli to vydat s Linuxem. Tam by jim do toho neházel MS klacky pod nohy...
To už udělali.
Problém bude v nvidii. Na rozdíl od jejích fandů si dovoluji připomenout, že jejich CPU stály vždy za hovno. Na ARM bych to úplně nesváděl, to jsou CPU primárně do mobilů a jablek a v desktopu je to dlouhodobě bída, úplně stejná, jako když to kdysi Intel zkoušel v mobilech.
Desktop jede na ARMu dobře, příkladem je RPi, kde desktop jede ok. Akorat HW je slabší. Tipnul bych si, že kernel Windowsů čekají nějaké x86 specifické chování a ARM se na to musí nějak složitě ohýbat aby se tak tvářil a je možné, že při tom ohýbání dost podstatně ztrácí výkon. Linux je multiplatformí už od začátku.
Mně RPi nepřipadne jako dobrý příklad. Jednak to není desktop, protože je to absolutně portově ořezané a rozumně nerozšiřitelné (haty jsou skvělý nápad, ale pro bastlíře, ne na normální použití) a každé rozumnější využití naráží na tyhle problémy. A jednak samotný výkon Pi a cena jsou IMHO úplně o ničem. 16GB Pi5 stojí přes 5k Kč (plus zdroj a chlazení), a přitom je to stále mašinka spíše na promítání videa nebo sběr dat, kterou musíš, na rozdíl od nezničitelné Pi2/3 chladit a udržovat v kondici.
Jedine co drží x86 pri živote je spätná kompatibilita. Ak by sa neriešili drivery a softvér, tak x86/x64 nemá šancu, a to aj napriek obrovskému toku prostriedkov smerujúcemu do x86/x64. Či už v desktope, mobile, cloude alebo embedded.
Koniec x86 je otázka kritického množstvo sw pre arm. Kritické množstvo sw je zase nutné aby firmy investovali do desktop arm cpu. Začarovaný kruh z ktorého sa dostáva svet pomaly (alebo rýchlo pod diktátom apple vo svete macos)
Pri tom istom výrobnom procese, elektrickom prikone a architektonickom úsilí bude arm cpu vždy výkonnejší.
A vidíš, já si myslím, že ARM nemá na Zeny od AMD vůbec šanci 😁
Ok. Mozno tak v metrike, "dnes si chcem kupit najlepsi PC na hry"
ARM má na ZEN jedině a to ještě možná ve výkonu ALU na stejném taktu, ve výkonu FPU / SIMD už ne a v taktech taky ne. Proto se do destopu ještě ARM nedostal. Ani multicore Ampere Altra nejsou vhodné pro HTP zátěž, kdežto AMD EPYC a ThreadRipper v ní excelují. A je je jedno zda pod Windows, Linux, nebo BSD. A k tomu AMD jde i Cloud, což je taky jediné nasazení procesorů Ampere Altra, kde mají smysl. ARM obecně mají výhodu jen tam, kde je možno je přímo uzpůsobit. AMD ZEN procesory to nepotřebují. Žádný konec x86-64 nevidím.
Kdyby ryby.....
"Ak by sa neriešili drivery a softvér.."
.. odpovedel jsi si sam, proc x86/64 tam kde je a ARM taky..
Nvidia Tegra byly notoricky známý bugama v PCI Expressu, to byla stálice. Nebyl nedávno odhalenej nějakej i v jednom z těch nových? Teď to nemůžu najít, ale někde jsem to viděl :)
GB10 má štěstí, že na tom většinu SoC dělá MediaTek.
Aha: https://x.com/never_released/status/2015490564167270428
>> Nvidia Tegra byly notoricky známý bugama v PCI Expressu, to byla stálice. Nebyl nedávno odhalenej nějakej i v jednom z těch nových? Teď to nemůžu najít, ale někde jsem to viděl :)
Vera (ARM based CPU ze sady Vera + Rubin) má problémy spolupracovat s GPU jiných výrobců než nVidia.
Údajně to ale není specifikum nVidia, ale samotného ARM. Je to něco podobného jako použítí Strong Mem, jen pro PCIe. A je na to workaround.
Problem moze byt v implementacii TSO (Total Store Ordering), zapina rezim pristupu do pamate ktory umoznuje lahsie emulovanie x86/x64. (ARM ma "weakly ordered" memory model, x86 ma strictly ordered).
Je to nieco ako HW akceleracia emulacie x86. Kvoli tomu, ze Apple a neskor aj Qualcomm si takto rozsirili (po svojom) ARM specifikaciu, moze byt emulacia taka rychla (15-30% pomalsi beh emulovaneho kodu namiesto 70%). Ak by ARM nemal TSO v hardvéri, emulator by musel po kazdom zapise do pamate vlozit instrukciu "DMB" (Data Memory Barrier). To nuti procesor cakat, kym sa potvrdia vsetky predchádzajuce operacie, čo drasticky znizuje vykon.
Takze Windows on ARM by bezal krasne na cistom ARMe s nativnymi appkami, ale x86 appky by sli vyrazne pomalsie.
TSO myslim, ze nie je standardizovane, asi je to aj dovod, preco na MACu pojdu vo virtualke s Windows (on ARM samozrejme) pomalsie x86 programy. Kazdy asi prinasa vlastny sposob ako na to a OS (konkretne cast ktora emuluje x86 ale aj kernel) s tym musi pocitat.
Si objevil Ameriku? Že je nativ rychlejší než emulace, to je ale překvapení.
Zial tu uz asi nastupuje jazykova bariera.
ARM žádné instrukce pro emulaci nemají. Rozdíl je v tom, zda umí little endian model jako x86-64. Ani procesory Apple žádnou jinou HW pomoc v emulaci nemají.
Ale maju - Apple Mx aj Snapdragon od X Elite vyssie maju HW podporu pre emulaciu (nielen) x86.
Vola sa to TSO (Total Store Ordering)
V pripade apple sa to vola `TSO Extension`, apple to spristupnil aj pre Linux vo VM/Dockeri, treba akurat upravu linux kernelu. Rosetta2 pre linux na beh x86 binariek to pouziva. Zapina sa to per process, jeden bit v registri ACTLR_EL1 (Auxiliary Control Register)
V pripade X Elite je to podobne, tiez asi per process, neviem aky register.
To je jen přepínač režimu přístupu do paměti, nic víc. Žádná speciální funkce, jen přepíná Weak Memory Ordering a Strong Memory Ordering. Přístup do RAM není ani tak věcí CPU jako spíš řadiče RAM.
Nie je to o radici RAM. Neviem ako poznate instrukcnu sadu x64 a ARM, ale v skratke je to to tom, ze x86 instrukcna sada pouziva prekonany Strong memory ordering - v kazdom case musi byt vsetko zapisane pre kazdu instrukciu precitatelne z RAM (aj z ineho threadu). Pri ARMe to nie je zarucene a CPU moze do RAM zapisat v akom chce poradi a nie je to zarucene kym sa nezavola instrukcia ktora urobi force vsetkeho do RAM. Je to podobne ako nutnost zarovnat pointre na ARM na adresy delitene 4, v sucasnosti to uz nie je vzdy nutne (v minulosti crash), len pomalsie.
x86 program spolieha na Strong memory ordering, bez toho by program spadol, ARM nespolieha, program musi povedat CPU kedy ho to zaujima. Aj preto mozu byt ARM efektivnejsie/vykonnejsie na W.
OK není to věc řadiče, ale Load/Store, není to početní / logická operace nebo bitová manipulace. Nemá přímý vliv na výpočetní výkon. Jen uzpůsobuje způsob čtení / zápisu dat z / do registrů.
A stejně tak to není nic co by přímo emulovalo jakoukoliv instrukci x86-64 na ARM. Co se týká odlišného přístupu, je to věc dlouhého vývoje obou platforem. ARM stejně jako další RISC je Load/Store platforma. x86-64 to řešil jinak pomocí komlexnějších instrukcí. Takže přímé srovnání není tak snadné.
Neemuluje ale pomáha emulacii x86.
Tu napr apple popisuje ako zapnúť TSO pre akceleráciu rosetty v Linuxe:
https://developer.apple.com/documentation/virtualization/accelerating-th...
Popísané aj tu: https://dougallj.wordpress.com/2022/11/09/why-is-rosetta-2-fast/
ARMv8+ nie je už čistý Risc, tie uz v podstate vymreli. Rýchlosť load/store ma vplyv na výpočtový výkon. X86 ma inštrukcie ako ADD v ram, tie musia byť predpísané na ARMV8 a pritom musí byť buď strong memory model (TSO) alebo musí byť vložená ďalšia ARM inštrukcia ktorá zabezpečí ze pred vykonaním ADD bude všetko zapísané. Ešte väčší průser je prístup do ram z viac emulovanych threadov be TSO.
Ale zrovna tak není ani čistý CISC, vše je μkódované. Ale takže z funkce procesoru jsou vlastně skoro stejné. Ty rozdíly jsou v instrukční sadě.
Áno, ale sú zásadne rozdiely v instrukcnej sade ktoré armu pomáhajú dosiahnuť vyšší výkon jednoduchšie.
- pevná dĺžka inštrukcie (4B) vs variabilná (1-15B) - arm dokaze paralelne dekodovat inštrukcie na mikrokod(dopredu je jasne kde začína inštrukcia), dôležité pri branch cold start. Inštrukcií Je cca 3-4x menej, aj kvôli tomu, že x86/64 má kopec balastu ktorý dnes nie je tak potrebný. Armv8 je z r. 2012, kedy už boli znalosti kompilátorov a pokročilého navrhnú cpu na inej úrovni. X64 síce vyhodil niektoré malo používané inštrukcie ale nie moc a celková koncepcia sa nezmenila
- weak vs strong synchronizácia prístupu do pamäte - Arm nemusí každý zápis do pamäte synchrónne zapisovať, pre čítanie z iných inštrukcií alebo corov. Kedy je to nutné - určuje kompilátor, zjednodušuje sa návrh cpu.
- arm ma viac general purpose registrov - ak sa algoritmus "nezmesti" do daného počtu registrov, začína drahý presun z/do pamäte, komplikuje to out of order execution
Ten mýtus s dekodérem se nikdy nevyplnil. Jak AMD tak Intelu se i přesto daří zvedat IPC, i díky tomu, že instrukce x86 je v dekodéru dělena na víc μinstrukcí. a synchronní přenos dat je u x86 tak dlouho, že s ním prostě umí pracovat... Ale ARM zůstává u 128 bit NEON SIMD, kdežto AMD má dvě (odlišné) 512 bit AVX jednotky. Takže jedinou instrukcí zpracuje 4x tolik dat. CISC a RISC koexistují natolik dlouho, že se vzájemně ovlivňují. Jediný AMD s výkonnými 2x SVE 512 bit je stavěný na velký datový tok 48 jader, ale s nízkým taktem a malými cache, jako hybrid CPU a akcelerátoru.
Intel a AMD zdvihaju výkon vďaka veľkej mikrokodovej cache, ale vyzerá, že narážajú na limity, ST výkon v niektorých aplikáciách stále nedohnal 2 ročný apple m4. Ryzen 9xxx oproti 7xxx priniesol len veľmi málo výkonu, väčšinou v hrách vďaka inému umiestneniu 3d cache ktore umožňuje lepšie chladenie a väčšie takty cpu. Arrow lake oproti dvom minulým generáciám tiez moc nepriniesol (pre content creation je BTW super, pri arme mám aj arrow lake)
Pozor, ARMv9, čo je už väčšina dnešných cpu podporuje SVE / SME ktoré môžu ísť až do 2048b podľa implementácie. Nevyznám sa, ale zachytil som niečo, že je to vymyslene sikovne, jeden kod sa vykonáva dlhšie pomocou 128b registrov alebo rýchlo pomocou viac bitov. Netreba rekompilovat ako z avx na avx512. Je to „Spracuj toľko dát, koľko sa ti zmestí do jedného vektora.“, niektoré cpu majú 128b, niektoré 512b registre. Pri x86 je pre podporu 512b registrov nutné rekompilovat kod, Mar dve vetvy pre avx2 avx512.
BTW moja skúsenosť keď som robil niečo s bufframi, zrovna sieťové veci, tam ma nenapadlo také veci používať, Ai mi navrhlo robit to pomocou stream inštrukcií, mega zrýchlenie oproti bežnému kódu, na arm aj x86. Akonáhle sa dá robiť pomocou avx, sse, neon, sve, sme je to veľké zrýchlenie
Pořád nejsi schopný rozlišit výkon ALU a FPU/SIMD části. V ALU má Apple nějaký náskok, zbytek ARM ale ne. A výkon v plovoucí řád. čárce a vektorech? SVE sice umožňujse jediné instrukci pracovat s 2kbit vektorem, ale fyzicky na jaké jednotce? Udělat tak širokou vektorovu jednotku je téměř nemožné. Sama by zabrala víc tranzistorů než 3 celá dnešní jádra - bez L2 a vyšší cache.
Na FPU/SIMD máš v Apple GPU a API Metal, které konkuruje schopnostmi a softwarovou podporou CUDA. Ale jestli to máš rád na CPU části *toho stejného procesoru*, tak si kup klidně Threadripper.
Zas mimoň se ozval. Tady snad píšu o tom, co umí HW. SW vrstva ti jen usnadňuje programování, ale přímo s CPU fyzicky nemá nic.
Však mluvím o HW. Např. DeepSeek má půlku kódu pro NVidia GPU v assembleru (HW) a jen půlku v CUDA (SW). Stejně tak dnes většina programátorů nepíše v assembleru/C/C++, ale ve vyšších jazycích (SW).
Assembler je přece taky programovací jazyk, níž už je jen kód v symbliicých adresách, či jak. Je to tedy poskládané ze dvou prog. jazyků. Kde je fyzický HW? Pokud si pamapuji pořadí tak: assembler, nad tím C a ještě výš byly Fortran, Pascal atd. A u nich právě ty dvě úrovně programování uplatňovaly. Hlavní kód v tom vyšším a rychlé rutiny assembler, takže se naprosto nic nemění.
Ve strojovém kódu neprogramuje už nikdo.
Ale ten poměr nizko / vysoko úrovňový programocvací jazyk. S tím že C je někde mezi.
O kolik je ten rozdíl? O 10, 20 %?
Netuším, asi je to i věc varianty C
V C se programuje GPU už dekády.
To přece nevyvracím, už zas odpovídáš na něco úplně jiné. Já píšu o počtu variant C. A hlavně na začátku platilo, že C je větší bordel než Pascal, ale má víc možností.
Tak Pascal víceméně umřel. Proč by mu měl růst počet variant? Protipříkladem je třeba Python a všemožné optimalizované varianty.
Poslední o čem jsem psal bylo C. Drž se tématu.
Každý si může odskrolovat, co jsi psal.
A ptal jsem se ma počet variant C, který jsi stále neuvedl.
Se zeptej Googlu nebo AI. Mě zajímají jen některé varianty C.
Je to hodně těžké pro tvé EGO napsat nevím. Ale mohl ses sám podívat a dělat chytrého. Raději se budeš dohadovat.
Narozdíl od tvého EGA vím aspoň některé varianty ;-)
Smích.
Pláč.
Jo, jenže IPC už zvedají jen pro některé situace. Kdežto široký dekodér instrukcí zvedá IPC všude (viz např. tzv. trhanost Windows 11). Navíc vychytávky AMD nejsou v consumer Intelu (HT, AVX-512). A ARM ISA samozřejmě umí víc jak 128bit NEON. Je jen na výrobcích a zákaznících, kdy to budou chtít v procesorech.
Když srovnáš ZEN 4 a ZEN 5, ostatně všechny generace, pokaždé došlo k nárůstu IPC. Ale fakt je, že zvyšovat prostý počet instrukcí za takt, je daleko složitějším, než přidávat výkonnější instrukce. A historie ukázala, že každá déletrvající platforma musela pracovat na obojím. A vektorové instrukce jsou starší než jednočopové procesory. Už tehdy věděli, že zpracovat víc dat jedinou instrukcí je správná cesta.
Kdyby nevyrostlo IPC, tak není důvod vydávat novou generaci CPU (když nepočítám v historii die shrinky). Je hezké, jak AMD zvládá zvyšovat IPC, nicméně i tak se vzdalují od Apple Silicon a Qualcomm Snapdragon X2.
Tady je pořád představa, že jde o konkurenty, ale ne. Jsou to jiné segmenty trhu.
80 % počítačů jsou laptopy. Takže se překrývají "jen" v 80 % trhu.
Ale pořád je rozdíl Windows a Apple. Ostatně nepamatuju si, že bych v této diskusi zmínil desktop.
Proto jsem zmínil i Qualcomm , který je PC/Windows.
Pořád je ARM + Windows proti x86 + Windows velice malý.
To je stejné jako podíl elektroaut, přestože spousta jich je o dost lepších než spalováky. Nějakou dobu trvá, než naroste podíl. Počítače se Snapdragon X2 teprve vyjdou.
Reálný vývoj ale spěje spíš k hybridům.
Ty jsou jen mezikrok. Dvojnásobná složitost.
Vývoj akumulátorů nestačí a stále se spalovákem ujedeš na jeden zátah víc. U AKU ti brutálně roste hmotnost a stejně pokud nechceš rychlonabíjení, tak jsou fakt dlouhé zastávky. Extender ti umožní menší kapacitu a hmotnost AKU tak akorát do velkého města i dlouhý dojezd a rychlé tankování.
Tohle bylo už vysvětleno na automobilových webech a skupinách. Jak od odborníků, tak reálných uživatelů, vlastníků. Nemám potřebu "zasírat" Diit.
Každý tábor má své odborníky. Takže to není argument.
Ok, ale řešili jsme to několikrát i na Diitu.
"Jo, jenže IPC už zvedají jen pro některé situace."
To přece není pravda, a hledat nějakou spojitost s "trhaností Windows 11" mi přijde úplně mimo.
Co se týká SVE-2, tak bohužel nikdo zdá se nemá zájem na víc jak 128 bitů jít, takže veškerá komplexita způsobená tou snahou o flexibilitu šířky SIMD je zatím jenom na obtíž. IMHO tenhle koncept SVE/RVV může být slepá ulička, která bude zase víceméně opuštěná pro univerzální CPU (v nějakých DSP by to možná fungovalo líp).
Jinak ten memory model se opravdu považuje za vlastnost architektury/instrukční sady, v tom má Mixal pravdu. Vedle toho mají ARM procesory Qualcommu a Applu i jiné funkce na zlepšení výkonu emulace, například (IIRC) v zacházení s flagy při FPU operacích, kdy normální emulace by byla kvůli odlišnostem v instrukční sadě ARM velmi náročná, ale pokud má procesor podporu pro emulaci chování x86 flagů, tak se to dá na ARMu emulovat mnohem efektivněji (s menší ztrátou výkonu).
Je to tím, že s šířkou vektoru nestoupá počet tranzistorů lineárně. Pokud vím ARM zkoušel 2x 256 i 4x 128 bit. A je asi jasné, co vyhrálo.
Hlavní je, kdy to budou lidi potřebovat. U x86 to význam má, protože dekódováním široké instrukce za jeden cykl protáhnete více práce skrz úzký dekodér.
Puf a Muf> Svižnost bloatware jménem Windows 11 si přece každý může snadno ověřit. Flagy pro emulaci byly i na Diitu dobře rozebrány. Ano, nejsou to instrukce, ale přepínače chování. Vtipné je, že nestojí tranzistory, protože strong memory model se emuluje *vypnutím* jedné optimalizace práce s RAM. A speciální výsledky FPU jednotky umí pro skalární operace, takže se na ně zvládne přepnout v NEON SIMD instrukcích. Jenže spousta výrobců procesorů neumí dělat jádra. Umí poslepovat licencovaná a tím to končí. Pro hardwarově akcelerovanou emulaci x86 by museli šáhnout do vnitřní logiky jader.
Celkem mne zajímaly Ampere One. Ty už mají vlastní jádra... Kdyby zůstali u licenčních, mozná by to bylo lepší. Mesh propojovací logika, člověk si řekne hezké. Ale v každém uzlu je čtveřice jader, takže některé SW zátěže škálují jen do poloviny jader a víc to nedá. Zjdenodušili si v SIMD / FPU. Umí sice FMAC, jenže celá pointa té instrukce je, že provedeš dva výpočty a až na závěr zaokrouhlení a normalizaci. Tady ne dva výpočty a po každém zaokrouhlení a normalizace, protože to jádro fyzicky FMAC neumí, je to lepené.
"Puf a Muf> Svižnost bloatware jménem Windows 11 si přece každý může snadno ověřit."
Sorry, ale co je tohle za výrok. Windows 11 fungují ok, jsou podobně náročné jako jiné state-of-the-art OS dneška s podobným DE. Dojmologii fanoušků a haterů nechme bokem.
Prostě nechápu, jak můžete vzít takový extrémně vágní a nejspíš imaginární koncept a považovat to za "jasný znak" něčeho týkajícího se procesoru...
Jestli tobě stačí ok level, tak ok. A Windows 11 používá většina lidí, takže dojmy lze hodnotit i statisticky - máš velký vzorek.
Navíc, kdo chce může se potrápit s linuxem...
No to je právě ono - když prý x86 způsobuje že se W11 prý chová kartastrofálně, tak jaktože se to neprojeví v Linuxu na serverech, aha?
Vono se to neprojeví ani ve Windows 10, vašnosti.
W11 na ARMe sa mi pocitovo zdraju zviznejsie ako na porovnatelnom x86 HW. A nielen mne, viacero ludi na reddite to pise, podobne okolo VS2026.
Samy o sobě možná. S nějakou větší SW zátěží už to tak nebude.
Nebo naopak. Něco jako tehdy výkon tesselace na NVidii a AMD GPU.
Mi se tu bavíme o CPU nebo GPU? Tato diskuse ode mne spěje ke konci, už zase si píšeš, co chceš.
Já ti snad bráním psát, co chceš? Co třeba ten Pascal?
Dobre video,ktore ukazuje aj moju skúsenost s armom.
https://youtu.be/uX2txbQp1Fc?si=9MG5fx4EpoINwv4c
Odporúčam hlavne od cca 8 minúty. Ako pusti VS. Rozdiel vo sviznosti arm pc a x86 pc je väčší ako ukazujú benchmarky. Je to podobné aj na snapdragone.
"Mac running windows as a VM beat the Windows laptop💀💀"
Ja bych doporucoval se zamerit na uvod, kde borec rika, ze ten Razer ma "24C" procesor :D o par vet dale jeste dodal, ze je to 14th generace..
pak jsem to video rovnou vypnul, protoze borec, ktery uvadi RaptorL notebook jako "24C"...sorry :)
Intel Core i9-14900HX je 24C CPU
sorry, ale pak jsi na stejnem levelu a v principu nema smysl se ani snazit komentovat co pises..
14900HX ma sice celkove 24 jader, ale POUZE 8 z nich za neco stoji, protoze to jsou P jadra architektury Raptor Lake. tech zbylych 16 Emrdek, ktere tam jsou jsou dobre tak pro ulohy typu Cinebench, mozna konverzi videa. Pokud delam technicke video, kde jeste srovnavam platformy, tak musim jit trochu do technickych detailu, v opacnem pripade muzes klidne srovnavat i skodat 120L s Kodiakem, protoze obe jsou preci auta..
Porovnanie vobec nie je od veci.
Je to rok +- stare video o tom, aky highend sa dal kupit z Windows a Mac sveta a ako zvladaju beznu robotu sw development.
Kolko ma kto jadier je v podstate jedno, dolezite su vysledky. Keby o to slo Apple M4 MAX ma tiez len 10 alebo 12 tucnych jadier a ostatne su E jadra.
Tragedia je, ze pre cloveka ako ja ktory ma rad a potrebuje Windows su dostupne PC sracky oproti Macbookom. Ak niekto hovori opak tak je to akurat denial faza. Rozdiel medzi tymito dvoma strojmi je ako keby 8r.
Najlacnejsi Apple M4 - rychlost kompilacie medzi Ryzen 9700x/9800x3d az 9950x. Cely najlacnejsi mac mini s tym CPU stoji skoro tolko co ten Ryzen.
V kompilacii - M4 MAX @55W v notebooku zadupe vodou chladeny pretaktovany Ryzen 9950x @200W do zeme. Pokial v tomto niekto nevidi tragediu tak uz potom neviem.
"Kolko ma kto jadier je v podstate jedno, dolezite su vysledky. Keby o to slo Apple M4 MAX ma tiez len 10 alebo 12 tucnych jadier a ostatne su E jadra."
.. tak pokud budes prispivat do casopisu "Zena a Zivot" tak ano. Pokud hazej "youtubera", ktery nevi, co delaji napajeci profily, nezna jak funguje architektura, nezna jak funguje benchmark..tak sorry, ale to tady nema co delat.
"Kolko ma kto jadier je v podstate jedno, dolezite su vysledky. Keby o to slo Apple M4 MAX ma tiez len 10 alebo 12 tucnych jadier a ostatne su E jadra."
.. to samzorejme jedno neni, protoze kdyz rikas, ze srovnavas 24 jader ve videu, z cehoz 2/3 jader tam jsou do poctu, s necim, tak to neni pravda. Ale nejpsis to bude tvuj level, takze tobe to staci, ale na technickem magazinu by to stacit nemelo.
"Tragedia je, ze pre cloveka ako ja ktory ma rad a potrebuje Windows su dostupne PC sracky oproti Macbookom. Ak niekto hovori opak tak je to akurat denial faza. Rozdiel medzi tymito dvoma strojmi je ako keby 8r."
.. ja bych rekl, ze "denial" faza se vyskytuje hlavne u tebe, ktery ma neustale nutkavou potrebu neustale spamovat jak to nebo ono je lepsi, ajk jednou je nejlepsi ST, a jak ARM vsechno zadupe do zeme.
Si tam troubeline spust treba 10 aktualnich her mezi tim Razerem a tim srackoidnim Macbookem.. a uvidis, kde ten Macbook zustane.
S tim zbytkem radeji spamuj na nejakem jablickovem webu, tam to urcite dava smysl a budes mit na to pozitivni ohlasy. Budes tam mezi svyma.
Ale on nemůže za to, že nabídka Intelu je "podvod". A integrovaná grafika v macbookách zamává půlkou PC laptopů.
tak za to samzorejme nemuze. Ale kdyz linkujes video tady, tak bud by jsi mel to video trochu "uvest", aby jsi "zmirnil" neprofesionlaitu daneho YT a nebo jej radeji neuvadet :)
Neprofesionalitu? Alex Ziskind robi jedny z najlepsich testov HW pre SW developerov.
Fakt? Ja treba vyuzivam vyvojovy SW, ktery urcite Ziskond netestuje a ty ho ani neznas.
Nicmene tocime se v kruhu. Za men je to video technicky silne neprofesionalni. Pokud tobe staci level nebo informace, ktere sdeluje, ok. Ale tady s tim neuspejes.
Ten vývojový SW je určitě tajný. A pravděpodobně starý, takže by ho utáhla rychle i softwarová emulace. Nevím, podle čeho je tebe video silne neprofesionalni, ale testuje konkrétní workflows.
pro tebe Ladiku, je vsechno tajne :D
"Si tam troubeline spust treba 10 aktualnich her mezi tim Razerem a tim srackoidnim Macbookem.. a uvidis, kde ten Macbook zustane."
A to je to. Intelu ostavaju Windows hry.
Dokud nezačne throttlovat. Zatímco MacBook zvládne AAA Windows-only x86 hry i pasivně (zkoušel jsem Borderlands 3 na MB Air M1). A to emuluje CPU, GPU a OS.
Ve tvem chapani a rozsahu reality asi ano. Ale opravdu jen ve tvem.
Tvoje chápání tu snad někdo sdílí?
TY rozhodne ne Ladiku :D
Možná ani ty ne, Tombíku :D
To se smí říkat, že u Intelu máme počítat jen velká jádra? Já za to na Diitu dycky dostal čočku 🤡
Nnnnoooooo.... to je odvážný výrok.
Větší šířka vektoru by měla být méně komplexní architektura, než když uděláte větší množství užších SIMD jednotek se stejnou celkovou šířkou. A to proto, že musíte mít instrstrukturu pro současné řízení, schedulování krmení a obsluhování vyššího množství jednotek. Jestli něco přináší nelineární nárůst komplexity, tak je to tohle. Zatímco když 2x rozšíříte SIMD jednotku/registry, tak počet tranzistorů a potřeba datových cest půjdou nahoru spíš lineárně. Ale zkuste říct, že bude v FPU osm 128bitových SIMD jednotek místo čtyři 256bitových. Najednou musíte mít dvakrát víc portů do register file (a tyhle porty jsou problém!), musíte mít fronty udělané na zpracování 2x operací za cyklus
Jako možná to zvládnete udělat tak, že nenaroste nelineárně počet tranzistorů, ale poroste vám nelineárně spotřeba, takže tohle ukočírovat je hodně těžké. Výhoda tohohle přístupu s užším SIMD a více jednotkami je někde jinde než v hardwaru - je v tom, že tohle má potenciál urychlit i starší software postavený na NEON/SSEx, kdežto přechod na 256bitové jednotky vyžaduje napsat kód v AVX2.
Nebavím se o okolí, jasně scheduller je složitější, ale neplatí, že 2x širší jednotka má 2x víc tranzistorů, ale spíš 3x až 4x. To je důvod, proč prvním Core s AVX512 tak padal takt.
Tranzistorů můžeš mít, kolik chceš, viz Apple Silicon s velkou plochou čipu.
Aha tady se ozval těžce zamilován do Apple ARM teoretik.
Praktik. Narozdíl od tebe jsem ho měl v ruce. A vyvrátil jsem tím tvoje:
"víc tranzistorů, ale spíš 3x až 4x. To je důvod, proč prvním Core s AVX512 tak padal takt."
To že něco bez dalšího zdroje napíšeš, nevyvrací vůbec nic.
To platí i o tobě. Dal jsem konkrétní protipříklad.
A kde je důkaz? Tvé písmo není svatá pravda.
Tak si přečti údaje o procesoru třeba na Wikipedii, když mi nevěříš.
Já to tady mám zdůvodněno v textu. Ty jsi neuvedl nic kecale.
"Tvé písmo není svatá pravda." in your face.
Důvody proč s šířkou roste složitost SIMD není těžké najít. Ty jsi neuvedl žádný argument. Ale můžu to napsat. Samotné výpočetní jednotky - sčítačky, násobičky - tam to jde lineárně. U registrů už ne kvůli složitosti propojení portů. Shuffle Unit - závislost je už kvadratická. Bypass Logic - zde je to podobné jako u registrů. Roztrhej to.
Uvedl jsem protiargument na tvou uvedenou *konkrétní implementaci*:
"To je důvod, proč prvním Core s AVX512 tak padal takt."
Mimochodem pozdější Intely ten problém postupně vyřešily.
Takt u nich taky padal, ale méně a řešili to správou napájení. Každopádně plocha na čipu při stejné výrobě s šířkou SIMD roste víc než lineárně. A to je fakt. Je možné i to, že Intel samotnou implementaci trochu zjednodušil.
Právěže u těch registrů propojení s jednotkami (porty) jsou ten aspekt, který favorizuje rozšiřování vektoru a mluví proti multiplikování jednotek o nižší šířce. Pokud máš jako základ procesor s 4x128bit jednotkami (který měl jenom 128bitové registry, tj. současné SVE, NEON, SSEx), tak při přidání dalších SIMD jednotek třeba na 6x nebo 8x této šířky musíš zvýšit počet portů do registrů i "rozšířit" schedulery a forwarding network aby zvládaly víc operací za cyklus. Přidávání portů do register file je problém, protože pak ti to víc žere, je mnohem větší problém stihnout časování a tak, není to zdaleka jenom o tom, že to stojí tranzistory.
Nebo to můžeš udělat bez toho a nějak to ošidit, ale 6x nebo 8x SIMD jednotek nebude škálovat a budou tam zčásti zbytečně, protože se málokdy využijou.
Pokud zůstaneš u 4x jednotek, ale rozšíříš registry a jednotky na 256bitů, tak naopak budeš mít lineární nárůst tranzistorů v registrech (pokud zachováme počet - teoreticky se dá udělat kompromis a místo 256 registrů mít jenom 192, například, takže nárůst tranzistorů bude pod 2x). Musíš rozšířit datové cesty sa mozřejmě přidat per-lane ALU v SIMD jednotkách - jenže ty jsou paralelní a nezávislé, takže to není architektonicky těžké.
Ale hloubka front a scheduleru se nemusí zvyšovat, nemusí se zvyšovat počet instrukcí zpracovávaných za tak, nemusí se přidávat porty.
Jediná výjimka, jak je zmíněno, jsou shuffle jednotky. Nicméně ne všechny instrukce permutují úplně napříč celým vektorem, často je to omezené na určté jho sekce pro usnadnění. A kromě toho, právě tyhle shuffle operace přes široký vektor taky bývají v programování hodně užitečné, proto taky třeba Zen 4 do tohohle investoval a má fakt 512bitové shuffle operace, přestože většina instrukcí se dělí na 256bitové operace.
BTW to, proč u 14nm Intelů hodně padal výkon/nebyl dobrý výkon při použití AVX-512 (ale to nebyl hlavní problém, horší bylo, že aktivace 512bitových operací uváděla procesor do přechodového stavu, který trval hrozně dlouho a o hodně snižoval výkon), nebyl počet tranzistorů, ale nároky na proud, který je pro provedení 512bitové operace třeba vyšší. A Intel neměl vybudovanou infrastrukturu, aby to dobře zvládl a proceosr používal strašné hacky na to, aby se vyhnul nestabilitě kvůli voltage dropu.
Výsledek byl, že mixování 256bitových a 512bitových isntrukcí (což většinou kód dělá) neustále spouštělo ty hacky řešící přechody mezi 256bit a 512bitovým vykonáváním.
To snížení taktů třeba ještě nemuselo být tak fatální, protože to často 2x výpočetní výkon mohl dohnat, ale tohle byl prostě velký problém. Zlepšilo se to u 10nm procesorů.
Konečně odpověď od někoho, kdo o tom něco ví. Ale pak mne zajímá, proč tolik ARM zůstává u 128 bit?
Protože ARM i po rozšíření infrastruktury je furt menší a levnější na výrobu než x86 a většina aplikací nevyužije širší vektory a/nebo matice*. ARM jde cestou zvyšování obecného výkonu, který se projeví všude. Cesta AMD je taky dobrá, protože reálně aplikace, která ten výkon skutečně využije, nemá problém přidat codepath pro speciální instrukce* či akcelerátor**. Problém je pouze Intel.
*) Matice má i Apple Silicon. Papírově je to koprocesor, aby nemuseli porušit licenci na ARM ISA, ale reálně jde o "skryté" instrukce CPU jader (přístupné přes knihovnu v OS).
**) Apple Silicon a Qualcomm Snapdragon jsou dodávány s výkonnou GPU, NPU a videokodeky.
SW nástroje tradičně k CPU dodával i Intel a ovladače atd, jsou snad samozřejmost všude. Ale je taky vidět, že ARM dobře ví, kde mají silné a slabé stránky a do WS a HPC se neženou.
Tak třeba dnes letí workstationy pro AI, a tam je Apple dvojka po NVidii (a pro stejnou kapacitu VRAM stojí zlomek - za cenu o trochu pomalejší).
Zrovna AI jsem nemyslel. Třeba stroje pro konstrukční práce.
Těm dnes stačí historický HW ve srovnání s tím, co lidí kupují za WS dnes.
Dost jednoduchý pohled. Možnost číslo 2 je, že na WS je možné zpracovat složitější a obsáhlejší projekt než dřív.
To jistě. Děláme software pro statiky (stabilita budov, mostů, ...), a na to už dýl stačí vyšší model notebooku.
Neřekl bych, že statika budov je to nejnáročnější. Možná u hodně velkých a složitých.
Není to to nejnáročnější. Ale tak polovina věcí, co člověk dělá. Prostě co bylo workstation PC za 200 tisíc před 6 lety je dnes notebook za 50 tisíc.
O tom se nepřu, viděl jsem konfigurátor WS s dual EPYC a možností osadit 4 GPU. Jestli dobře počítám, maximum bylo 6 TB RAM. To je Hi End WS.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.