Fallstudie zur Leistung von Stockfish 16 auf Multi-Core-Systemen

By Olaf Jenkner Date 2024-02-16 19:37 Upvotes 1

Dieter Brandhorst schrieb:

Während Multi-Core-Systeme zweifellos ihre Vorteile in bestimmten Anwendungen und Szenarien haben, legen die Ergebnisse nahe, dass für den spezifischen Zweck des Vergleichs und der Bewertung von Schachengines der Single-Core-Modus vorzuziehen ist. Dies ermöglicht eine präzisere und zuverlässigere Beurteilung der Engine-Leistung unter kontrollierten und vergleichbaren Bedingungen.
VG Dieter Brandhorst

Damit fällt aber in ganz wesentlicher Punkt unter den Tisch. Verschiedene Programme kommen unterschiedlich gut mit der Parallelisierung zurecht.
Kein Programm ist mit 20 Kernen 20 mal schneller als im Single-Core-Modus. Manche sind vielleicht 10 mal schneller, andere 15 mal.

By Peter Martan Date 2024-02-16 20:09 Edited 2024-02-16 20:12

Und dann kommt noch dazu, dass time to solution halt nun mal weder bei verschiedenen Programmen noch bei ein- und demselben Programm irgendeine anders als durch Versuch und Statistik und Stellung für Stellung feststellbare Beziehung zu benchmarks wie time to depth und n/sec hat, die man ansonsten noch als irgendwie einfacher berechenbare und testbare Parameter der "Parallelisierung" heranziehen kann, und die zwar auch stellungs-abhängig sind aber halt viel weniger und mit viel weniger Streuung

By Dieter Brandhorst Date 2024-02-16 20:14

Zitat:

Verschiedene Programme kommen unterschiedlich gut mit der Parallelisierung zurecht.Verschiedene Programme kommen unterschiedlich gut mit der Parallelisierung zurecht.

Das ist tatsächlich ein zentraler Punkt in der Bewertung und im Vergleich von Schachengines sowie allgemein in der Beurteilung von Software, die für Multi-Core-Systeme optimiert ist.
Anstatt sich aber nur auf die absolute Leistung in Multi-Core-Systemen zu konzentrieren, sollte man dann Skalierbarkeitsmetriken einführen, die bewerten, wie gut eine Engine mit zunehmender Anzahl von Kernen skaliert. Dies würde es ermöglichen, Engines nicht nur nach ihrer absoluten Geschwindigkeit oder Leistung zu beurteilen, sondern auch danach, wie effizient sie zusätzliche Hardware-Ressourcen nutzen können.
Die Leistung in einem Single-Core-Umfeld zu messen, gibt Einblicke in die Effizienz und Optimierung auf der grundlegendsten Ebene. Dies ist wichtig für das Verständnis, wie gut die Engine ohne die zusätzliche Komplexität der Parallelverarbeitung funktioniert.

VG Dieter Brandhorst

By Peter Martan Date 2024-02-16 20:03 Edited 2024-02-16 20:20 Upvotes 1

Dieter Brandhorst schrieb:

Während z.B. ElostatTS davon ausgeht, dass eine Verdopplung der Rechenleistung eine Halbierung der Lösungszeiten zur Folge hat, kann bei Multi- Core- Systemen im Vergleich zu Single - Core genau das Gegenteil der Fall sein.

Wie kommst du darauf, dass EloStatTS von derartigen Voraussetzungen ausgeht, die jeder Erfahrung im Umgang mit Schachstellungen und Engine- Output spotten (egal wie gut oder schlecht sie als "Teststellungen" für welche Tests auch immer geeignet sein mögen)?
Wenn du schon weißt, wie sich welche Rechenleistung bei welchem Programm auf welche time to solution- (oder time to eval, time to best line, was auch immer du für Parameter messen willst und kannst, die nicht nur benchmarks der Knoten- und oder Tiefenzählung pro Zeit beinhalten) Veränderungen auswirken, brauchst du ja keine Stellungstests mehr zu machen

Wäre das so, müsstest du auch keine SMP- Matches mehr spielen lassen.

By Dieter Brandhorst Date 2024-02-16 20:23

