GPU: er är bättre vid vissa typer av beräkningar, t.ex. generera bitcoins och utföra klimatsimuleringar.
Skulle schackmotorer gynna om de beräknade med GPU: er istället för CPU: er?
Kanske kan någon kunnig person belysa skillnaderna mellan de två och upplysa oss om om GPU: er är (o) lämpliga för den typ av beräkningar som schackmotorer utför.
EDIT:►
Få andra punkter som tas upp i http://rybkaforum.net/cgi-bin/rybkaforum/topic_show.pl?tid=32317.
Original :
@ Maxwell86 har redan gett utmärkta länkar och resurser. Var uppmärksam på zeta-schackmotorn. Det är en GPU-schackmotor. Tyvärr har inte GPU visat sig vara användbar i schackprogrammering. Faktum är att zeta-schackmotorprojektet gick absolut ingenstans.
GPU fungerar mycket bra på flytande beräkningar och algoritmer som kan parallelliseras. Detta kräver oberoende. Men om vi tittar på ett typiskt min-max (eller alfa-beta) träd (används av varje schackmotor)
Den högra grenen beror på den vänstra grenen. I synnerhet, om vi kan få en cutoff (fail-high), skulle vi inte ens behöva söka i de återstående noderna. Tyvärr är detta inte något som en GPU kan göra effektivt. Det är möjligt att skriva ett GPU-program för alfa-beta, men GPU-trådarna (känd som kärnor) måste pausas för att vänta. Till skillnad från en CPU kan en GPU-kennel inte bara byta till något annat (en process som kallas tråd-switch eller till och med process-switch).
Vår befintliga algoritm och motorkunskap härleddes för CPU-världen. Hela algoritmen måste undersökas om för GPU. Tyvärr finns det inte mycket intresse och forskning om det.
Jag har ingen erfarenhet av GPU-programmering, men vanligtvis är GPU: er mycket effektiva när det gäller att utföra enkla kommandon parallellt. Tydligen är detta inte fallet för sökträdet som används för schackmotorer. Därför förlorar GPU sin beräkningsfördel jämfört med en CPU.
Detta är naturligtvis det nuvarande tillståndet för GPU-programmering för schackmotorer, men GPU-programmering är relativt nytt, så kanske de hittar lösningar för nuvarande problem i framtiden.
Här är ett par intressanta länkar, särskilt bloggen om att implementera en schackmotor för GPU är ganska insiktsfull.
LC0-projektet (Leela Chess Zero), en öppen källkodsanpassning av AlphaZero för schack, visar fördelarna med gpus, floating point-prestanda och minnesbandbredd som används i stora neurala nätverk.
Jag avslutade min nuvarande körning på Zeta v099a, min experimentella GPU-schackmotor.
https://github.com/smatovic/Zeta
Den faktiska slutsatsen av den nuvarande iterationen är att en enkel motor, motstått schackprogrammeringstekniker, kan överföras till OpenCL för att köra på en GPU, men det skulle kräva mer ansträngningar för att göra motorn konkurrenskraftig när det gäller beräknade noder per sekund (hastighet ), heuristik (expertkunskap) och skalning (parallell sökalgoritm).
Datorschack, som ett ämne inom datavetenskap, utvecklades under årtionden, med början på 40- och 50-talet, och nådde en topp 1997 med matchen DeepBlue vs. Kapsarow. Numera är schackmotorer avstämda genom att spela tusentals och tusentals spel, så det är två olika uppgifter att få en schackmotor som körs på GPUn och att få en konkurrenskraftig schackmotor som körs på GPUn.
Jag har lite erfarenhet av CUDA och schackprogrammering (inte motorprogrammering). Denna fråga kom också till mig många gånger. Här är min åsikt, jag har aldrig studerat detta.
Nåväl, först är det nästan säkert att det med nuvarande design av schackmotorer är omöjligt. Annars skulle någon helt enkelt göra det.
Om du skulle kunna använda den i helt ny design är det en större fråga. Det finns inga problem med heltalsåtgärder, men det finns helt klart en enorm sak att du måste köra primitiv kod utan någon seriös förgrening på många enheter.
Enligt min mening bör alla trädberäkningar köras på CPU.
Men jag kan föreställa mig (jag säger inte att det är möjligt) några partiell utvärderingsfunktioner som bara gör så mycket utvärderingar på positioner som möjligt, för att ge CPU mer tid, för att hjälpa honom att bygga trädet i en bättre sätt, låt oss säga att en sådan funktion kan beräkna hur seriös beräkning ska göras på varje position.
Du kan beräkna antalet attackerade rutor, bitar attackerade, eldkraft runt kungar och i vissa underregioner ombord, bonde struktur relaterade saker kan du förmodligen göra GPU-optimerad kod för dessa. Du kan antagligen få en hel del användbar information gratis (ingen CPU-tid, ingen CPU väntar), men du måste vara riktigt geni för att använda full hästkrafter av moderna GPU för sådana små saker.
Det är förmodligen inte särskilt intressant att göra för att skapa helt ny design av motorer för att få låt oss säga 30% extra hastighet. Och för att låta oss säga 20x hastighet på toppmoderna GPU: er måste du göra utvärderingsfunktioner riktigt främmande.
Och det sista på det jag ser är ett problem. Du kan köra en kod på CPU med inte så många tankar, men i CPU + GPU-scenariot måste du hantera riktigt olika förhållanden mellan CPU och GPU. hastigheter och kärnantal. Du behöver annan kod för 16-kärnkluster med svag GPU än på långsam CPU med supersnabb GPU för att använda alla hårdvarufunktioner. Att jämföra CPU mot GPU och sedan köra mer kod på den snabbare maskinen skulle vara önskvärt. Men ändå tror jag att du inte kommer nära att mata 3000 kärnor bara med utvärderingsfunktion (er).
Redigera: Bara för att göra saker tydliga skulle CPU regelbundet skicka GPU-arrays av positioner för att göra partiella utvärderingar . Kanske var det inte klart från vad jag skrev.
Många problem för att detta ska fungera.
Jag ser bara fördelar med att använda en GPU-baserad schackmotor och ser inga allvarliga problem att göra det. Kanske har du problem att försöka använda ett schackprogram, vet inte mycket om de andra. Jag börjar bara skriva ett schackprogram från första raden, som ett andra CUDA-baserat program efter att jag gjort några första programmeringstester på CUDA utan någon specifik känsla. Snart kan jag göra några första prestandatester och testspel mot andra motorer. Kanske under nästa vecka. Jag börjar bara skapa det men jag är redan nära avsluta det och de flesta funktioner är redan färdiga.