Nya detaljer läckta om Ryzen 9900X3D och 9950X3D

Hårdvarumässigt så är det PCIe 4.0

När först Sony började prata om PS5 så var det långt innan lansering och då fanns det inte PC att köpa med PCIe 4.0
Sen kör PS5 även andra optimeringar med någon komprimering.
Men om man säger okomprimerad data, "RAW", Då är det PCIe 4.0 med 4 banor.
Så motsvarande att ladda hem eller ladda upp en packad fil så kan inte PS5 komma upp i mer än teoretiska 8GB/s med 7,något i verkligheten.
Men sen med komprimering så kan det motsvara mer okomprimerad data.
RAM minnet har ju mycket högre bandbredd. Så om du kopierar komprimerad data från SSD till RAM och sen packar upp det i RAM så kan det gå snabbare om du har tillräckligt utrymme att bolla runt saker.

Men rent fysiskt så är det fortfarande PCIe 4.0 gränssnitt mot SSD.

Men 'tricket' där är ju om man pratar om en framtidsprodukt.
"Den produkten vi släpper i framtiden blir bättre än de produkter som finns idag"

Alltså jag menar inte att PS5 är en framtidsprodukt idag.
Men första gången PS5 nämndes var långt innan lansering.

Verkar som många tolkar den här nyheten som att 9950X som har 4.3 GHz BAS och 5.7 GHz med turbo att 9950X3D skulle nå upp till 5,7 turbo på båda CCD. Läser man noga står det endast att de har samma bas på 4.3, vilket är ganska ointressant?

Man kan säga att helheten består av flera delar och för PS5 så var/är en av dessa delar PCIe 4.0

Sony visste om att de hade planer på att utveckla, producera och sälja PlayStation 5 långt innan releasedagen.

Det är möjligt att göra en produkt och bara göra en "tyst lansering"
Att man inte nämner produkten före försäljningsstart.
Men många företag pratar om sina kommande produkter innan de finns att köpa för att bygga en hype och öka köpintresset.

Alltså "tricket" är att prata om produkter innan lansering för att bygga hype.
Det är väldigt vanligt att företag gör det.

Sony visste att de skulle använda AMD Zen 2 baserad krets i PS5 långt innan försäljningsstart.

Man kan säga att vi båda kommer med en del av sanningen. Att vi båda har åtminstone delvis rätt.

Men om du vill vinna i en slags du har 100% rätt och jag har 100% fel sätt, så...

Bevisa då dessa saker;

1. M.2 NVME SSD PCIe 3.0 är lika snabb eller snabbare än M.2 NVME SSD PCIe 4.0

2. Bevisa att Sony inte visste att de skulle använda Zen 2 baserad krets före Zen 2 (Ryzen 3000 serien) processorer och datorer börjat säljas till slutkonsument.

3. Att marknadsföring bara är ett hittepå som inte existerar.

2010 fanns inte ens Sandy Bridge på PC,
Sandy Bridge lanserades 2011.

Jag skaffade en begagnad Mac Book Pro 15" 2011 med Sandy Bridge quad core.
Tror det var den första portabla Quad core Macen ?
Men mitt exemplar började strula efter några dagar och sen ville den inte boota alls.
Man kan tänka sig att den hade något strul och om förra ägare hade "bakat" moderkortet eller något, jag vet inte.
Var privat via Tradera och den fungerade när jag mottog den så svårt att göra något.
Så Jag skaffade en helt ny Mac Book Pro 13" (Coffe Lake) med garanti istället (fungerar fortfarande).