Zitat:

Wie kommst du darauf, dass EloStatTS von derartigen Voraussetzungen ausgeht, die jeder Erfahrung im Umgang mit Schachstellungen spotten

Ich zitiere mal Frank Schubert:

Zitat:

Dies steht im Widerspruch zu der Erfahrung aus den Eloranglisten, bei denen eine Verdopplung
der Rechengeschwindigkeit des verwendeten PCs (und somit eine Halbierung der Lösezeit im Stellungstest) mit einem
Elozugewinn von lediglich 70 Punkten einhergeht.

Quelle: https://glarean-magazin.ch/wp-content/uploads/2017/03/Lösung-eines-alten-Problems-Frank-Schubert-1.pdf

VG Dieter

By Peter Martan Date 2024-02-16 20:39 Edited 2024-02-16 21:12

Was hat das damit zu tun, dass Frank Schubert seine damaligen Beobachtungen von Elo- Zugewinn in Eng-Eng-Match-Ranglisten als Grundlage der Formeln zugrunde gelegt hat, die dann das EloSatTS- Programm zu diesen Elo- Berechnungen irgendwie vergleichbaren Stellungstest- Elo ausrechnen lassen sollte?
Es ist eben weder im Eng-Eng-game playing noch im Stellungstest Spielstärke irgendwie als direkt umrechenbare Funktion von Software (auch nicht ein- und derselben) und Hardware- Leistung vorhersagbar, drum musst du sie für verschiedene Software, verschiedene Hardware und verschiedene Hardware- Zeit- Leistungen immer extra testen.

Du hast dir viel Mühe gemacht, aber irgendwie scheint es mir immer noch, dass du eine wesentliche Größe dessen, was du testen willst, einfach nicht als solche für sich allein stehende zur Kenntnis nehmen willst, die Größe heißt stellungsabhängige schachliche Performance. Nicht time to depth, nicht Knoten/Zeit, nicht Zahl an Lösungen bestimmter Stellungen, am ehesten entspricht sie hinlänglich bekannten Begriffen wie time to solution, wie auch immer du solution für die einzelne Stellung (oder auch für das einzelne aus der Stellung ausgespielte Match) definierst. Und ja, in dem Zitat von Schubert vereinfacht er den Begriff der Lösungszeit einer Teststellung auch, ich bin mir aber trotzdem sicher, der kannte und kennt den Unterschied von dem, was man da halt so für einzelne Stellungen hin und wieder zufällig auch so einfach bekommen kann, und dem, was prinzipiell eben überhaupt nicht so einen direkt proportionalen Zusammenhang hat.

Warum machst du, wenn du dir dir viele Mühe schon antust, nicht das Ganze Stellung für Stellung und Parameter für Parameter, der an Stellungen schachlich interessieren kann, und wenn's schon single best move- Stellungen sind, warum nicht wirklich zunächst mal einfach anand von time to solution- Messungen?
Da kannst du pro Stellung viel besser, weil schneller statistisch signifikanter, für die einzelne Engine, die einzelne Hardware und die einzelnen Zeit- Vorgaben Vergleiche anstellen.
Dass deine Studie für andere als die gewählten Stellungen (die ohnehin auch nicht gerade zahlreich sind) keine übertragbaren Ergebnisse (auch nicht in Elo) liefert, ist dir ja klar, denke ich.
Aber warum dann nicht wenigstens gleich Stellung für Stellung? Wie schachlich relevant die Zeit- Leistung der einzelnen Engine bei der einzelnen Stellung ist, bleibt sowieso deinem ureigenen schachlichen Urteil überlassen.

