Texel 1.07

By Damir Desevac Date 2017-09-30 18:06 Upvotes 1

ist gerade rausgeschiehen. Author hat diese version gerade entwickelt. Hoffe dass Ingo es auf seiner Seite ein Versuch gebe.

Hier sind die Veränderung

Von hier kann man eine spezielle version von Texel laden, die über 800 UCI Parametern haben. Die sind nur für Leute die Spass haben wollen, und um Texel stärker zu machen:

https://www.dropbox.com/sh/v16dye7ww33x7oe/AAAXmGY0phMkB7XlR-vaOxasa/test?preview=texel107tuning.7z

PS: Diese Version ist 35 Elo stärker.

http://talkchess.com/forum/viewtopic.php?t=65339

Version 1.07 of my chess engine Texel is now available for download.

This version contains the following features:
- New parallel search based on lazy SMP and ABDADA.
- Parallel search can use computer clusters.
- Include hashfull information in UCI output.
- UCI option to control whether the transposition table is aged when starting a new search in analysis mode.
- BMI2 compile.
- Support for large pages in Windows.

The following executables are included in the download package:

texel64bmi.exe : For 64-bit Windows 7 or later Intel systems with BMI2, SSE42 and POPCOUNT.
texel64.exe : For 64-bit Windows 7 or later Intel systems with SSE42 and POPCOUNT.
texel64amd.exe : For 64-bit Windows systems with SSE42 and POPCOUNT.
texel64old.exe : For 64-bit Windows systems without SSE42 and POPCOUNT.
texel64cl.exe : Cluster version of texel64.exe. Requires Microsoft MPI to be installed.
texel64 : For 64-bit Linux Intel systems with SSE42 and POPCOUNT.
texel-arm64 : For the Android armv8-a 64-bit architecture.
texel-arm : For the Android armv7-a architecture.
texel32.exe : For 32-bit Windows systems with SSE42 and POPCOUNT.
texel32old.exe : For 32-bit Windows systems without SSE42 and POPCOUNT.

For more Android executables see the "Texel Chess Engine" app in the Google Play Store.

The Linux executable requires a fairly recent 64-bit Linux distribution to run. To compile your own Linux version see the readme.txt file. Running "make texel64" should work in most cases.

Cluster support depends on MPI. See the readme.txt file for more information.

Texel 1.07 is around 35 elo stronger than Texel 1.06 in self play at very fast time controls.

Detailed list of changes:

Search:
- More aggressive LMR in expected CUT nodes.
- Don't use history and killer heuristics for captures.
- Prevent q-search explosion in pathological cases.
- Allow LMR for checking moves with negative SEE value.
- Don't do internal iterative deepening when in check.
- Don't do razoring when in check.
- Don't check extend SEE<0 moves at depth<=3.
- More LMR/LMP reduction if the evaluation score is worse than it was two plies ago. Idea from stockfish.
- More aggressive reverse futility parameters.
- In hash replacement, prefer a deep bound over a shallow exact entry if the depth difference is larger than 3.
- Use history score to control LMR reductions.

Parallel search:
- Parallel search algorithm changed to hybrid lazy SMP / ABDADA.
- Removed code that on NUMA avoids probing the TT at depth 0 for nodes > 0.

Evaluation:
- Removed the piece trade bonus.
- Implemented fortress detection for KQvsKRM+pawns endgames.
- Added endgame correction for KQKNNNN which is generally won by the knights.

Speed:
- Support for large and huge page allocations for the transposition table.
- Added alpha/beta pruning to the SEE function.
- Added support for sliding move generation using the PEXT BMI2 machine code instruction.

Other:
- Include "hashfull" information in UCI output.
- Added UCI option to control whether the transposition table is aged when starting a new search in analysis mode.

By Michael Scheidl Date 2017-10-01 00:04

Thanks! Texel gehört zu den interessantesten Nachwuchsengines, man sehe z.B.

http://chessprogramming.wikispaces.com/Texel%27s+Tuning+Method

(eindrucksvoll aber mir weitgehend unverständlich

).

Jedenfalls wirft TCEC 10 sozusagen seine Schatten voraus, und wir können zeitnah mit weiteren Updates rechnen. Fire und Andykacks hatten wir schon, typisch wären nun u.a. Hackbraten, Nirvana oder Hannibal.

By Benno Hartwig Date 2017-10-01 06:15

"...fast time control (such as 1s+0.08s/move)"
steht da.

