Ako to vidíte z budúcnosťou processorových architektúr?

[fortran1986]

CISC tu bude IMHO ešte hodne dlho, minimálne tam kde sa vyžaduje výkon - na desktopoch, herných počítačoch, konzolách, práci s multimédiámi a pracovných staniciach. Síce Intel zaspal na vavrínoch, ale naštastie AMDčko ťahá architektúru ďalej. Škodaže na trhu X86/AMD64 neni toľko hráčov ako v 80tych a 90tych rokoch (popri Inteli a AMD aj Cyrix a NexGen a IBM a NEC) tam kde chýba konkurencia, je bohužiaľ menšia dynamika vývoja.

ARM - RISC Architektúra veľmi šetrná ka životnému prostrediu. Pôvodne vznikla ako CPU pre domáce počítače. v 90tych rokoch ARMy dominovali PDA (StrongARM v Psion Series 5), PocketPC a Handledom, ale najvačšiu slávu získali po roku 2007 vďaka dotykovým mobilným zariadeniam, veľkú reklamu jej urobili Apple svojim iPhonom a Samsung či NVIDIA. Má omnoho lepší pomer cena výkon spotreba. Veľkí hráči ako NVIDIA, Microsoft, Apple, Samsung, Google čím ďalej tým viac presadzujú ARM. Momentálne ARMy vládnu, nie len mobilom, tabletom, set top boxom, IoT zariadeniam (Raspbarry PI, NVidia Jetson, Rock Pi) ale presadzujú sa aj v Laptopoch a čím ďalej tým viac majú potenciál dostať sa aj trh aj plnohodnotných výkonných desktopov a herných konzol. Okrem iOS a Androidu je už na ARMe doma aj Desktopový Linux, Windows 10/11, MacOS. mimochodom ako to dopadlo s kúpou ARMu NVIDI-ou?

RISC V - otvorená RISC architektúra, vraj má byť ešte šetrnejšia a ekonomickejšia ako ARM. Žiaľ zatiaľ je ešte len v plienkach a je veľmi málo rozšírená. Na trhu je zatiaľ len pár developer boardov (SiFive HiFive Unmatched, BeagleV) a dosť veľa microcontrollerov - pre IoT (ESP32-C3, ESP32-C6, Sipeed Maixduino AI, Huawei Hi3861, LoFive RISC-V). Intel po tom ako stráca pozície na trhu X86/AMD64 hľadá nové trhy a dokonca kúpil startup vyvýjajúci RISC V. Huawei vďaka Americkým sankciám (paradoxne aj napriek tomu že ARM je Britská firma) tiež poškuľuje po RISC V a možno sa okrem microcontrollerov raz dočkáme aj telefónu od s RISC V a Harmony OS. Otázka je či má zmysel venovať čas a energiu tejto architektúre, lebo vôbec neni jasné či sa presadí. Žiaľ trh zložený s ľudí a človek nie je "homo economicus" ktorý by si vyberal vždy objektívne najvýhodnejšie riešenie, takže nad rozšírením tejto architektúry zatiaľ visí veľký otáznik. No ekonomický intervencionizmus, sankcie a rôzne obchodné vojny by jej paradoxne mohli pomôcť.

[Reklama]

[RDa]

Tohle je hodne naivni pohled na situaci a platilo to mozna pred 20 rokama.
Dnes se deli trh, produkty a featury zcela jinak.

[PanVP]

IMHO není žádné běžné náročnější využití než moderní hry.

Jsme v bodu zlomu, kdy nebude náročnější využití než hry a AI.

[anonacct]

Viděl bych to na boj mezi X86_64+AVX512 a AArch64+SVE2 v HPC/compute segmentu. Časem AArch64 možná nahradí X86 všude možně - je to dobrá architektura, mnohem lepší než X86, nenáročná na decode a teoreticky mnohem výkonnější než X86. To co Apple předvedl s M1 je jen začátek nové éry.

Nevím ale jak daleko to je a kdy uvidíme propad prodeje X86_64, teď si nedokážu představit nic jiného na workstation / na práci.

[kanoe22]

Viděl bych to na boj mezi X86_64+AVX512 a AArch64+SVE2 v HPC/compute segmentu. Časem AArch64 možná nahradí X86 všude možně - je to dobrá architektura, mnohem lepší než X86, nenáročná na decode a teoreticky mnohem výkonnější než X86. To co Apple předvedl s M1 je jen začátek nové éry.

Nevím ale jak daleko to je a kdy uvidíme propad prodeje X86_64, teď si nedokážu představit nic jiného na workstation / na práci.