Tut mir leid, ich komme schon wieder ins unnötig lange Schreiben, ich sollte es lieber gleich wieder lassen, du und die Anderen, die sich derlei von mir zu lesen überhaupt noch antun, wissen doch vermutlich ohnehin längst, was ich meine. Es nicht glauben zu wollen, mag trotzdem immer noch klappen, ich frag' mich nur mehr und mehr, wozu will man das mit Gewalt nicht und nicht wahrhaben? Dass schachliche Leistungen, welcher Art auch immer und wie auch immer man sie am besten meint messen zu können, nur strikt stellungsabhängig messbar sind und nur in genau umschriebenem Zusammenhang mit den Teststellungen (seien's auch bestimmte Eröffnungsstellungen für Eng-Eng-game playing) vergleichbar sind, ist das wirklich noch anders als höchsten quantitativ anzuzweifeln? Und was erspart man sich dadurch, dass man dem nicht auch endlich in den Tests Rechnung trägt? Beim game playing wird's ja eh immer klarer, dass die Elo, die rauskommen, UHO- Elo oder balanced opening- Elo sind, Elo aus VSTC, STC, LTC oder VLTC mit verschiedener Hardware- TC als zusätzlich zu beachtendem Kriterium, wenn das schon schön langsam Allen immer klarer wird, könnte man sich das für die Stellungstests und die Teststellungen für nicht ausgespielte Stellungstests (zum Unterschied von den ausgespielten Eng-Eng-Matches) dann nicht auch endlich eingestehen?

Kurt's Fassung: time to solution ist nicht direkt proportional der Knotenleistung oder anderen rein Hardware- abhängigen benchmarks, nicht bei ein- und derselben Engine und schon gar nicht bei verschiedenen Engines untereinander, nicht bei "Teststellungen", weder bei single best move- Stellungen noch bei anderen, wenn sie das mal bei einzelnen Stellungen ist (direkt proportional), ist das reiner Zufall und die Treffer sind Ausnahmen, wenn man das statistisch vergleicht und quantitativ halbwegs genau nimmt. Natürlich haben bestimmte Stellungen weniger time to solution- Schwankungen als andere, und bei manchen Engines mehr und bei anderen weniger, aber wenn man irgendwelche Parameter wie time to solution (noch einer der am leichtesten messbaren unter den schachlich relevanten) vergleichen will, muss man's Stellung für Stellung, Software für Software, Hardware für Hardware machen. Wäre das anders, wären SMP- Matches völlig überflüssig.
Period.

By Dieter Brandhorst Date 2024-02-16 21:12

Zitat:

Wenn du dir seine primäre Formel 1 ansiehst D=70*log2 (t2/t1) erkennst du doch an dem Logarithmus zur Basis 2, dass eine Halbierung der Lösungszeit einem Elogewinn von 70 (später hat er dann 50 genommen) entspricht. Diese Erkenntnis hat er aus Elolisten empirisch gewonnen und auf Stellungstests und deren Lösungszeiten angewendet. Das geht doch klar aus seiner Formel und Beschreibung hervor. Zu seiner Zeit war das ja auch korrekt so, denn es wurde noch nicht parallel gerechnet.

Zitat:

für sich allein stehende zur Kenntnis nehmen willst, die Größe heißt stellungsabhängige schachliche Performance

Warum heißt Fallstudie wohl Fallstudie? Weil sie die Ergebnisse der in dieser untersuchten Fälle darstellt und nichts anderes. Natürlich ist immer auch alles stellungsabhängig, aber für die von mir untersuchten Fälle, unter diesen speziellen Bedingungen, gilt genau das, was ich berichtet habe. Eine anderer Anspruch
wird nicht erhoben.

Zitat:

Dass deine Studie für andere als die gewählten Stellungen (die ohnehin auch nicht gerade zahlreich sind) keine übertragbaren Ergebnisse (auch nicht in Elo) liefert, ist dir ja klar, denke ich.

Darum ging es ja auch nicht. Es ging um die Konsistenz der Engines im Vergleich multi-core vs. single core und die daraus sich ergebenden Schlüsse. Wenn du denkst, das sich da mit anderen Stellungen am Ergebnis oder der Erkenntnis das single-core wesentlich konsistenter ist als multi-core, ändert, steht es dir ja frei das mit Daten und Fakten zu belegen.

VG Dieter

By Peter Martan Date 2024-02-16 21:28 Edited 2024-02-16 22:22

Dieter Brandhorst schrieb:

Zitat:

