Auf den Weg zum stärksten Schach-Programm der Welt

Patrick22

Lt. Commander
Mitglied seit
14.03.2002
Beiträge
132
Renomée
2
Standort
Cuxhaven
Zum stärksten Schach-Programm der Welt durch Distributed Computing.

Zur Zeit wird das Open Source Schach Programm Stockfish sehr erfolgreich durch verteiltes Rechnen weiterentwickelt.
Die Weiterentwicklung des Programms steht jeden zur Verfügung und es ist sogar auf Android-Handys kostenlos verfügbar.

Stockfish ist somit auf dem besten Weg das stärkste Schachprogramm (Engine) der Welt zu werden, es fehlt lediglich noch an weiterer Rechenpower um das Projekt schneller voranzutreiben, denn zur Zeit beteiligen sich nur ca. 10-30 Leute Weltweit.

Gruß
Patrick
 
Es gibt viele Klicks, aber bis jetzt keiner der Interesse hat mitzumachen.
Falls doch jemand mitmachen möchte, versuche ich es so einfach wie möglich zu machen und habe dafür eine Anleitung auf deutsch für Windows Nutzer geschrieben:

Entweder über die Links der Webseite Stockfish.org -> "Get Involved" -> "add your computer to the pool" aufrufen
oder über diesen direktLink:
https://github.com/glinscott/fishtest/blob/master/README.md
die Englisch Anleitungsseite für Linux und Windows aufrufen.

Und dann geht es für Windows so:

1.
Python 2.7.x for x86 downloaden , über den Link

http://www.python.org/ftp/python/2.7.4/python-2.7.4.msi

ausführen und mehrmals "Next" klicken bis es installiert ist.
( Ausführlich geschrieben : 1. Für alle User installieren 2. Auf wunsch Verzeichnis auswählen 3. mit allen Features installieren 4. Okay klicken, fertig)

2.
Dann das Hauptprogramm "fishtest-master" runterladen über den Link

https://github.com/glinscott/fishtest/archive/master.zip

und entpacken, z.b. in "c:\fishtest-master\worker\"
Dann sich über den Link

http://tests.stockfishchess.org/signup

anmelden, einfach Username/Password/ E-Mail eintragen und sofort ist man angemeldet.

4.
Dann das Hauptprogramm "fishtest-master" starten:

Dazu im Unterordner "worker" eine Kommandozeile (*) öffnen, z.B. in "c:\fishtest-master\worker\"
dann eingeben:

'c:\Python27\python.exe worker.py --concurrency <cores> <username> <password>'

Erklärung:
a) "c:\Python27" ist das Verzeichnis in dem Python installiert wurde.
b) --concurrency <cores> ist die Anzahl Kerne die zur Verfügung gestellt werden ( ohne Hyperthreaded Kerne), ein Kern muss für das Betriebssystem übrig gelassen werden.
Habt ihr 2 Kerne gebt ihr --concurrency 1 ein
Habt ihr 4 Kerne gebt ihr --concurrency 3 ein
Habt ihr 6 Kerne gebt ihr --concurrency 5 ein
Habt ihr 8 Kerne gebt ihr --concurrency 7 ein
Habt ihr 12 Kerne gebt ihr --concurrency 11 ein
Für i5 und i7 CPUs wäre das also "--concurrency 3"
c) <username> <password> , das Eintragen was Ihr bei der Anmeldung angegeben habt.

Mit allen Eintragungen und sieht es also z.B. so aus:
c:\Python27\python.exe worker.py --concurrency 3 test 123456

Enter drücken und los geht's.

(*) So startet man die Kommandozeile in einem bestimmten Verzeichnis z.B. in "c:\fishtest-master\worker\"
http://www.tippscout.de/windows-7-kommandozeile-in-bestimmtem-verzeichnis-starten_tipp_4369.html

---------- Beitrag hinzugefügt um 01:10 ---------- Vorheriger Beitrag um 01:05 ----------