AVX512 sa hodne precenuje. Dodnes to nepouziva snad ziadny bezny program okrem nejakych programov na vedecke vypocty. Problem je ze procesory pri tom zeru ako svina, nie kazdy procesor to ma a aj tie co to maju to nemaju poriadne standardizovane.

Problem x86 je spatna kompatibilita desiatky rokov naspat. Ked sucastny arm bude rovnako stary ako je dnes x86/x64 architektura, bude na tom rovnako. Rozna nutena spatna kompatibilita ho bude brzdit.

Kazda architektura na zaciatku vyzera akoby niekto objavil ameriku. Skvelym prikladom su rozne technologie okolo baterii. Ako som od maleho decka zacal sledovat techniku (asi od 10tich rokov), dnes (o 20 rokov neskor) mame stale tie iste technologie baterii, ktore su sice vylepsene oproti tim z roku 2000, ale ziadne terno to nie je. To iste cakam aj pri procesoroch, ked sa nejaka architektura viac rozsiri, zacne sa tam dorabat kompatibilita pre toto a tamto a pojde to na rovnaku uroven ako ostatne achitektury.

[Reklama]

[Jiří Havel]

Viděl bych to na boj mezi X86_64+AVX512 a AArch64+SVE2 v HPC/compute segmentu. Časem AArch64 možná nahradí X86 všude možně - je to dobrá architektura, mnohem lepší než X86, nenáročná na decode a teoreticky mnohem výkonnější než X86. To co Apple předvedl s M1 je jen začátek nové éry.

Nevím ale jak daleko to je a kdy uvidíme propad prodeje X86_64, teď si nedokážu představit nic jiného na workstation / na práci.

AVX512 sa hodne precenuje. Dodnes to nepouziva snad ziadny bezny program okrem nejakych programov na vedecke vypocty. Problem je ze procesory pri tom zeru ako svina, nie kazdy procesor to ma a aj tie co to maju to nemaju poriadne standardizovane.

AVX512 hlavně není jedna instrukční sada, ale je jich několik. A nějaká velká konzistence v tom, co různé železo podporuje, není. Snaha detekovat víc než jenom minimální základ vede leda tak k výbuchu hlavy skrz kombinatorickou explozi možností

Problém s tou žravostí je ten, že stačí pár AVX512 instrukcí pro to, aby se procesor musel podtaktovat. A výkon je překvapivě výrazně horší než naivní skalární kód. I AVX s 256b registry tím trpí i když ne tak moc.

AVX512 se hodí hlavně pro nějaké výpočty na clusterech. Jedno výpočetní jádro psané tak, aby využívalo naplno šířku registrů a tak nevadil nižší takt. A psané pro jeden konkrétní hardware. Pro hry a podobné věci to nestojí za to.

[incorporated]

Dávám x86 rok. Maximálně dva...

[RDa]

AVX512 hlavně není jedna instrukční sada, ale je jich několik. A nějaká velká konzistence v tom, co různé železo podporuje, není. Snaha detekovat víc než jenom minimální základ vede leda tak k výbuchu hlavy skrz kombinatorickou explozi možností

V praktickem nasazeni existuji snad jen jednotky kombinaci - tipuji kolem 5 (vychazim z poctu generaci jader a cpu, mozna neco malo variability pridava cilene vypnuti nekterych sad pro nizsi/levnejsi marketingove modely cpu).

Takze reseni by bylo algoritmus implementovat pro techto nekolik kombinaci (at uz prekladacem nebo rucni optimalizaci) a vzit cpu flagy, udelat z toho bitovou masku a dle ni vybrat implementaci ktera pobezi. Tohle se bezne deje napr. s predkompilovanyma gpu shaderama, pro ruzne verze shader modelu, pak se runtime vybere to, na co mate hardware.

[anonacct]

To, že je AVX-512 rozdělené na několik extensions v praxi ale nic neznamená. Jsou tam základní extensions, které jsou vždycky na X86 CPU dostupné (F, CD, DQ,BW,VL, atd...) (Xeon Phi nepočítám, to je mrtvé) a pak pár dalších extensions, které si člověk může zjistit za běhu, nebo je vůbec nepoužívat, protože jsou stejně hodně specifické. U nových CPU ten downclock taky není nijak dramatický, v podstatě se zlepšováním výrobní technologie ty důvody nepoužívat AVX-512 mizí. AMD bude podporovat AVX-512 taky, takže je to jasná budoucnost X86 architektury.

Maskování, conflict detection/resolution, atd... to jsou nové věci, které otevírájí úplně nové možnosti. Mě to živí, takže to samozřejmě vidím z mojeho pohledu - a ten je takový, že AVX-512 je momentálně jediná věc, co tu archtekturu bude ještě nějaký čas držet.

[mhi]

