Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Navrhuju prekompilovat CUDA na RiscV. ;-)
Už tady byly pokusy převádět věci psané pro CUDA na OpenCL.
Nejlépe automaticky.
Teoreticky a na ukázkových kusech SW to fungovalo.
V praxi se neuplatnilo, protože kodéři jsou čuňata.
ved na to budu dobre tie akceleratory AI, prekoduju si to za pochodu :)
Třeba AMD kompiluje CUDA na svůj HIP. OpenCL je už mrtvé (Apple ho vytvořil a nakonec i ukončil; AMD nikdy nemělo dobré ovladače a NVidia vždy prosazovala svou CUDU; Intel nemá výkon, dedikované grafiky jsou jen kapka v moři).
Jinak třeba grafický čip Rendition Verite byl obyčejný RISC CPU, který vykonával grafické operace. Díky své obecnosti (nebyly to zadrátované funkce fixed function pipeline klasické tehdejší GPU) na tom jel single pass multitexturing v Quake 1. Tím pádem to bylo stejně výkonné jako Voodoo 1, které nemělo multitexturing, ale mělo dvojnásobný výkon, takže zvládlo multipass multitexturing. Omezením bylo, že Verite uměl tímto trikem jen lightmapu ve stupních šedi a novější hry, jako Quake 2 už měly barevné (navíc Carmack pak už nechtěl dělat speciální renderery - vedle SW renderingu nechal jen OpenGL a Glide - nejsem si jist, jestli pak už i ten nebyl jen přes wrapper).
Dedikovane CPU co renderuji grafiku... to jsme meli v mnoha obdobach na (CAD) grafikach - ruzne cpu architektury, ci dsp procesory.. az po pokus o integraci do jednoho kremiku v podobe Larrabee ktery skoncil celkem fiaskem.
Fixni pipeline ma holt navrch, i kdyz je realizovana nejakym mikroprogramem.
Imho to cele souvisi s tim, jak na pocatku byla rychla pamet vuci pomalemu compute, a nyni mame rychly compute a pomale pameti. A vyrobci se holt nasli v jinem trhu.
Jim je z tej generácie bardov, ktorú nevedia nové kádre nahradiť, a tak im musia riadiť ľudia ako Jim, ktorý je poste šefinžiniera (mikro-)architektúr CPU skoro 40 rokov (a pred tým sa 5-10 rokov učil ako robiť CPU)
32-bit computer family, VAX
8800/8700/8500, (uvedené na trh 1986, vývoj minimálne 18 mesiacov )
pipelined the microinstructions
I-box and E-box - Jim Keller, project leader
https://people.computing.clemson.edu/~mark/architects.html
A problémom všetkých technických odborov je, že týchto ľudí nedokáže nahradiť.
A keď tak, tak sú to deti tých bardov
/DP-10 (KA10), 1967 - Alan Kotok (architect)
KA teams, 1967
Hardware: Alan Kotok, Bob Clements, Dave Gross, and Bill English (documentation)
Software: Tom Hastings, Tony Wachs,
!!!Dave Plummer!!!
https://people.computing.clemson.edu/~mark/architects.html
Dave Plummer má dcéru "Zuzku"
24. 2. 2017
Co se x86 architektury, tedy Zenu, týče, svěřil Keller sestavení a vedení vývojového týmu do rukou Suzanne Plummer, která v té době v AMD působila zhruba 10 let. Plummer jako šéfinženýra týmu Zen vybrala inženýra, který v AMD záhy dovršil druhou dekádu - byl jím Mike T. Clark. Tyto dvě osoby měly na starost vedení týmu a vývoj Zenu.
https://diit.cz/clanek/jim-keller-nebyl-sefinzenyrem-zenu
Nahradit HW nVidie nebude problém, průšvih bude SW...
Vždycky jsem si myslel že na tyto typy úloh jsou nejlepší architektury typu VLIW. Asi žiju v minulosti. Na druhou stranu nejsem CPU architekt, tak tomu rozumět nemusím :-)
Nejdražší je velká RAM, aby se tam vešel velký model k učení (pro malý model stačí komoditní hardware v podobě herní grafiky). Pak je otázka, nakolik je levnější custom hardware. Tj. vývoj vlastního čipu plus cena RAM vs komoditní hardware, kde si NVidia*/AMD*/Apple** účtujou svou "daň" za hodně RAM.
*) Výpočetní grafické karty, speciálně myslím ty s VRAM o hodně větší než je herní grafika.
**) Apple má RAM sdílenou a GPU dokáže využít většinu z ní (resp. všechnu, ale aspoň 8 GB potřebuje OS a nějaký ten program).
VLIW je do znacnej miery historicky prezitok z doby pred superskalarnymi procesormi. V dobach drevnych to umoznilo lacnu a rychlu implementaciu instruction level paralelism na urovni vyssej nez pipelining bez nutnosti riesit out of order execution a/alebo register renaming (aj ked z toho asi VLIW moze tiez profitovat).
S OOO execution, register renaming, s flexibilnejsimi pamatovymi modelmi ako total store order a optimalizujucimi prekladacmi je VLIW uz podla mna zbytocne.
Ono totiž některé informace potřebné pro optimalizaci nejsou známy v době překladu programu, ale až během vykonávání.
Dalo by sa to aj tak povedat.
Hlavne, out of order execution a register renaming maju tu vyhodu, ze pokial je kod aspon +- vhodne poskladany, vie ho optimalne vykonat nejaka pomerne siroka rodina architektur.
Kod sa staticky preusporiada v case prekladu tak, ako to najlepsie vidi prekladac a pripadne potom este pocas vykonavania si to moze jadro otunit podla toho ako je fyzicky nakonfigurovane.
Ked ma prekladac posledne slovo, tak pri zmene architektury moze dojst k tomu, ze kod rychlejsie bezat nebude, pretoze nove vlastnosti architektury vyuzit nedokaze. Napr. znizena latencia, alebo rozsireny paralelizmus na urovni vykonnych blokov.
A tak nejako mam pocit, ze robit OOO ex alebo register renaming s VLIW je celkom dost velky spas.
Groq si nemyslí, že VLIW je přežitek a s tím jak AI/ML aplikace spoléhaj na optimalizované mikrokernely nedává overhed OOO přístupu moc smysl. Lepší ten křemík ušetřit a řešit to v SW, když už se SW stejně píše ručně na míru HW
Na CPU nemá VLIW smysl, protože většinou jde o běh předzkompilované binárky, po čase pro jiného výrobce nebo jinou generaci stejného. Výjimkou je JIT (Just in Time kompilace) - tak fungovala Transmetta/Efficeon. U GPU je to jiné, protože tam si kód kompiluje ovladač sám (aplikace si může zkompilovaný kód cachovat, takže je to jen jednou po update ovladače). Ale i u GPU se od VLIW odešlo, protože skalární procesor má prostě více možností, zvládne efektivně různorodější kód.
Transmetta se píše Transmeta
R.I.P.
:`- (
Za to mám ten mínus? Zdejší komunitě asi ještě moc nerozumím :-)
To je snadný.
Mínuska se dávají za pravdu.
Pluska za pochvalu AMD.
A když pravdivě pochválíš AMD dostaneš 2x víc plus XD
Hurá. K singularitě budeme uhánět mílovými kroky.
Snad jejich technici pracují lépe než marketing. Dát nové architektuře vyvinuté startupem název black hole není ideální...
Třeba to tak pojmenovali investoři... :D
Ohledně x64, tedy správně AMD64, je Keller trochu více politický, než faktický, a také si malinko přihřívá svou polívčičku, ale vzhledem k tomu jakou je autoritou v oboru, nyní v roli CEO, tak mu odpouštím .. :)
Faktem je, že za rozšířením AMD64, tj. prakticky všechny CPU v klasických PC, nestojí až tak pán Keller nebo samotná architektura AMD64 (x64), jako spíše skutečnost, že AMD do 64-bitové sady instrukcí zahrnula i zpětnou kompatibilitu pro x64-32bit, což konkurenční sada od Intelu IA-64 (společně s HP, původně pro CPU Merced, přejm. na Itanium) zpětně kompatibilní s x64-32bit nebyla. IA-64 byla spíše koncipována jako serverová architektura (EPIC, VLIW) a nějak si ji moc nedokáži představit v PC (osobním počítači) i vzhledem k tomu, že vyžaduje jiný přístup programování, část logiky práce s vlákny je přenesena na kompilátor apod . .
Nakonec IA-64, resp. Itanium, zařízl sám Intel neb se prostě neprosadil . . . tak jako třeba mé oblíbené Alfy s OpenVMS, na kterých jsem měl tu čest nějakou dobu psát. OpenVMS posléze běželo i na Itaniích .. tak už to bývá, že ty nejlepší technologie, ano myslím si, že platforma OpenVMS byla jednou z nejlepších, nebo vůbec nejlepší, se nakonec neprosadí . . .
Každopádně fandím Kellerovi .. je to génius, který pod Lisou pomohl vytáhnout AMD, Tesle postavit vlastní řešení .. jsem zvědav, co se podaří nyní ...
A není náhodou OpenVMS teď portováno na x86 (resp. amd64)?
A bylo v případě IA64 vůbec o co stát? Pokud se podíváme například na výsledky TPC-C z roku 2007, stejné hodnoty tpm a tpm/US$ dosahuje Power5+ based system s polovinou jader proti Itanium-based Superdome.
https://www.tpc.org/tpcc/results/tpcc_results5.asp?print=false&orderby=t...
On Intel nabízel HPE možnosti, jak Itanium zrychlit, ale HPE už nemělo zájem. Ten CPU byl už jen pro doběhnutí kontraktů. Pro zajímavost, i když za ty poslední roky frekvence Itania moc nerostla, výkon rostl furt o dost (pomocí schválených jednodušších optimalizací). Ale procesor by stejně neměl budoucnost, ta idea optimalizace se ukázala později jako nevhodná.
Ano aj nie.
Spatna kompatibilita s i386 tomu rozhodne pomohla. AMD vtedy nemalo trhovu poziciu na to, aby presadilo nieco, co nie je spatne kompatibilne s x86. Bola by to politicka samovrazda.
Na druhu stranu cisto spatna kompatibilita AMD64 uspech nezarucila. Niekedy v druhej generacii Itanii Intel "kompatibilitu" s x86 a dokonca aj AMD64 pridal. Z biedy ho to nevytiahlo a ani Itania kompatibilne s x86 nikdy nedosiahli predajov predikovanych Itaniam prvej generacie.
Pri AMD64 slo minimalne rovnym dielom o to, ze AMD fixlo to, co v Inteli pred 20timi rokmi nejako urobili a odvtedy nemali potrebu fixnut. 8 general purpose registrov a segment:offset boli v '79tom bohovsky napad. Ale okolo roku 2000 uz to smrdelo.
Takze mam za to, ze ak by AMD64 nebolo urobene dobre, nepresadi sa. A o ziadnu politicku agitku moc nejde.
Nebylo to naopak tak, ze HW podpora IA-32 byla pravě součástí uvodnich generaci Itanií a přišla o ní od modelu Montecino?
https://en.wikipedia.org/wiki/Montecito_(processor)
https://en.wikipedia.org/wiki/Itanium
Hej pravda. Z nejakeho dovodu som si to pamatal naopak. Cize ta kompatibilita tam bola. Aj tak to bol shit.
Nutno este dodat, ze Alpha nebola VLIW, ale obycajny RISC. Debilny VLIW z toho spravili az pod taktovou Intelu.
Itanium mělo v sobě 386, hlavně pro instalaci OS. Ta byla samozřejmě pomalá, ale později tam přibyla o dost rychlejší softwarová emulace v OS. Podobně jako rychlý FX!32 na Alphě. Nevím, jestli pak tu 386 odstranili, ale asi už tam tím pádem neměla smysl. Ty ne-x86 verze Windows se běžně instalovaly tak, že ten počítač měl speciální BIOS, který si z CD Windows jen vytáhl potřebné soubory, takže nebylo třeba emulovat bootovací proces x86 Windows.
"Alpha ... pod taktovou Intelu."
???
Já si to tedy pamatuji tak, že Alpha = AMD K7.
Wikipedie píše že Alphu koupil Compaq.
Tak teď jsem se v tom ztratil.
Možná by pomohl retročlánek.
Co se zařízl vývoj Alphy, tak lidi přešli do AMD a vytvořili Athlon. Takže svým způsobem žila dál.
Například SlotA používal EV6 protokol, původně vyvinutý pro DEC Alpha.
https://en.wikipedia.org/wiki/Slot_A
Ludia z Alphy skoncili kde-kade. DEC s IPckom kupil Compaq, ten potom kupilo HP (a konecne sa naucilo robit notebooky) a ti, kedze mali aj PA-RISC, vyksefovali cosi s Intelom.
Zo vseobecnej depky zo zarezania alphy a VMS sa ludia rozprchli kde-kade. Cosi skoncilo v AMD (aj ked K6 bude mat cosi asi aj z Cyrixa 6x86) a cosi skoncilo v Microsofte, kde splodili Windows NT.
Vypadá, jak kdyby baštil anabolika a tejden nespal :)
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.