Wenn du dir seine primäre Formel 1 ansiehst D=70*log2 (t2/t1) erkennst du doch an dem Logarithmus zur Basis 2, dass er eine Halbierung der Lösungszeit mit einem Elogewinn von 70 (später hat er dann 50 genommen) entspricht. Diese Erkenntnis hat er aus Elolisten empirisch gewonnen und auf Stellungstests und deren Lösungszeiten angewendet. Das geht doch klar aus seiner Formel und Beschreibung hervor. Zu seiner Zeit war das ja auch korrekt so, denn es wurde noch nicht parallel gerechnet.

Ja, ja, ja, nee, nee, nee.
Die Formel hat er so erstellt, weil er für den Fall der Halbierung der Lösungszeiten den Elo- Zugewinn an den angleichen wollte, den er aus den damaligen Elolisten empirisch hatte. Das heißt überhaupt nicht, dass er davon ausgegangen ist, dass die doppelte Rechenleistung (in was auch immer gemessen) automatisch eine Halbierung der Lösungszeiten für ihn bedeutet hätte, sonst hätte er sich die Formel ja sparen können und das Testen als solches auch

Die Umrechnung von Zahlen von Lösungen in einer bestimmten TC mit bestimmen Teststellungen in Elo war für ihn ein Weg, verschiedene Hardware- Leistungen verschiedener Engines überhaupt miteinander vergleichen zu können, es war und ist ein guter Weg, gerade auch, wenn man nicht nur single thread testen will (was man auch damals schon nicht musste und nicht machte) und sie trug und trägt der Erkenntnis Rechnung, dass time to solution- Messungen (um solche handelt es sich bei Stellungstests immer irgendwie, da kannst du auch machen, was du willst, du kannst single thread, SMP, mit oder ohne automatisch ablaufende Suiten mit oder ohne bestimmte TC- Vorgaben testen, time to solution kriegst du nicht als Performance- Hauptkriterium weg) beim Stellungstest ebenso von der Software, der Hardware und den Zeitvorgaben abhängen, aber nicht einfach direkt ineinander umrechenbar sind anhand von irgendwelchen anderen benchmarks, das ist eine Erkenntnis, zu der deine Studie ja vielleicht auch wieder was beiträgt, danke dafür, aber irgendwie war mir das halt vorher auch schon klar.
Nochmals: man müsste sonst auch keine SMP- Matches machen, um schachliche Performance- Unterschiede zu single thread festzustellen, und man könnte beliebig kleine Hardware- TCs auch fürs Eng-Eng-game playing nehmen und von der Grundstellung allein ausspielen lassen, bei entsprechend kurzer Hardware- TC wäre auch so der Performance- Unterschied zwischen beliebig nahe beisammen liegenden Engines im wahrsten Sinn des Wortes blitzschnell diskriminierbar, games in Zeitvorschrift 1" pro Partie wären echt schnell in statistisch ausreichend signifikanter Zahl ausgespielt.

Quantitativ sehe ich's wahrscheinlich sogar immer noch vielschichtiger als du, was die Stellungstests und die Teststellungen angeht, weil ich nicht nur single best move- Stellungen für Stellungstests nehme. Und dass du mit single thread keine Streuung hast, wenn du größere Zahlen an Stellungen mit fixer TC- Vorgabe und bestimmten tools (GUIs, command- line- tools wie MEA...) laufen lässt, so ist's ja auch nicht. Da streuen diese Ergebnisse auch single thread, und mit Lc0 kannst du dir sogar bei der time to solution der einzelnen Teststellung (die ja ansonsten bei A-B schon deterministisch ist) aufmalen, dass du da keine Streuung zwischen den einzelnen Messungen hast.
So what?

Dieter Brandhorst schrieb:

Da such' ich immer noch das beste Posting, in dem ich derlei schon vor längerer Zeit veröffentlich hab', leider ist in dem, dass ich schon gefunden habe und das noch nicht gar so lang her ist

https://talkchess.com/forum3/viewtopic.php?p=939929&sid=bd4422cbc72c6a4c2259acb6310354c9#p939929

, der Screenshot mit den Ergebnissen nicht mehr aktuell, sodass die Resultate nicht mehr lesbar sind, aber da find' ich schon noch was besseres, die Frage ist, ob in der Editierzeit.

In der (Editierzeit) hab' ich lieber den Screenshot von damals (oder einen ähnlichen, den ich noch gespeichert hatte) neu hochgeladen:

