Intel pracuje na úpravách kódu x86 FPU, připravuje jej pro AMX

1D konvoluci nebo 2D konvoluci? 1D konvoluci s 2D operacemi uděláte taky, jen musíte mít správně poskládaná data v té matici a tuším, že konvoluční matice má pak tvar symetrické Toeplitzovy matice. 2D konvoluce je jen maticové násobení, akorát se z matice dat musí vyseknout kus odpovídající velikosti konvoluční matice a udělat těch konvolucí pak m*n, aby se z toho poskládala celá matice výsledků (dělá se to tak i bez těch AMX instrukcí, akorát to většinou lidi píšou tak, že člověka hned netrkne, že je to maticový výpočet). Každý výsledný bod je pak skutečně výsledkem lineární algebry, celá výsledná matice vznikne správným seskupením těchto mezivýsledků.

Jak se tkaová matice dělá, je vidět třeba tady:
https://docs.gimp.org/2.2/cs/plug-in-convmatrix.html

Pro mnou vyjmenované operace je potřeba akorát udělat padding pomocí nul na okrajích matice dat (třeba na okraji obrázků) o poloviční šířce té konvoluční matice, aby z těch filtrů nevycházely kraviny (nebo na okrajích upravovat konvoluční matici, aby nelezla konvoluce přes okraj dat, ale to je trochu komplikace, protože se kvůli tomu musí dynamicky nulovat prvky té konvoluční matice). Nebo na okrajích počítat jen pomocí klasických / vektorových operací a poskládat to z nich a maticově počítat jen vnitřek.
Pokud by tohle rozšíření fungovalo opravdu rychle, tak by se tím podle mě opravdu dalo slušně akcelerovat maticové výpočty používané pro grafiku.

Jo, tak tu 1D konvoluci jde dělat maticově. Vektor se rozšíří ve směru kolmém na původní rozměr vektoru o nuly na čtvercovou matici, konvoluční matice je pak ten symetrickej Toeplitz a výsledkem je matice, ze který zahodíte všechno kromě jednoho řádku. Nebo sloupce? Pokaždý se musím podívat na definici :-D
Je pravda, že pak se zbytečně místo N operací dělá N*N operací, ale holt tyhle maticový konstrukce jsou vhodnější na 2D konvoluci (třeba) než 1D.

A při tý 2D konvoluci jak se dělá bod po bodu, tak je pravda, že to "není" componentwise řešení, nicméně vypadne vám matice, kde bod uprostřed má hodnotu výsledku pro daný bod původní matice a zbytek zahodíte, protože vás nezajímá. Pravda, ten zbytek prvků se vlastně počítá zbytečně.

13. 10. 2021, 14:59 editováno autorem komentáře

A mohl bys popsat, jak to uděláš v tom AMX?

Máš 2 datové typy - INT8 a BF16, a 5 instrukcí, co spočítají dot product. To je jediná operace, kterou to podporuje.

Jenomže on nebude jenom rychlejší, on bude i dražší. Navíc bude pomalejší v těch obecných a nejčastějších úlohách. Protože čím větší bude jedno CPU jádro, tím méně se těch CPU jader vejde na příslušný čip. Nemluvě o omezené kompatibilitě.

Naopak - v konečné kalkulaci je to rychlejší a levnější. Stačí se opět podívat na ten Apple M1. Je to jeden CPU, použitý v různém HW, protože není ekonomické těch CPU navrhovat víc. Není ani ekonomické navrhovat diskrétní GPU, když může být přímo v tom CPU a sdílet paměťovou cache, atd..

SIMD není slepá ulička, je to jediná možnost, jak saturovat paměťovou sběrnici. SIMD je univerzální, pomocí AVX2 můžeš třeba parsovat JSON, což bych řekl, že je právě ta "obecná a častá" úloha. Časem se přichází na to, že víc a víc úloh jde takto zrychlit.

Někdy by možná bylo vhodné mít třeba 64/128 dumb jader, ale z konzumní perspektivy je lepší třeba 16/32 výkonných jader co umí 128-bit nebo 256-bit SIMD. Já mám dobré zkušenosti i s AVX512.

Směšujete hrušky s jablky. Například Apple ARM s Intel x86.

Navíc, já nejsem proti SIMD, ale ve většině aplikací je jedno, z jaké strany přijde výkon, protože numerické výpočty jsou většinou výborně paralelizovatelné a z hlediska uživatele je jedno, zda výpočet provádí 64CPU jader za pomoci 128threadů a AVX256, nebo 32CPU jader a 64threadů a AVX512. Podobně matice atp.

Také může být výhodné, oproti výpočtům za mohutného použití paměti, použít jiný algoritmus využívající zejména registry CPU, protože je to obvykle všestranně efektivnější, včetně úspor energie. Navíc tu jsou další nevýhody AMX, jako zesložiťování CPU jader a jejich instrukčního souboru, kompatibility a zhoršení použití instrukčního souboru pro realtimové a embeded aplikace.

Je také načase říci, že multithreading tu již je a stejně ho musíme využít.

13. 10. 2021, 21:37 editováno autorem komentáře

Oba to jsou procesory - a u obou můžeme pozorovat, že tam toho výrobci chcou nacpat co nejvíc.

To právě ne. ARM je v podstatě RISCový procesor, který těží z jednoduchosti a efektivitě svého návrhu, díky které je výkonnější, zabírá malý prostor na křemíku, a je i energeticky úspornější. Takže čím složitější procesorové jádro, tím větší problémy zvyšovat jednojádrový i mnohajádrový výkon a spořit energii.

U toho Intelu je to hodně znát, CPU architektura je napjatá k prasknutí, zejména kvůli zachování historické kompatibility, protože těch pět nebo kolik procent křemíku, energie a výkonového handicapu krát počet jader na čipu je již znát. Zbývá největší plus a to je zpětná kompatibilita a tu již pomalu začíná přebírat 64bit ARM, či případně RISC-V.

Intel a AMD ale má ještě zatím jednu přednost, naučil uživatele využívat mnohojádrové procesory, které dodají výkon vždy.

Takže si myslím, že Intel s AMX a AVX-512 spíše dělá PR, aby mohl říci, že má něco navíc a proto Linus Torvalds nesnáší Intel AVX-512.

Většina procesorů Intelu (kromě těch nejdražších) má jen jednu 512-bitovou FMA jednotku, takže jediná výhoda AVX-512 jsou instrukce navíc, které AVX2 nemá.

Ano, tak nějak. A někdy je lepší zůstat na instrukcích AVX2.

Tak maskování v AVX2 vůbec není, embedded broadcast/rounding je taky velmi užitečná věc, a těch instrukcí co přidává AVX512, a jsou nenahraditelné, je celkem dost.

Výhody člověk pozná, až si v AVX512 něco napíše...

Ano, AVX je někdy celkem fajn, ale je to legrace, která má dobrý smysl jen když se mohutně zvětší CPU jádro a tím i cena křemíku a také maximální spotřeba celého procesoru. Navíc problémy s kompatibilitou. A což teprve AMX...