Und wenn Ihr das alles gemacht habt sieht die Ausgabe des laufenden Programm so aus:

C:\more\fishtest-master\worker>C:\python27\python.exe worker.py --concurrency 1
test 123456
Worker version 38 connecting to http://tests.stockfishchess.org:80
Downloaded stockfish.exe from http://fishtest.s3.amazonaws.com/binaries/75f8106d
c57d862c072f8b8270c9388a526620a0_windows_64
Downloaded base.exe from http://fishtest.s3.amazonaws.com/binaries/f45eee318bbe0
fe1465bda80bf62bc8b3bc7d07c_windows_64
Downloading 8moves_GM.pgn ...
Downloading cutechess-cli-win.zip ...
Verifying signature of stockfish.exe ...
Verifying signature of base.exe ...
CPU factor : 1.253201 - tc adjusted to 18.80+0.05
Running null2 vs fmaster
C:\more\fishtest-master\worker\testing\cutechess-cli.exe -repeat -rounds 890 -to
urnament gauntlet -pgnout results.pgn -resign movecount=3 score=400 -draw movenu
mber=34 movecount=8 score=20 -concurrency 1 -openings file=8moves_GM.pgn format=
pgn order=random plies=16 -engine name=stockfish cmd=stockfish option.Hash=128 o
ption.OwnBook=false -engine name=base cmd=base option.Hash=128 option.OwnBook=fa
lse -each proto=uci option.Threads=1 tc=18.80+0.05
Indexing opening suite...
Started game 1 of 890 (stockfish vs base)
Finished game 1 (stockfish vs base): 1/2-1/2 {Draw by 3-fold repetition}
Score of stockfish vs base: 0 - 0 - 1 [0.500] 1
Started game 2 of 890 (base vs stockfish)
Finished game 2 (base vs stockfish): 1/2-1/2 {Draw by adjudication}
Score of stockfish vs base: 0 - 0 - 2 [0.500] 2
Started game 3 of 890 (stockfish vs base)
Finished game 3 (stockfish vs base): 1-0 {White wins by adjudication}
Score of stockfish vs base: 1 - 0 - 2 [0.667] 3
Started game 4 of 890 (base vs stockfish)

usw.

die Ergebnisse könnt Ihr dann live auf dieser Seite verfolgen:
http://tests.stockfishchess.org/tests

PS.: die Anzahl Kerne, die fürs Schach zur Verfügung gestellt werden, dürfen nicht von anderen Programmen belastet werden, nicht mal vom Betriebssystem, deswegen muss auch immer ein Kern frei bleiben.
 
Das PS solltest du als oberste Zeile und ganz Fett posten. Denn alleine das ist für viele ein absolutes KO-Kriterium. Ein testender PC kann nicht produktiv verwendet werden; starte ich mal ein Programm welches mehr als die Leistung eines Cores anfordert was passiert dann? Ich möchte doch meinen PC nicht künstlich beim Arbeiten auf einen Core einbremsen. Das Programm scheint sehr sensibel zu sein was benchen angeht. Dann sollte man es aber gleich richtig machen und nur auf absoluten bare-metal Installationen nutzen die ausschließlich dem Testen dienen.

Abgesehen davon ist die Installation schon arg kompliziert und nicht für Gelegenheits-DCler zu empfehlen. Ich wünsche dir aber dennoch viel Glück bei der Suche nach Testern!
 
Zuletzt bearbeitet:
Wenn man das Projekt in BOINC heben würde, hätte man sicher schlagartig viele DCler dabei. Zumal es dann auch Punkte gäbe. Mit der manuellen python Installation wird man nicht viele Leute finden. Sieht man ja bei test4theory, dass vielen schon die zusätzliche vbox installation zu viel ist. Trotzdem ist die Anleitung eine gute Sache. *great*
 
starte ich mal ein Programm welches mehr als die Leistung eines Cores anfordert was passiert dann?


Das Ergebnis der Schachpartie, die im dem Moment der Belastung gespielt wird, könnte verfälscht werden.