anonacct (pripadne ostatni co pisi neco s AVX): mohu se zeptat co delate? A na jake urovni (asm/...)  to delate?

[alex6bbc]

anonacct (pripadne ostatni co pisi neco s AVX): mohu se zeptat co delate? A na jake urovni (asm/...)  to delate?

a neni zbytecne to v procesoru mit, radeji na vektorove vypocty pouzit gpu?

radsi bych se vratil do doby kdy byl v pocitaci procesor a matematicky koprocesor.
ze by CPU umelo zakladni praci s float cisly a na dalsi veci uz by byl koprocesor :-)

[RDa]

a neni zbytecne to v procesoru mit, radeji na vektorove vypocty pouzit gpu?

radsi bych se vratil do doby kdy byl v pocitaci procesor a matematicky koprocesor.
ze by CPU umelo zakladni praci s float cisly a na dalsi veci uz by byl koprocesor :-)

CPU neumi ani float v zakladu, a FP je "koprocesor" stejne tak jako MMX, SSE, AVX. Beru to z pohledu toho, co se uklada na zasobnik pri prepnuti kontextu mezi userspace a kernelem = stavy koprocesoru zustavaj. Proto v kernelu nelze pouzivat FP :-)

Offload na GPU ci FPGA dava smysl pri ukolech, ktere jsou giganicke z pohledu asm operaci - protoze latence planovani, spusteni a synchronizace gpu vypoctu je znacna - a nepomahaj tomu ani heterogenni architektury kdy to sdili pamet - dnesni OS neni schopen planovani tasku na GPU, porad je to jenom nezavisla periferie s vlastnim zpusobem ovladani. A od sdileni pameti se upousti, protoze kdyz vam GPU vidi vsude, tak to je dira jako... ehm.

Ja nepouzival primo asm, ale intrinsics, coz jsou takove jakoby C funkce ktere se prelozi prave na tu danou asm instrukci, ale pracuje se s tim ponekud lip, kdyz muzete resit registry/pointry/data v C syntaxi. Skoncil jsem u SSE (haswell) a nebylo to prilis ono tenkrat (variabilni bitove posuny uz nesli, fixni jsem zvladl). Ono je nekdy pak snazsi pouzit hotovou libku, i kdyz dela veci sloziteji nez potrebujete, tim, ze tomu nekdo fakt znalej venoval cas, tak to muze byt vykonnejsi nez nase, na miru psany, ale lamersky kod

Musi existovat problem, kde se vam to fakt oplati resit rucne - a vysledek bude znat.

[mhi]

Obcas delam nejaky reverse engineering a autovektorizace je u modernich prekladacu celkem bezna. Nejen u nejakeho vyplneni pole hodnotou" jako je toto ...

Kód: [Vybrat]

        movdqu    xmm0, XMMWORD PTR .L_2il0floatpacket.0[rip]   #25.4
        mov       edx, 512                                      #25.4
..B1.6:                         # Preds ..B1.1 ..B1.6
        movdqu    XMMWORD PTR [-16+rcx+rdx], xmm0               #25.4
        movdqu    XMMWORD PTR [-32+rcx+rdx], xmm0               #25.4
        movdqu    XMMWORD PTR [-48+rcx+rdx], xmm0               #25.4
        movdqu    XMMWORD PTR [-64+rcx+rdx], xmm0               #25.4
        sub       rdx, 64                                       #25.4
        jne       ..B1.6        # Prob 87%             
... ale uz bezne i pri hledani/posouvani nejakych bloku dat apod. Musim se priznat, ze je to na palici zkoumat kod ktery ma treba 1000 instrukci s ruznymi cykly co vlastne dela...

Docela by mne zajimalo ceho se da dosahnout nejakou rucni chytrou optimalizaci, kdyz vidim co delaji prekladace automaticky ...

[anonacct]

AVX-512 má výhodu v tom, že to je jakoby GPU instrukční sada, která je v CPU, takže má člověk všechny výhody CPU a nemusí řešit omezení GPU.

[kanoe22]

AVX-512 má výhodu v tom, že to je jakoby GPU instrukční sada, která je v CPU, takže má člověk všechny výhody CPU a nemusí řešit omezení GPU.

Vsetky vyhody nemas. Mas pomalu pamet (DDR vs GDDR), tich jadier ktore to maju je iba par (neviem ako sa to sprava pri multithreadingu - napr 8c/16t procesor, ci ich mas 8x alebo 16x), kdezto tich jadier v grafikach mas dnes tisicky, vykon watt/instrukcia je pri grafikach na mile vzdialeny od procesora pretoze tam su jadra taktovane viac menej na efektivnom takte, kdezto v procesoroch sa ide az na krv aby si si mohol do letaku dat ze to boostuje na 5GHz.