Zur Leserlichkeit auf die Lupe klicken.
Das war damals ein Vergleich von 2 SF- Versionen auf 1, 2, 4, 8, 16 und 32 Threads mit einer 888- Stellungen- Suite.

By Dieter Brandhorst Date 2024-02-16 22:33

Zitat:

Die Formel wurde in einer Zeit entwickelt, in der die Parallelverarbeitung in der Form, wie wir sie heute kennen, noch nicht üblich war. Sie diente dazu, die Verbesserung der Lösungszeiten aufgrund von Optimierungen in der Software selbst und nicht durch Hardwarebeschleunigung durch Parallelverarbeitung zu quantifizieren. Die Gleichsetzung einer Halbierung der Lösungszeit mit einem bestimmten Elo-Gewinn spiegelt einen empirischen Zusammenhang wider, der aus damaligen Beobachtungen abgeleitet wurde.
Die Methodik, die Lösungszeiten zweier Schachengines in Relation zu setzen und das Ergebnis unabhängig von der absoluten Zeit zu machen, ist tatsächlich ein innovativer Ansatz zur Bewertung der relativen Engine-Leistung gewesen. Diese Vorgehensweise ermöglicht es, die Engine-Leistung in einem hardwareunabhängigen Kontext zu vergleichen, solange die Hardware konsistente Ergebnisse liefert. Der Ansatz, jede Halbierung der Lösungszeit als einen festen Elo-Gewinn zu betrachten, bietet eine elegante Lösung für den Vergleich der Effizienz verschiedener Engines unter der Annahme einer linearen Skalierung. Mit den heutigen stark parallel rechnenden Systemen ist diese lineare Skalierung leider nicht (mehr) gegeben.

Die Herausforderungen, die sich bei der Anwendung dieser Methodik in Multi-Core-Systemen ergeben, sind daher groß:

1.Inkonsistente Ergebnisse: Die Ergebnisse in Multi-Core-Systemen können stark variieren. Diese Variation kann durch viele Faktoren verursacht werden, einschließlich der unterschiedlichen Effizienz, mit der verschiedene Engines Parallelverarbeitung nutzen, sowie durch die Komplexität der Interaktionen zwischen den Cores.
2.Notwendigkeit zahlreicher Durchläufe: Um statistisch signifikante und belastbare Ergebnisse zu erzielen, sind in einem Multi-Core-Umfeld erheblich mehr Durchläufe erforderlich. Dies erhöht den zeitlichen und rechnerischen Aufwand für Tests erheblich.

Für eine umfassende Leistungsbewertung von Schachengines in heutigen Computerumgebungen wäre es daher sinnvoll, eine hybride Bewertungsstrategie zu verfolgen, die sowohl Single-Core- als auch Multi-Core-Tests umfasst. Dies würde die Vorteile des ursprünglichen Ansatzes beibehalten, während gleichzeitig die zusätzliche Komplexität und Leistungsfähigkeit moderner Mehrkernsysteme berücksichtigt wird.

VG Dieter

By Peter Martan Date 2024-02-16 22:59 Edited 2024-02-16 23:20

Dieter Brandhorst schrieb:

Die Gleichsetzung einer Halbierung der Lösungszeit mit einem bestimmten Elo-Gewinn spiegelt einen empirischen Zusammenhang wider, der aus damaligen Beobachtungen abgeleitet wurde.
Die Methodik, die Lösungszeiten zweier Schachengines in Relation zu setzen und das Ergebnis unabhängig von der absoluten Zeit zu machen, ist tatsächlich ein innovativer Ansatz zur Bewertung der relativen Engine-Leistung gewesen. Diese Vorgehensweise ermöglicht es, die Engine-Leistung in einem hardwareunabhängigen Kontext zu vergleichen, solange die Hardware konsistente Ergebnisse liefert. Der Ansatz, jede Halbierung der Lösungszeit als einen festen Elo-Gewinn zu betrachten, bietet eine elegante Lösung für den Vergleich der Effizienz verschiedener Engines unter der Annahme einer linearen Skalierung. Mit den heutigen stark parallel rechnenden Systemen ist diese lineare Skalierung leider nicht (mehr) gegeben.