Insgesamt müssen pro neuer Version des Schachprogrammes etwa 2.000-20.000 Partien gegen die alte Version gespielt werden (pro Minute und Kern ca. 2 Partien)bis das Ergebnis feststeht, ob die neue Version wirklich eine Verbesserung des Programms darstellt.
Nur wenn die neue Version gegen die alte gewinnt, wird sie übernommen und das Schachprogramm dadurch stärker.

Auch Programmierer können sich daran beteiligen, das Open Source-Programm zu verbessern.
Insgesamt reichen zur Zeit ca. 10 Schachprogrammierer Weltweit Ihre Verbesserungsvorschläge ein, die dann zur Prüfung durch das Rechennetzwerk gejagt werden.
 
Zuletzt bearbeitet:
Genau das sehe ich kritisch. Eine Partie ist in rund 30 Sekunden durch (und ich gehe davon aus es handelt sich um 2000 - 20000 verschiedene Partien).

Nun kann es passieren dass das OS in einigen Partien die vom Test genutzten CPU-Cores belastet, und damit das Ergebnis verfälscht. Ebenso der Einfluss von anderen Prozessen auf den CPU-Cache, was dann wieder zu geringeren Durchsätzen der Schachengine führt.

Diesen Einfluss kann man minimieren indem jede Partie statistisch relevant mehrfach durchgerechnet wird. Aus dem Bauch heraus empfehle ich 5-10 Durchläufe, wovon im Anschluss die schlechteste und die Beste Zeit pro Partie gestrichen und aus dem Rest der Mittelwert gebildet wird.

Oder geht es hier bei den Tests AUSSCHLIESSLICH um die spielerische Stärke der Engine ohne Beachtung der Zeiteffizienz?
 
Nun kann es passieren dass das OS in einigen Partien die vom Test genutzten CPU-Cores belastet, und damit das Ergebnis verfälscht.

Wenn das OS Leistung braucht, nimmt es sich automatisch den im Leerlauf befindlichen freien Kern.

Diesen Einfluss kann man minimieren indem jede Partie statistisch relevant mehrfach durchgerechnet wird.

Bei dem Test geht es nicht um den Zeitverbrauch, sondern welche Version die Partie gewinnt. Eine Schachpartie wiederholt sich auch niemals, denn es kommen jedesmal andere Eröffnungszüge aufs Brett und insgesamt gibt es mehr mögliche verschiedene Partieverläufe als Atome im Universum.