Ich finde ja faszinierend, dass bei solchen Zeiten überhaupt sowas wie eine Schachpartie herauskommt!
Aber man kommt so auf statistisch relevante Partienanzahlen.
Mal gucken, ob eine mir verfügbare GUI sowas auch mit sich machen lässt.

Benno

By Klaus Meier Date 2017-10-02 09:48

Benno Hartwig schrieb:

Welchen Sinn macht schon eine hohe Partienanzahl wenn dann wegen kurzer Bedenkzeiten
etwas prodziert wird, das dem Mensch ärgere dich nicht Spiel näher kommt, als dem Schach Spiel.
gähhhn

By Stefan Pohl Date 2017-10-02 14:19 Edited 2017-10-02 14:22

Klaus Meier schrieb:

Benno Hartwig schrieb:

Welchen Sinn macht schon eine hohe Partienanzahl wenn dann wegen kurzer Bedenkzeiten
etwas prodziert wird, das dem Mensch ärgere dich nicht Spiel näher kommt, als dem Schach Spiel.
gähhhn

Das ist doch gar nicht wahr. Man muß das Ganze mal in Relation zu den Brettcomputern sehen. Selbst wenn Texel bei diesem Tempo de facto (abzüglich GUI-Lag und irgendwelcher Initialisierungsprozesse vor Rechenbeginn) 0.05 Sekunden pro Zug gerechnet hat und das nur im singlecore-Betrieb auf einer nicht mal superschnellen CPU, dann sollten bei 2 MN/s immer noch 100.000 Knoten in 0.05 Sekunden durchgerechnet werden.
Ein 8bit-Brettcomputer, wie der Milano oder Polgar rechnet 500 knoten pro Sekunde. Ergo müßten diese Geräte 200 Sekunden rechnen, also mehr als Turnierbedenkzeit von 3 Minuten, um genausoviele Knoten zu schaffen. Und da hat damals niemand behauptet, die Geräte würden eher Mensch ärgere dich nicht spielen als Schach...

By Benno Hartwig Date 2017-10-02 18:03

Für Partien verschiedener Engines finde ich ultrakurze Zeiten dann daneben, wenn ich befürchten muss, dass da ganz andere Quoten als bei längeren Zeiten herauskommen. Ein H6 - SF Duell führt bei so kurzen Zeiten zu einem beinahe-100%-Sieg für Houdini. Und sowas interessiert wohl wirklich niemanden.

Aber wenn ich eine SF-Sourcenänderung testen will, besonders eine der Stellungsbewertung, dann möchte ich schon gern seehhr kurze Partien nutzen, und das ist dann ggf. auch sinnvoll.
Aber 1s + 0,08s finde ich schon frech kurz. Aber es scheint dann ja zu sinnvollen Ergebnissen zu führen.

Benno

By Benno Hartwig Date 2017-10-02 19:44

PS:
Dieses ultrakurze Ergebnis interessiert dann nicht als Selbstzweck, aber es liefert ggf. einen ersten Hinweis, was meine Sourcenänderung ggf. brachte.
Und es motiviert dann ggf. zu einem ausführlicheren Test bei längeren Zeiten.
Benno

By Klaus Meier Date 2017-10-03 09:51

Verstehe schon was ihr meint. Wer knoten zählen gelernt hat, dem bleibt nix anderes übrig, als knoten zählen.

By Benno Hartwig Date 2017-10-03 13:54

Ich verstehe schon, dass du so rein gar nichts verstanden hast.

By Michael Scheidl Date 2017-10-03 17:35

Bei diesem, übrigens von der Junior-Engine stammenden Konzept geht es um die Optimierung der positionellen Bewertungskriterien. Soweit ich verstanden habe - und das ist nicht allzuviel

- wird statistisch untersucht, wie vertrauenswürdig eine positionelle Stellungsbewertung bezüglich des letztendlichen Partieresultats war. Das wiederum führt mich zur Überlegung, daß lange Zeiten = große Rechentiefen hierfür sogar kontrapoduktiv(*) sind. Denn es wird in diesem entwicklungstechnischen Vorgang ja nicht getestet wie schnell die Engine rechnet oder wie stark sie ist, sondern wie treffsicher die positionelle Bewertung ist.

So gesehen frage ich mich ob man das nicht gleich mit einer fixen Rechentiefe von 3 oder 4 durchführen sollte, nur um irgendwelche Banalitäten zu unterbinden...

*) weil sie kombinatorische Erfolge einspeisen die nichts mit Stellungsbewertung zu tun haben

By Peter Martan Date 2017-10-02 19:37