Er hat nicht jede Halbierung der Lösungszeit als einen festen Elo- Gewinn betrachtet, das wäre ein sehr viel einfachere Formel als die von dir zitierte, sie sähe so aus: t/2=xElo

Zitat:

Die Herausforderungen, die sich bei der Anwendung dieser Methodik in Multi-Core-Systemen ergeben, sind daher groß:

1.Inkonsistente Ergebnisse: Die Ergebnisse in Multi-Core-Systemen können stark variieren. Diese Variation kann durch viele Faktoren verursacht werden, einschließlich der unterschiedlichen Effizienz, mit der verschiedene Engines Parallelverarbeitung nutzen, sowie durch die Komplexität der Interaktionen zwischen den Cores.
2.Notwendigkeit zahlreicher Durchläufe: Um statistisch signifikante und belastbare Ergebnisse zu erzielen, sind in einem Multi-Core-Umfeld erheblich mehr Durchläufe erforderlich. Dies erhöht den zeitlichen und rechnerischen Aufwand für Tests erheblich.

Für eine umfassende Leistungsbewertung von Schachengines in heutigen Computerumgebungen wäre es daher sinnvoll, eine hybride Bewertungsstrategie zu verfolgen, die sowohl Single-Core- als auch Multi-Core-Tests umfasst. Dies würde die Vorteile des ursprünglichen Ansatzes beibehalten, während gleichzeitig die zusätzliche Komplexität und Leistungsfähigkeit moderner Mehrkernsysteme berücksichtigt wird.

Wenn dir die Formel der Umrechnung in Elo nicht gefällt, erstelle eine bessere, Frank Sanders ist dabei, eine zu erstellen, wie gut sich die praktisch bewähren wird, wird man sehen, direkt von WDL in Elo umzurechnen ist sicher ein einfacher und praktikabler Weg, aber die Zeit dabei mehr als es die TC sowieso tut, zusätzlich für die einzelnen gemeinsamen Lösungen in Wins umzurechnen, das hat den Vorteil der größeren Diskrimination aber den Nachteil, die Ergebnisse wieder weniger mit anderen vergleichen zu können. Man müsste die zeitlichen Unterschiede pro Stellung, Lösungszeit und Enginepaar TC- abhängig betrachten, wenn man's überhaupt auch machen will, muss man ja nicht, dann sind halt alle von je 2 Engines in der TC gelösten Stellungen als Remis zu zählen. Und die Zeit geht sowieso über die TC ein als nach wie vor wesentlichstes Performance- Kriterium, wie gesagt, time to solution bleibt das Prinzip auf jeden Fall, egal, ob man zusätzliche Formeln für mehr Diskrimination und oder die Umrechnung in Elo in die Auswertung einbaut oder nicht.