Das Endergebniss sieht dann z.B. so aus ( aus einem realen Match hier http://tests.stockfishchess.org/tests entnommen)
19-08-13 tk Multiple-Not-Improving
Erklärung:
Test vom 19-08-13 , Kürzel des Programmierers: tk , Name des Patches (der Programmveränderung): Multiple-Not-Improving
Ergebnis
Total: 46746 W: 9682 L: 9443 D: 27621
Erklärung:
"Total 46746 " : Gesamtzahl der gespielten Partien
"W: 9682" : Die neue Version hat davon 9682 Partien gewonnen.
" L: 9443 " : Die neue Version hat davon 9443 Partien verloren.
"D: 27621" : Unentschieden endeten 27621 Partien.

Insgesamt wurde dadurch festgestellt, das die neue Version eine Verbesserung ist, was auch durch die grün hinterlegte Farbe angezeigt wird.
 
Danke für deine Erklärung, da habe ich dann zu sehr alles hinterfragt. Es werden also quasi-zufällige Partien mit unterschiedlichen Seeds (Eröffnungszüge) gespielt. Spielt dann quasi die alte Version gegen die neue?

In deinem ersten Punkt muss ich dir widersprechen, denn welcher Prozess auf welchen Kern zugreifen darf regelt der Scheduler des OS. Und selbst bei einem Realtime-Prozess, den man im Taskmanager auf bestimmte Kerne festnagelt gibt es immer noch das Problem dass der Cache oft von mehreren Cores gleichzeitig genutzt wird.

Wenn es aber wie in deinem zweiten Punkt erwähnt ausschließlich um die Überlegenheit einer Version gegenüber einer anderen geht und keine zeitkritischen Aktionen laufen: warum benötigt man dann dennoch exklusive Prozessorkerne? Läuft der Prozess mit Priorität REALTIME oder woran liegt es?
 
Das liegt daran, das die Belastung ungleichmäßig verteilt sein könnte, z.B. gerade dann wenn Schwarz am Zug ist gibt es eine Belastung, der Zug wird dadurch schlecht und die Partie geht dadurch verloren und verfälscht die Statistik.
 
Also gibt es doch zeitkritische Methoden / Aktionen / Züge. Aber ich denke auch wenn z.B. der Cache dazu führt dass die Züge von "alt" immer schlecht werden liegt dies im Sinne der Entwickler: dann ist die alte Implementierung schlechter als die neue.

Ich hoffe, dass diese Tests mit einem Quorum durchgeführt werden - also auf unterschiedlichen Systemen von verschiedenen Testern. Denn sonst müsste man das Testszenario tatsächlich viel stringenter gestalten (bare-metal Installation, keine Userintervention am testenden System, keine Systemprozesse (Indizierung, Taskplaner, ....)).

Ansonsten kann der Test immer nur als Tendenz gesehen werden.
 
Also gibt es doch zeitkritische Methoden / Aktionen / Züge. Aber ich denke auch wenn z.B. der Cache dazu führt

Der Cache auf den CPUs spielt nur eine untergeordnete Rolle, da die Programme da sehr bescheiden sind. Die Schach-Programme selbst haben auch nur eine Größe von ca. 100 KB (=0,1 MByte).

Diese Art zu testen ist schon sehr ausgereift und wird schon seit vielen Jahren so gehandhabt. Nur das die Entwickler früher meist nur 1-2 Computer dafür zur Verfügung hatten. Die kommerziellen Anbieter arbeiten immerhin mit mehreren Computern gleichzeitig, aber wenn sich an diesem Open Source Projekt genügend freiwillige beteiligen kann sich das Open Source Schachprogramm Stockfish gegenüber den kommerziellen Anbietern durchsetzen und schon sehr bald das stärkste Schachprogramm der Welt werden.
Und das für jeden frei und kostenlos überall verfügbar, sogar auf dem Handy. Finde ich eine tolle Sache, besonders wenn man dann sagen kann, das man ein Teil dieses Projektes war..
 
Zu deinem ersten Punkt: gerade wenn das Programm da sehr bescheiden ist, ist es klein genug in den L1 oder L2 Cache zu passen, wenn es dort laufend von anderen Prozessen verdrängt wird verfälscht das die Performance massiv! Dann gibts noch die Sprungvorhersagen, Cache-Pipelines, ....

Zum zweiten Punkt: So wie du es beschreibst, ist der Testvorgang am ehesten mit einem genetischen Algorithmus zu vergleichen, mit den von mir beschriebenen Fehlerquellen. Gut, die mögen sich vielleicht statistisch herausmitteln.

DIe Projektidee an sich finde ich natürlich spannend, keine Frage. Mit vergleichsweise wenig Ressourcen kann hier ein enormer Fortschritt erzielt werden im Gegensatz zu vielen anderen DC-Projekten.
 
Nun kann es passieren dass das OS in einigen Partien die vom Test genutzten CPU-Cores belastet, und damit das Ergebnis verfälscht.

Sorry, da habe ich mich vielleicht falsch ausgedrückt.
Das Schachprogramm muss nicht nicht einen einzigen Kern exklusiv für sich haben, sondern es gehen auch zwei zu 50% oder 3 zu 33%, wichtig ist nur das am Ende ca. 100% raus kommen. Daher ist die Belastung des OS (oder andere geringe Belastungen) kein Problem.
 
Zurück
Oben Unten