[QUOTE=Yoshman;12938793]Är det verkligen ett kap? Antar att 30K betyder runt $3000, jämför vi då Tesla K20 med Xeon Phi så kostar den senare ~$2000 och har ungefär samma teoretiska flyttalsprestanda för DP (double precision), vilket är det jag utgår från att man använder i de flesta vetenskapliga beräkningar, i marknadsföringen tenderar man dock lista SP (single precision) då det värdet är högre och SP räcker oftast i spel. Tesla har dock ~3TFLOPS SP prestanda medan Xeon Phi "bara" har ~2TFLOPS SP.
Och då har vi bara tittat på den teoretiska prestandan. Vilket system tror du är lättast att programmera?
Ett system bestående av runt 2500 "stream processors" där man hela tiden måste mata systemet från en "vanlig" CPU
Ett system bestående av 60st x86-kompatibla CPU-kärnor som, om man så önskar, kan köra sitt eget OS och hantera sin egen schemaläggning av problem
Xeon Phi är precis som Tesla ett PCIe kort, men den stora skillnaden är att Xeon Phi faktiskt själv kan köra ett OS (Linux stöds officiellt) vilket definitivt förenklar designen på de program som ska köra på systemet. I system som är helt beroende av en koordinerande CPU som i detta fall sitter på andra sidan en PCIe buss kommer det vara extremt svårt att nå den teoretiska prestandan i praktiken, jämför det med flyttalsberäkningar som utförs direkt på CPUn med SSE/AVX där det definitivt är praktiskt möjligt att nå >95% av den teoretiska prestandan då kostnaden för kommunikation är i praktiken noll.[/QUOTE]
[QUOTE=Yoshman;12939065]Många långsamma kärnor är alltid MYCKET svårare att hantera än färre snabba kärnor, så skulle vara väldigt intressant att veta hur nära den teoretiskt prestandan man faktiskt når med ett typiskt CUDA-program. Enda fördelen med många svaga kärnor är att man normalt sett kan nå en betydligt mycket högre aggregerad prestanda med många svaga kärnor jämfört med några få starka kärnor givet en viss ström- och transistor-budget. I detta fall så verkar skillnaden väl liten för att det ska vara värt huvudvärken.
Framförallt så måste CUDA vara ett rejält gissel då det är väldigt likt C medan Fortran fortfarande är väldigt populärt då det är en mycket bättre match vid bl.a. matris-beräkningar jämfört med C. Till Xeon Phi, som i praktiken kör något som är väldigt likt AVX, finns ju redan Fortran-kompilatorer (Intel har en egen sådan). Sedan har Intels C++ kompilator (ICC) har stöd för Xeon Phi + att det finns ett tillägg som kallas Cilk+ som ingår i ICC, Cilk+ lägger till några saker till C/C++ som gör det möjligt för programmeraren att uttrycka vektorer och matris som språk-primitiver (direkt kopierat från Fortran) som i sin tur gör det trivialt för kompilatorn att inse hur den kan köra den koden med SIMD-instruktioner.
Tesla har ju en till svaghet jämfört med Xeon Phi i det att en GPU kan i praktiken bara hantera problem som är data-parallella (vilket t.ex. matris-beräkningar är och det är den form av parallellism som SSE/AVX/NEON/AltiVec är designade för). Men det är bara en form av parallellism som finns, den andra är instruktions-parallella system som är den form av parallellism som de flesta kanske tänker på då det är vad man har i multitrådade program som kör på "vanliga" CPU:er. Skulle tro att Xeon Phi får rejält med stryk av en "vanlig" CPU på instruktions-parallella problem, men det är i alla fall möjligt att hantera sådant med en rimlig effektivitet.[/QUOTE]
[QUOTE=Yoshman;12939138]Men tror du inte det är lättare att hitta programmerare som kan hantera relativt gamla och etablerade språk som C och Fortran än att hitta programmerare som kan hantera CUDA eller OpenCL? Fördelen med att skriva för etablerade språk är ju att man inte blir låst till en specifik leverantör på samma sätt som om man skriver allt för CUDA. Nu tror jag inte det är ett problem för superdatorer, då man tydligen är ganska "van" i de kretsarna att få skriva om rätt stora delar av sin programvara för att hantera de ganska radikala HW-designerna man jobbar med. Men för lite mer "vanlig" användning blir det en väldigt stor kostnad att vara tvungen att skriva om stora delar av systemet i det läget att man vill/måste byta HW-leveratör.
Vad det gäller Fortran blev jag själv ganska överraskad över hur mycket det används inom vissa specifika områden. Framförallt hade jag lite svårt att se varför Intel lägger ner rätt mycket resurser på sin Fortran-kompilator, men inser nu att det just inom vissa typer av beräkningsintensiva områden som Fortran fortfarande är det bästa (mest effektiva) språk man har just p.g.a. att det är lätt att extrahera data-parallellism ur sådan kod.[/QUOTE]
Som jag har förstått det så är de största problemen inom HPC energibudgeten. Att flytta data inom en normal CPU är mycket dyrare än att göra det samma på en GPU. När man sedan har med saker som spekulativ exekvering och liknande saker så blir CPUn vansinnigt dyr i drift (energi per operation).
Parallellisering verkar vara den väg framåt som finns på prestandaplanet. I och för sig så fungerar säkert saker som Xeon Phi bra när det gäller att snabba på vissa saker i en arbetsstation, men den kommer inte fungera i större skala. Dessutom så är det väl inte vettigt att välja bort prestanda för att vissa utvecklare har svårt att tänka parallellt? Det behövs helt klart bättre verktyg för att få området att flyta på, men också att man är villig att lära sig tänka på ett nytt sätt.
När det gäller att inte låsa sig till hårdvaruleverantör så löser C++ AMP en del problem (mot en viss prestanda förlust har jag för mig).
Bill Dally höll årets Celsiusföreläsning om det här kortet och dess släktingar. Han pratade också en del om vilka nya verktyg som behövs för att kunna flytta många av de tunga CPU-funktionerna från hårdvara till mjukvara. Mycket intressant och går att se på UUs hemsida.
