Universalprocessorn Tachyum Prodigy snabbare än Nvidia- och Intel-kretsar

"Tror du Tachyum lyckas leverera en produkt som är snabbare, billigare, mer energisnål än allt på marknaden och dessutom kan köra kod anpassad för alla befintliga instruktionsuppsättningar?"

Vete fan, låter för bra för att vara sant.

Calling @Yoshman, detta behöver lite insikt känner jag

Sååå... What's the catch?

Låter som om Euclideon hade designat en processor.

Tachyum låter som nåt material i Star Trek-universumet.

Det låter ju mest som ett aprilskämt.

Om de ens skulle komma nära det man påstår tycker jag existerande CPU-designers direkt övergår att vika dumstrutar...

Det gick att lösa, även om det gjorde kompilatorn väldigt komplex (vilket i sig inte är ett jätteproblem). Tankevurpan med Itanium var primärt att man bara löste den del av OoOE som statisk analys kan hitta. Finns en del sådant, men allt eftersom gapet mellan hur mycket data CPU-kärnan kan tugga i sig kontra hur snabbt (latens) man kan få in erforderlig data till beräkningsenheterna blev dynamisk analys allt mer kritisk.

Dynamisk analys är saker som att lära sig hur aktuell arbetslast uppför sig, t.ex. branch-prediction och mönster i vilka adresser som läses (att hantera skrivning är långt enklare ur ett latensperspektiv, så är just inläsning av data som är svårt). Var ju exakt dessa delar man hoppades kunna undvika implementera i kisel med Itanium, men i de sista generationerna hade man börjat stoppa in sådana delar vilket rätt mycket gjorde grundidén med EPIC-designen DoA (Explicitly Parallel Instruction Computing).

VLIW är närbesläktad med EPIC, båda fungerar lysande på vissa nischade fall men är ingen optimal lösning för en generell CPU. Eller så har man löst alla problem i Prodigy, i så fall blir det riktigt spännande att förstå hur! Men känns inte så sannolikt...

"Tricket" i ARM64 (och RISC-V) som får dessa att möjliggöra extremt "breda" CPU-designer är ju att förenkla analysen av den dynamiska analysen så långt som möjligt genom att göra majoriteten av instruktionerna helt oberoende av saker som globala flaggor och liknande. Det ser ju ut att fungera, vilket skulle göra Prodigy än mer fantastisk om den effektivt kan köra både x86 och ARM64 instruktioner då de skiljer sig på ett par viktiga fundamentala punkter.

Fast kikar man i pressmeddelanden säger man väl ändå inte att det handlar om en CPU för allt möjligt, man verkar rikta in sig på ett par specifika HPC-laster

"Tachyum's Prodigy can run HPC applications, convolution AI, explainable AI, general AI, bio AI and spiking neural networks, as well as normal data center workloads on a single homogeneous processor platform with its simple programming model."

Låter mer som detta är en GPU/NPU som kan klara sig helt utan en "vanlig" CPU. Är rätt mycket så världens snabbaste superdator, Fugaku, fungerar. Den kör i grunden ARM64 kod, men designmässigt är CPUn mer lik en GPU än en traditionell CPU. Fördelen med en sådan design är samma som för GPGPU på iGPUer: det är minimal kostnad (den är ju noll för Fugaku och Prodigy) att växla mellan CPU- och GPU-delen av kretsen.

Om så är fallet är det kanske inte en uppenbar scam, fast då handlar det inte heller om en CPU som kommer ersätta det vi idag kör i våra mobiler och desktop-datorer.

Antar att de pratar om data locality på något sätt. Upp till 90% av energiåtgången i moderna chip är ju relaterat till bussar och minneshantering för att det helt enkelt kostar så mycket energi att överföra information i de hastigheter som krävs

Wikipedia säger 40-50% vill jag minnas för FX!32 1.0 och spekuleras upp till 70% med senare versioner.

Jag installerade Windows NT 4.0 på min Alpha för några veckor sedan, kört Gentoo Linux sedan 2006 med en ominstallation runt 2014 men var aldrig stabil cid hård CPU last så har gått igenom hårdvaran mm (nya caps, ny kylning, rengjort alla kontakter, bytt ut en mistänkt kass CPU mm) och testande nu NT för att se hur den beter sig.

Men FX!32 ger ungefär 30-50% av native prestanda i NT 4.0 skulle jag säga med FX!32 Version 1.5 så några 70% har jag aldrig sett när jag testat Native port VS binärt översatt av FX!32.

Rent generellt fungerar GUI program bättre, börjar man tala om spel så är det mest komplexa jag fått runt prboom (doom port) och Sim City 2000.

Nu är utbudet av mjukvara EXTREMT tafatt till NT och Alpha och det mesta har gått Cyber space döden till mötes så man får gräva runt på ftp mirrors, Internet Archive mm för att hitta mjukvara att köra.

Jag har testat PRBOOM, en DOOM1/2 motor som finns native och som även fungerar under fx!32 och det är väl 1/3 CPU use med native.

Väldigt mycket fungerar inte genom FX!32 heller men det som fungerar är lite hit and miss.

Winrar fungerar väldigt bra och snabb faktiskt jämfört med native program som inte verkar lika finslipade men då jämför man ju inte äpplen och päron.

Kör även FTP Explorer som är ett x86 program då det har mer funktioner och är snabbt när FX!32 genererat binärer för det.

Men vist är FX!32 rätt coolt och imponerande och det var en del av Windows 2000 beta för Alpha så var i teorin bara att tuta och köra x86 binärer.

Emulerade Wintune 97 åt kompisen som samlar scores so its all for science!

Har med 2 Alpha system, den röda och gröna grafen till vänster.
Det är samma system men en rundan är den uppgraderad från 500Mhz till 600Mhz CPU och FX!32 har även gjort en binär översättning av Wintune 97, verkade först inte fungera men ja datorn stog på över natten så blev det lite fart på programet verkar det som.

Ofta går översättningen väldigt fort (någon minut) dock tar andra program lite tid och vissa kan inte översättas har jag märkt. Har ett som är fast på 62% efter flera veckor nu.

Men man kan ju se den röda stapeln med systemet i 600Mhz med Wintue97 binärt översatt jämfört med systemet i 500Mhz där den brute forsar emulering av x86.

Så binärt översatt är Alpha rätt snabb även med dagens mått skulle jag säga, många vanliga GUI program som Winrar och FTP Explorer är rappa som på en native P2/P3 PC i motsvarande frekvens så inget känns slött.

Spel och exotiska program fallerar ofta dock och om dom startar är plågsamt långsamma.

Så jag föredrar att kompilera om program om källkod finns, har så lång kompilerat Quake 2 3.21 och Quake1 1.09 SDL och några Kronos OpenGL demos och sånt. En del har redan native support men det ger lite mer prestanda att gå från VC4++ till VC6++ och sedan finns det lite buggfixar i senare Quake 2 sourcen som fixar artefakter så var väl lönt att kompilera om med Visual Studio 6.