Vlákno názorů k článku Rozšíření instrukční sady „Advanced Vector Extensions“ na platformě x86–64 od atarist - Prvni MMX bylo fajn. V podstate jen par...
-
Prvni MMX bylo fajn. V podstate jen par desitek instrukci a "par" tranzistoru na mikroprocesoru (ani se nemuselo nic platit za nove registry).
Potom to s SSE, AVX a uff uff AVX-512 strasne narostlo: nove obrovske registry, stovky novych instrukci, VEX, EVEX madness atd.
Mam pocit, ze ted mame na mikroprocesorech doslova miliony tranzistoru* s AVX (AVX-512 asi jeste ne), ktere v 99% vubec nic nedelaji, mozna se to maximalne zapne pri encodovani videa pri telekonferencich - a an tady to zdaleka nevytizi vsechna jadra. Tezko rict, jestli je to ta spravna cesta vpred.
* miliony: cele AVX nasobeno poctem jader, to je v podstate treba 32*16 FP ALU jednotek a to nejsou jednoduche obvody.
-
Vas prispevek mne inspiroval hledat informace jak to vlastne je: https://www.realworldtech.com/haswell-cpu/4/
-
Pavel TišnovskýZlatý podporovatelJo no, kazde vylepseni vykonu zatim stalo dalsi a dalsi tranzistory - coz obecne neni problem, protoze diky Moorovu zakonu je mame "zadarmo" :) Ovsem kumst je, jak zajistit, ze ty tranzistory se pouziji k necemu rozumnemu - a IMHO jsme uz tak pred 5-10 lety narazili na prakticke limity.
1. neRISCove prvni CPU, typicky osmibitove, tam se setrilo, kde se dalo (tri registry u MOSu atd.)
2. vic tranzistoru v dalsi generaci umoznilo vznik 6809 s nasobickou. Ta vyznamne urychlila nektere algoritmy a nekde zase vubec nebyla pouzta (napada me treba textovy editor).
3. potom FPU, typicky spousta tranzistoru a mnohdy nevyuzito (45000 tranzistoru u 8086 napriklad
4. RISCova pipeline - tranzistory pro latche, dalsi pro interlocking. Neco to stalo, ale vylepsilo to prakticky vsechny programy, pokud tedy byl prekladac alespon trosku rozumny co se tyka skoku a pouzivani registru
5. vicejadrova architektura - hmm toto je tezky :) tady nas totiz bije Amdahluv zakon a nikdo to moc neumi programovat :)
6. SIMD, hlavne "dlouhe" SIMD typu AVX-512 - IMHO je pravda, ze v 99.9% to tam proste na cipu existuje a "nic to nedela". Opet - neumime to programovat.
PS: reseni samozrejme nemam, a kdybych mel, tak bych to prodal ARMu, AMD nebo Intelu :)
-
Řešení je v zásadě jednoduché - vyrábět čipy specializované pro daný účel. Což se už do jisté míry děje - CPU, GPU, AI U (či jak to nazvat), Bitcoin U. I jednotlivá CPU se liší výkonem, i když architektura samotná je do jisté míry sdílená (tam je to zase ekonomický problém).
Omezení vychází víc i z dnešních jazyků - na to, že třeba Java byla původně pro jednoduchá embedded zařízení, tak je zvláštní, že core library závisí na float typech. O dnešním JavaScript radši ani nemluvě...
-
Pavel TišnovskýZlatý podporovatel
jo no, tím se ztrácí to kouzlo mikroprocesorů jako univerzální součástky, kterou je možné vyrábět v milionových sériích a tím zaplatit laby. Jako ASIC tady jsou a budou, ale není to levná věc.
Že paradigma dnešních mainstreamových jazyků zaostalo za HW - to je naprostá pravda.
-
To je dejme tomu dnesni trend, ale problem tohoto pristupu je, ze jakmile se typ operace zmeni, tak to musi nekdo prepsat a lidska prace, zvlast specializovana, je dost draha. Pokud chip podporuje konkretni typ kodovani videa, tak to bezi skvele, pokud mu das jiny typ videa, tak ma smulu. V lepsim pripade vyrobce vyda update, v horsim pripade si koupis novou verzi v nejhorsim ti vyrobce rekne - my podporujeme tenhle format a jiny ne (kvuli licencnim poplatkum, konkunrencni vyhode, ... ). Tohle si muzou dovolit mozna vyrobci fotoaparatu a Apple v uzavrenem systemu. Ale poskytovatele video obsahu (twitch, youtube, ...) si neco takoveho mohou stezi dovolit - teda oni to delaji, proste omezi bitrate, ale to uz si zakaznik stezuje, proc mu to nejede ve FullHD.
Ta potreba specializovanych cipu vznikla jenom proto, ze obecne CPU na ty operace nestaci nebo u toho zere moc energie. Kdyby to tak nebylo, nikdo by se tim nezaobiral. A to si myslim, ze je smer, univerzalnost - i GPU jsou uz uplne nekde jinde, nez kdysi. Proc by se nekdo zaobiral potrebou dekodovat video specializovanym kusem hw, kdyz to muze udelat na CPU.
-
No právě, CPU není efektivní, tak se hledají lepší možnosti, ať už GPU nebo zmiňované ASIC. Běžný uživatel to neřeší, neboť těch speciálních operací dělá poměrně málo a tam mu "obyčejné" CPU stačí - i tak je 1000-krát v průměru předimenzované, ale ve špičce těch 10-30% využije. Hráč nebo profesionální video editor si koupí předimenzované GPU, které bude 60% nevyužité. AI unit u Apple M1 se využívá vteřiny za den (?) - ale asi ušetří spoustu času a energie ve chvíli, kdy k tomu dojde.
... ono to je v zásadě obecný problém - běžný uživatel potřebuje auto, které dokáže řešit efektivně specifické problémy, ale 95% času někde stojí. Svět počítačů na tom není defakto až tak špatně a pro profesionální použití tam máme relativně slušné řešení - cloud a pokud-budou-cenově-výhodné, tak on demand instance. Omlouvám se za filozofickou odbočku .
-
Prijde mi pozoruhodne, ze Intel i AMD koupili vyrobce FPGA. Rekl bych, ze tady vidi asi urcitou budoucnost.
Problem ale vidim v tom, kdo bude psat to HDLko :). Padaji argumenty, ze vyvoj prinese nejake nove nastroje, no nejsem si uplne jist jestli tady jde nahnat neznalosti nejakymi tooly (efektivita takoveho "programu" resp. HDLka IMHO pujde do kytek).
Ja bych treba hrozne rad videl procesor, na kterem bych si mohl zadratovat vlastni instrukce pro nejake konkretni vypocty. A to by stacilo par (desitek) LUTu.
Na ten nadbytecny kremik jde nahlizet IMHO ze dvou hledisek:
- naklady na porizeni, tam mi vadi nevyuzivana plocha
- spotreba: pokud ta nevyuzivana plocha nic nezere, tak je mi to v provozu asi jedno.Zajimave mi prijdou navrhy procesoru, ktere optimalizuji na oboji, tzn. umi vyuzit ruzne vypocetni jednotky v ruznych konfiguracich pro celou radu instrukci
-
HDL je podle me skvela volba, problem je presne jak rikas, kdo to bude programovat, navic je to natolik specificka vec, ze to neumi kazdy a taky je to dost vendor specific, i kdyz standardy jako Verilog, VHDL existuji. Snad uz se tam chyta i OpenCL.
Dalsi vec je, ze ne vsechno ma cenu optimalizovat, pokud mas algoritmus, ktery se nebude pouzivat zase tak casto, tak je blbost, aby nad tim velmi specificky top programator, ktery tomu rozumi, travil tolik casu a nakonec mel treba oproti CPU narust vykonu 20%. Ony ty simd priklady vsechny krasne funguji prikladu vektorovych souctu, ale takovych trivialnich operaci zase tolik neni.
-
Pavel TišnovskýZlatý podporovatel
Popravde jsem v tech "novych nastrojich" hodne skepticky. Treba (ale uz se opakuju) vyvoj prekladacu pro mainstreamove jazyky strasne ustrnul a neumi vyuzit moznosti dnesnich CPU; tedy vlastne nedokazou vyuzit ani 10-15 let stare CPU. Takze ze by se v oblasti FPGA objevilo neco na rozumne urovni abstrakce, z ceho by lezly optimalni obvody... no uvidime, ale nevim nevim...
-
Novymi nastroji jsem myslel ruzne pokusy priblizit obvody typu FPGA lidem, kteri netusi co je HDL nebo hradlo, ale vidim to vlastne uplne stejne.
Na druhou stranu by tyhle vlastnosti myslim otevrely dvere na specificke aplikace, kde se vyplati cas nejakeho "dratare". Napadaji mne treba ruzne JITy, zpracovani obrazu a signalu, apod. Proste veci ktere se jednou napisou a 1000x pouziji.
3. 11. 2022, 12:29 editováno autorem komentáře
