Jörg,

denke wir reden ein wenig aneinander vorbei, sei mir nicht böse.
Deine Erläuterungen sind ja OK und auch gut aber ...

Wenn, fast alle Engines bei der SMP Frage meist heute alles gleich machen wird die Sache wieder vergleichbar.

Nun was schrieb der Stockfish Programmierer Tord Romstand dazu.

17.
Frank Quisinsky
Back to multiprocessing. Questions 17-19 were inevitable. A commercial chess engine with multiprocessing support costs a lot of money more. Do you agree on the price-calculation? Perhaps the multiprocessing code needs again and again a lot of time for each new version. It seems that commercials spend 50% of programming time in their multiprocessing code! Is this the cause that single core engine is 50% cheaper.

Do you think the claim was reasonable? Please dont write: You asked the wrong person!

Tord Romstad
The prices of commercial programs have no direct relation to the amount of work involved in creating them. The prices are chosen with the intention of maximizing the profit. If the single-CPU version of a program costs X euro and the multi-CPU version of the same program costs 2X euro, it only means that the programmer thinks he will earn more money this way than by any other pricing scheme.



18.
Frank Quisinsky
I heard that different ways to implement multiprocessing are possible. Could you write a little bit about this topic and the possibilities programmers have today? Which way is the most popular technique?

Tord Romstad
Most programs use some variant of a technique called the "Young Brothers Wait" algorithm. The implementation in Stockfish (and, I think, in most other programs) is influenced by Crafty's. There are algorithms which are harder to implement but scale better to a higher number of CPUs, and algorithms which are easier to implement but less efficient. A plain and simple Crafty-style YBW search is a good balance between complexity and efficiency on the mass-market computers available today.



19.
Frank Quisinsky
Analysing with more than one core will give us different results if we try to replay the same analyse. Could you explain this circumstance? Perhaps it is caused by one of the possible techniques to implement multiprocessing?

Tord Romstad
When a chess program searches a position somewhere deep inside the search tree, it makes use of information it remembers from previous positions examined in the same search. Things like which moves are pruned, reduced or extended depend on which positions have been examined before, and what the results of searching these positions were. Most of the information used for such decisions is taken from memory which is shared between all CPUs.

As long as the program uses a single search thread, everything is 100% deterministic. But with multiple threads, weird things start happening, because the threads never run at exactly the same speed. Once in a while, one of the CPUs will have to take a break for a few milliseconds because the operating system gives it some other task. This happens randomly and unpredictably, and you have no control of when or how often it happens. As a consequence, exactly what each CPU has seen when a certain position is reached somewhere inside the tree is essentially random, and this randomness has an impact on the search decisions made at this position.

Zurück zu Deinem Beitrag:
Du schreibst:

Willst du die Spielstärke für 8 Threads ermitteln, musst du auch mit 8 Threads testen!
Es gibt da keinen anderen Weg und auch keine Abkürzung!

Edit: Um es vielleicht noch besser zu verdeutlichen, du erhältst mit mehreren Threads quasi eine andere Engine als mit nur einem Thread.

...

Auch das ist nachvollziehbar und kann ich fast komplett unterschreiben, nicht Deine letzte Anmerkung.

Grundsätzlich ist und bleibt der folgende Grundsatz immer klar:
Es kann nur verglichen werden was vergleichbar ist. Das war egal in welchem Fall der SMP Umsetzung nie der Fall.
Ob dann eine Engine Faktor 1,4 hatte, die nächste Faktor 1,6 oder im Falle einer anderen SMP Umsetzung dann Züge in der Analyse nicht mehr zu reproduzieren sind ...
Das ist für jeden Vergleich schlecht.

---

Ich schrieb grundsätzlich könnte man mit einer einfachen Erhöhung der Bedenkzeit höhere Zugtiefen auf mehreren Cores produzieren.

Die Theorie und die Praxis:

Nehme eine Lösung von einem Problem:
Dann analysiere mit 1 Core, 2 Cores, 4 Cores, 8 Cores ... grob siehst Du was eine Verdoppelung bringt anhand der Lösezeiten.

Ich hatte den Fall noch nicht, dass eine Lösung mit einem Core gefunden wurde und mit 4 Cores nicht.
Oder das ein Core schneller als vier Cores waren.
Wenn ich dann mehrere vergleichbare Aufgaben zusammenziehe zu einem Endergebnis ist es fast immer so gewesen dass 4 Cores besser waren als 1 Core.
Generiere ich daraus einen Durchschnitt ... sehe ich was es ca. in NN Zeiten bringt.

Das ich bei mehreren Threads eine quasi andere Engines als mit einem Thread erhalten kann ich so nicht stehen lassen.
Ich sehe das in der Praxis nicht.

Viele Grüße
Frank