Apple hade även två olika "generationer" Sandy Bridge.
Om det var early 2011 och late 2011 eller något sånt.
Där den tidigare (som jag skaffade begagnad) bara hade USB 2.0 och den senare hade USB 3.0
Sandy Bridge var sista generationen för Apple där man kunde uppgradera både RAM och HDD som man ville (2.5" SATA, går att använda SSD).
Önskade lite att Apple hade fortsatt med uppgraderingsbara datorer någon generation till.
Hade hellre tagit en med Ivy Bridge eller Haswell där jag fortfarande kunde byta minne och lagring.
Men hade ju inte varit så snabb idag ändå.

Känns som att även inom PC så var Sandy Bridge - Kaby Lake en era,
Att jämföra en före 2011 Mac blir inte riktigt rättvist om man inte jämför med en PC som är ännu mer retro.

Säg om du någon gång de senaste åren har använt en Core 2 PC så tror jag inte att du tyckte den var speciellt snabb heller.

M4 har inte stöd för SVE/SVE2 däremot finns det stöd för SME (Scalable Matrix Extension) (och SSVE).
Jag blir lite nyfiken på vad du menar med "AVX-512 done right"?
Båda instruktionsuppsättningarna innehåller bra saker men det är inte direkt så att man sitter på x86 och önskar att man hade tillgång till SVE istället. Det finns en hel del "problem" med SVE också t.ex. är det betydligt krångligare att skriva algoritmer som använder permutes när man inte har en fast registerlängd, sorting networks osv. Det finns luckor i vilken elementstorlek man stödjer för vissa instruktioner t.ex. arms motsvarighet till compress som bara går ner till 32 bitar, AVX512 har stöd för 8/16 bitars element vilket är väldigt användbart om man skriver simd algoritmer för text (expand motsvarighet saknas helt). Hur man hanterar maskning/predication känns mer enhetligt på x86.
Dessutom verkar de flesta nöja sig med att implementera 128 bitars SVE med några enstaka 256 bitars undantag. Det hade kanske varit bättre med neon256 + maskning istället för att krångla till det variabel vektorlängd för simd och bara haft det för streaming varianterna.

Jag skulle inte kalla parsning av t.ex. json, xml, uft-8.. sortering, filtrering, sökning, hashing osv.. för nischfunktion eller extrem nisch.

Jag är inte helt säker på att jag uppfattat det rätt men om jag tolkar de delar som faktiskt handlade om AVX512 vs. SVE2 rätt så är det själva scalability delen med variabel vektorlängd som du menar gör SVE "AVX-512 done right"?

På pappret verkar det väldigt smidigt med variabel vektorlängd men det gör det betydligt krångligare att programmera vissa typer av algoritmer. Allt handlar inte om enkla fp algoritmer där man kan använda SoA layout. Det finns många problem man kan optimera med simd som använder AoS och då är det enklare med fast vektorlängd. Använder man SVE måste man komma på nåt smart sätt att försöka beräkna index för shuffles dynamiskt utifrån vilken hårdvara man kör på och i vissa fall använda olika kodvägar beroende på vilket stöd för vektorlängd som faktiskt finns i hårdvaran. Problemet är att man måste se till att det fungerar hela vägen från 128 bitar upp till 2048 vilket innebär att den typen av kod måste testas via en emulator. Just nu ser det ut som framtiden för SVE är 128 bitar så det är mycket krångel för kod som antagligen aldrig kommer köras på något annat än 128 bitars SVE. Att man kan köra samma binär på utstickare som fujitsus 512 bitars versioner är helt ointressant eftersom det handlar om HPC och då programmerar man mot specifik hårdvara.

Det blir också lita av ett hönan och ägget problem. Varför skriva om neon kod till sve idag om vinsten är ganska liten? Därför jag är inne på att det kanske hade varit bättre att bara lägga till instruktioner till neon med maskning och en storlek större vektorer som tillval och lämna resten åt acceleratorer som t.ex. SME, NPU, GPU beroende på latens.

Varför är just 4 x 128 bitar det som är mest flexibelt och bäst? Varför inte gå ner till 8 x 64?
Det handlar inte bara om fler transistorer och sämre energieffektivitet när man går ner i vektorstorlek utan varje instruktion tar ju även upp OoO resurser i form av en reorder slot, 128 stores? du har även en store queue..

Jag skulle nog säga att AVX512 faktiskt är "AVX-512 done right". Det största problemet med AVX512 är hur Intel valde att hanterar utrullningen och osäkerheten för stöd i framtiden för olika plattformar. Nu har AMD AVX512 och Intel har sitt AVX10.2 förslag på gång så det är inte längre ett problem. Jag hade helt klart föredragit om Intel skippat 10.2 och kört zen4 varianten för e-cores med full shuffle enhet, resten inklusive load/store som 256 bitar och dragit ner på antalet register. Uppenbarligen fungerar det väldigt bra vilket AMD har bevisat.

Poängen var att det på pappret verkar vara smidigt med variabel vektorlängd och att man kan skriva en implementation som skalar automatiskt med hårdvaran. När man sen tittar på verkligheten så ser det annorlunda ut och man kan behöva skriva olika implementationer för olika fysisk vektorlängd även på SVE och då har man fem (arm tog som tur var bort galenskapen med valfri multipel av 128) olika vektorlängder att ta hänsyn till vilka det för tre i princip inte finns hårdvara att testa på idag. Avx512 har bara en storlek (två med 10.2) där du som utvecklare själv fritt kan välja att jobba med kortare register. Ibland t.ex. vid parsning kan det vara smidigt att använda olika vektorlängd i samma algoritm.

Jag vet inte om rvv är ett bra exempel. Finns det någon som gillar rvv utom de som skrev specifikationen? Rvv har ännu mer likheter med traditionella vektorprocessorer som cray med elementstorlek som global state. Väldigt smidigt för traditionella HPC laster men mindre smidigt för mycket av det man använder simd till idag.

Valet av design av ISA påverkas nog mer av fast instruktionslängd än något annat. x86 kan lägga till några tusen nya instruktioner om man behöver det men det kan inte ARM göra. Det finns egentligen inte så många val om man vill kunna använda längre vektorer i framtiden. Men frågan om det behovet egentligen finns.

Själva designen av avx512 har väl inte ändrats förutom tillägg? Larrabee 1 använde LRBNI och sen bytte man kodning till LRBNI2 för Larrabee 2 korten det var först i steget till Knights Landing som man ändrade till dagens EVEX kodning/avx512 och då passade man på att plocka bort saker som inte fungerade så bra som t.ex. swizzling och la till permute funktioner istället.

SME på apple använder AMX enheten som är en delad resurs per processorkluster och använder väl cache för kommunikation. Ett vettigt mellansteg innan GPU. Olika typer av acceleratorer tror jag mer på än att skala upp vektorlängd till 2048 och det är en av orsakerna till att jag anser att ett smidigt att programmera simd ISA med fast vektorlängd som enklare kan lösa fler problem är att föredra istället för eventuell framtida skalbarhet.

Tittar man på faktiska implementationer och tillgänglighet så har avx512 fungerat bra på Intel serverprocessorer i några generationer nu och det finns "löfte" om avx512 överallt iom avx10.2. AMD har två generationer av bra implementationer även för klientcpus. Tyvärr inte fp16 stöd i Zen 5 vilket hade gjort den avx10.1 kompatibel. Det är först nu man börjar se SVE i arm processorer och det är osäkert hur framtiden för SVE på apple ser ut.

Förutom en framtid där avx10.2 finns överallt så är det lite av en besvikelse. Temtioelva nya ai fp format men inte så mycket annat nytt. Jag hade gärna sett mer funktioner som inte har med fp att göra, pext/pdep (som faktisk arm har), scan/segmented scan, nån form av un-permute/grade..

Som jag skrev från början är både SVE och avx512 bra. Det var din generalisering "AVX-512 done right" som jag reagerade på. Det känns som många trådar här som från början handlar om annat än arm/apple tillslut ändå bara handlar om hur mycket bättre arm/apple är. Att SVE skulle vara "AVX-512 done right" stämmer helt enkelt inte. Vissa saker gör avx512 bättre och andra saker är enklare med SVE. Med SVE kan man eventuellt få skalbarhet i framtiden. Vissa problem blir enklare och resulterar i kompaktare kod eftersom man inte behöver skriva en extra loop för de element på slutet som inte fyller ett helt vektorregister. Tittar man på ett enkelt exempel som axpy så blir det nästan dubbelt så många instruktioner om man använder avx512 och räknar med tailloop. Tittar man på inre loopen är avx512 version en instruktion kortare men förlorar ändå i koddensitet om man jämför bytes med ~30%. En hybrid skulle vara klart bäst. Om avx512 hade instruktioner för att skapa en mask utifrån kvarvarande element i ett loop räknar register och en hopp instruction för icketomt maskregister så skulle man kunna skriva ännu kompaktare kod än SVE. Nu finns det tyvärr inga hybrid ISA utan antingen mer traditionell simd med fast vektorlängd som avx512 eller mer åt vektorprocessor hållet med skalbar längd som ARM/risc-v. Vilket man föredrar har nog mest med den kod man skriver att göra.

M3 vs. M4 resultaten i geekbench är intressanta. SVE/SVE2 optimeringar kan vi helt utesluta eftersom geekbench inte använder de instruktionerna och M4 inte har SVE stöd förutom några funktioner via SSVE (vilket ändå inte skulle ge några fördelar över neon eftersom kärnorna delar AMX enhet). Det intressanta är att hårdvaran bakom SME inte är ny. AMX finns i alla apple M cpuer men man kommer bara åt det via apples egna bibliotek som geekbench inte verkar använda. I en riktig applikation som använder apples bibliotek kanske skillnaden mellan M3 och M4 är betydligt mindre. Andra tester som den för text är väl i princip python 3.9 så där finns den knappast några simd optimeringar. Man ska nog inte försöka läsa in allt för mycket i geekbench resultat.

Ett stort problem med simd ligger hos de som programmerar. De som kodar vill fortsätta skriva enkeltrådad C liknande kod som en kompilator/processor automagiskt försöker klämma ut så mycket parallellitet ur som möjligt. Titta bara på hur trögt det gick när cpu tillverkarna sa att nu kommer processorerna inte öka i hastighet lika mycket varje år men här har ni flera kärnor att använda istället. Samma problem finns med simd. Det är väldigt mycket beräkningskraft som de flesta utvecklare inte alls använder eller inte ens vet hur de ska använda. Många utbildningar lär ut kurser i datastrukturer och algoritmer för en värld som cpu:er lämnade för länge sedan. Mycket kod som skrivs idag är 100-1000x långsammare än vad den skulle kunna vara även fast den är skriven i snabba språk och inte gör korkade saker. Simd är något som kompilatorer överlag är dåliga på och många algoritmer kräver att man skriver koden helt annorlunda. Nu har i princip alla populära programmeringsspråk stöd för simd programmering på gång. Vissa ser mindre användbara ut som C++ förslag t.ex. och andra fungerar redan hyffsat för vissa saker som t.ex. java. Förhoppningsvis ökar simd användandet i framtiden.