Timo Klaustermeyer hat einen Texel- Cluster installiert:
http://www.talkchess.com/forum/viewtopic.php?topic_view=threads&p=734120&t=65339

By Timo Haupt Date 2017-10-02 20:38

Hallo Peter,

im CCC erscheine ich immer noch unter meinem alten Nachnamen - keine Ahnung, wen ich da anschreiben muss, damit der mal auf 'Haupt' geändert wird...

Aber mit der Clusterversion von Texel ist es wirklich sehr einfach, mit mehreren Computern im lokalen Netzwerk einen kleinen (oder auch größeren) Cluster zu bauen. Microsoft MPI 8.1 kann kostenlos heruntergeladen werden. Alles weitere wird in der Readme.txt erklärt, die in dem Texel-Download enthalten ist. Wichtig wäre noch zu erwähnen, dass das Netzwerk gerne Gigabit-Geschwindigkeit haben sollte (WLAN eher nicht empfohlen, könnte bremsen), bei sehr vielen Rechnern sollte der "Master-Node" (quasi der, auf der die allererste Instanz von Texel gestartet wird) am besten mit 10GBE angebunden sein. Alles weitere machen die Texel-Instanzen unter sich aus. Da die Quellen vorliegen, ist bei der Hashverteilrate u.ä. sicherlich auch noch Optimierungsspielraum vorhanden - da kann man selbst viel ausprobieren, es wird nur schwierig, dann genügend Partien zusammenzubringen, um statistisch vernünftig die Verbesserung bzw. Verschlechterung messen zu können.

Bislang spielt der Cluster aus 5x Dual 6core CPUs schon sehr ordentlich und überflügelt den einzelnen Dual 6core spielend. Aber es liegen noch nicht genügend Partien vor. Trotzdem scheint es so, als wenn Texel auch mit diesen insgesamt 60 Threads noch sehr gut skaliert. Vermutlich haben viele Entwickler jahrelang die Fähigkeit zur Skalierung von einfacheren MP-Ansätzen wie Lazy-SMP und ABDADA unterschätzt. Zwar hat Peter Österlund noch einige weitere Optimierungen vorgenommen, aber letztendlich ist die Parallelisierung nach Texels Vorbild deutlich einfacher umzusetzen als beispielsweise das YoungBrothersWait- oder das DynamicTreeSplitting-Verfahren. Die Stockfish-Leute wissen schon, warum sie von YBW auf Lazy gewechselt haben. Denn um YBW umzusetzen und parameterseitig so zu tunen, dass es genauso gut oder sogar besser skaliert als ein gut implementierter Lazy-Ansatz, ist offensichtlich wesentlich größerer Aufwand nötig.

Ich hoffe wirklich, dass sich einige Engine-Entwickler die Texel-Quellen genau anschauen und einen ähnlichen Cluster-Ansatz in ihre Engine implementieren. Der Aufwand ist natürlich nicht ganz unerheblich, aber der Spielstärkezugewinn kann groß sein, wenn man mehrere Rechner zu einem Cluster vereint. Und man bräuchte dann nicht mehr zwingend die "großen Kisten" (die einfach viel zu viel kosten), sondern könnte sich praktisch aus ein paar Ryzen-Clients einen ähnlich starken Cluster bauen als wenn man einen Server mit Dual oder sogar Quad-Sockel System verwendet, bei dem allein die CPUs mehr kosten als die eingangs erwähnten Clients. U.a. für Fernschach-Spieler sicher nicht ganz uninteressant, beim Antreten der Engines in großen Turnieren ohne Hardware-Beschränkung wie der ICGA-WM sowieso.

Viele Grüße
Timo

By Peter Martan Date 2017-10-02 22:02

Timo Haupt schrieb:

im CCC erscheine ich immer noch unter meinem alten Nachnamen

Uups,Timo, ich hätte es natürlich korrigieren müssen.
Aber die Infos über den Cluster sind interessant, danke.

By Jörg Oster Date 2017-10-03 10:07

Timo Haupt schrieb:

Hallo Peter,

im CCC erscheine ich immer noch unter meinem alten Nachnamen - keine Ahnung, wen ich da anschreiben muss, damit der mal auf 'Haupt' geändert wird...

Hallo Timo,

schau mal hier: http://talkchess.com/forum/viewtopic.php?t=30086
Ansonsten würde ich einfach eine PM an Harvey Williamson schicken,
welcher in solchen Angelegenheiten auch immer hilfsbereit ist.

Gruß, Jörg.