In Elo umrechnen muss man Stellungstest- Ergebnisse auch an und für sich überhaupt nicht, und wenn ich sehe, wie die Leute, die regelmäßig Stellungstests machen, darauf reagieren, wenn man ihnen Möglichkeiten dazu anbietet (sei's mit EloStatTS), verliere ich ohnehin mehr und mehr die Lust daran. Mir kommt's auf eine Bewertung der statistischen Relevanz des einzelnen Ergebnisses an, nicht auf die Maßzahl.
Was aber mit deiner Beobachtung der Unterschiede zwischen single thread und SMP (bei A-B, was ja nur die Hälfte der momentan relevanten Fragen beantwortet, nicht die des Vergleichs mit Lc0- artigen Engines) auch an sich überhaupt nichts zu tun hat, ist nach wie vor die Frage der Übertragbarkeit von einzelnen Stellungstest- Resultaten verschiedener Stellungen, Engines und Hardware- TCs. Du magst dich der Hoffnung hingeben, (oder ich täusche mich da in dem, was du erreichen willst und du willst es vielleicht eh gar nicht) dass du, wenn du dich auf single thread und A-B beschränkst, dadurch die Ergebnisse zwischen verschiedenen Stellungen, verschiedener TC und verschiedenen Engines eher wirst aufeinander übertragen können. Ich finde halt, wenn du dafür eine Formel wie die von EloStatTS für brauchbar hältst, warum die dann für SMP nicht genau so funktioneren sollte und SMP halt einfach mehr runs bräuchte?
Und so ist's ja mit EloStatTS auch, wenn dir nur die quantitative Umrechnung von Lösungszeiten bestimmter Stellungen und Engines nicht gefällt, ändere halt die Formeln einfach in Hinblick auf die quantitative Umrechnung, von mir aus bestimmte quantitative Parameter numerisch anders für single thread und anders für SMP, anders für die einen Stellungen und die eine Hardware- TC als für die anderen und gut.

Ich fände immer noch am vielseitigsten, WDL (mit oder ohne Elo als Ergebnis) als wesentliches Bewertungskriterium zu nehmen, einen zusätzlichen Punktegewinn durch bestimmte Unterschiede in der einzelnen Lösungszeit im Engine- Vergleichspaar anhand der einzelnen Stellung zu definieren, erhöht die Diskrimination, muss auch die error bar nicht heben oder jedenfalls nicht gleicht stark oder gar stärker, muss aber jedenfalls in Relation zur TC stehen und die muss wieder an die Stellungen und die Engines angepasst werden.

Diese Punkte scheinen mir nach wie vor die wichtigsten (und eigentlich die einzig wirklich wichtigen) beim statistischen Stellungstest zu sein und viel mehr Rolle zu spielen als die Frage, ob man, wenn diese wesentlichen Zeit- und Stellungsfragen an Hardware single thread (bei A-B) oder SMP entsprechend angepasst werden, dann dadurch auch schon wirklich mehr oder weniger Übertragbarkeit auf andere Tests gewinnt.
Dass man auch mit Elo als Ergebnis solche Übertragbarkeit nicht automatisch bekommt und auch nicht dadurch, dass man Lc0 völlig weglässt und A-B nur mehr single thread testet (ist ja auch einfach eine Frage des Gesamt- Hardware- Zeitaufwandes mit wievielen runs bekommst du ausreichende Signifikanz und ein möglichst großes Verhältnis von Diskrimination zur error bar), das ist ja wohl ohnehin auch evident.

By Dieter Brandhorst Date 2024-02-17 10:41

Zitat:

Er hat nicht jede Halbierung der Lösungszeit als einen festen Elo- Gewinn betrachtet, das wäre ein sehr viel einfachere Formel als die von dir zitierte, sie sähe so aus: t/2=xElo

Die ursprünglich zitierte Formel, die auf dem logarithmischen Verhältnis der Lösungszeiten basiert, zeigt, dass eine Halbierung oder Verdoppelung der Lösungszeit eine feste Elodifferenz ergibt. Setze für das Verhältnis t2 zu t1 =2 in die Formel ein und D ist gleich 70, unabhängig davon wie groß t2 oder t1 ist, nur das Verhältnis zueinander muss 2 sein. Das ist alles was ich behauptet habe. Die Ausdrucksweise, wie du sie oben angibst, stammt ja von Frank Schubert selbst, siehe das Zitat.
Die Frage ob das unter den heutigen Bedingungen des massiven Parallelrechnens noch so zutrifft, habe ich natürlich stellen wollen.

Zitat:

Wenn dir die Formel der Umrechnung in Elo nicht gefällt,….

Da verstehst du immer noch was falsch. Die Umrechnung in Elo stört mich weniger. Man kann nur nicht blind einfach alles in Elo umrechnen was da mächtig schwankt und streut. Man benötigt dann halt sehr viele Einzelvergleiche um halbwegs valide Ergebnisse zu bekommen. Genau darauf wollte ich mit meinen Daten hinweisen. Bei den von mir gefundenen Werten, müsste man mit jeder Engine im Multi-Core-Modus bei einem Vergleich schon schätzungsweise 30 Runs machen. Wer will denn sowas?

VG Dieter

By Peter Martan Date 2024-02-17 11:05 Edited 2024-02-17 11:34

Dieter Brandhorst schrieb:

Die Frage ob das unter den heutigen Bedingungen des massiven Parallelrechnens noch so zutrifft, habe ich natürlich stellen wollen.

Das beantwortet dir die error bar, die ja ohnehin auch angegeben wird, für den einzelnen Test mit der einzelnen Suite und der einzelnen Hardware- TC. Alles andere ist ein Frage der Übertragbarkeit auf andere Tests mit anderen Suiten, anderen Engines und anderen Hardware- TCs.

Zitat:

Und wieviele Runs brauchst du single thread? Du verlässt dich einfach darauf, dass das, was du da bei den paar einzelnen single thread- runs mit SF bekommen hast, für alle anderen Engines, Suiten und Hardware- TCs auch gilt.
Und wieviele single thread mit einer anderen Engine als der, die du probiert hast? Nimm mal Dragon statt SF und sei nicht allzu überrascht, wenn dir der auch single thread in einem GUI mit Extrahalbzug- Zählung (z.B. Shredder oder Fritz und weniger als dem Maximum an Extraplies, bei Banksia auch mit dem Maximum, von MEA auch ganz zu schweigen) eine Streuung liefert wie SF SMP, von Lc0 wollen wir erst recht gar nicht reden.
Und wieviele single thread mit einer anderen Suite? (Gut wär' eine mit mehr Stellungen, weil dann die Streuung relativ zur Gesamtzahl an Stellungen weniger Rolle spielte, jedenfalls wahrscheinlich, wenn's eine zum Enginepool und zur Hardware- TC passende Suite wäre.)

Was du immer noch nicht verstehst: Es kommt weniger darauf an, ob's single thread ist, sondern mehr darauf, dass es valide Teststellungen für die auf einer bestimmten Hardware- TC miteinander verglichenen Engines sind, das schon allein, was die statistische Signifikanz des Einzeltests angeht (der Hauptvorteil von EloStatTS für mich, dass du die error bar deines einen Testpools mit deiner einen Hardware- TC auch ausgerechnet bekommst) und erst recht, wenn du den einen Test mit einem anderen vergleichen willst.
Ich bin jetzt wieder raus.

By Dieter Brandhorst Date 2024-02-17 12:24

Zitat:

Meine Herangehensweise und die daraus resultierenden Empfehlungen basieren ausschließlich auf den Daten und Beobachtungen, die ich im Rahmen meiner Untersuchungen gesammelt habe. Ich möchte betonen, dass diese Erkenntnisse nicht als universell gültig für sämtliche Situationen, Engines oder Hardware-Konfigurationen angesehen werden sollen. Die Annahme, ich würde meine Beobachtungen ohne weiteres auf alle nicht von mir untersuchten Fälle übertragen, entbehrt jeder Grundlage und entspricht nicht der Wahrheit.

Die Entscheidung, Single-Thread-Tests gegenüber Multi-Thread-Verfahren zu bevorzugen, fußt auf der festgestellten geringeren Variabilität der Testergebnisse unter den erstgenannten Bedingungen. Diese Beobachtung, gepaart mit der logischen Überlegung, dass Single-Thread-Prozesse naturgemäß weniger Anfälligkeiten für Schwankungen aufweisen als komplexe Parallelrechnungen, bildete die Grundlage für meine Empfehlung. Es ist eine Schlussfolgerung, die nicht nur durch meine Daten gestützt wird, sondern auch durch die intrinsische Logik des Vergleichs zwischen diesen beiden Rechenansätzen.

Ich möchte betonen, dass meine Ausführungen und Empfehlungen dazu dienen, auf Basis der von mir erlangten Erkenntnisse Orientierung zu bieten. Sie sind als Anregung zu verstehen, in ähnlichen Untersuchungen möglicherweise Single-Thread-Tests aufgrund ihrer konsistenteren Ergebnisse zu bevorzugen. Diese Herangehensweise erhebt nicht den Anspruch auf Allgemeingültigkeit, sondern ist vielmehr ein Vorschlag, der auf sorgfältiger Analyse und Beobachtung beruht. Es ist mein Ziel, eine fundierte Diskussion zu fördern, die sowohl die Stärken als auch die Limitationen verschiedener Testmethoden berücksichtigt und dabei stets offen für neue Daten und Perspektiven bleibt.

und jetzt bin ich raus,

VG Dieter