Not logged inCSS-Forum
Forum CSS-Online Help Search Login
CSS-Shop Impressum Datenschutz
Up Topic Hauptforen / CSS-Forum / Aktueller CPU Bench für Schachengines
- - By Ingo Bauer Date 2011-07-10 19:59 Edited 2011-07-10 20:05
Hallo

Da alle Schachbenchmarks daran kranken, dass sie genau für EINE Engine einen Benchmark fahren und der nicht mal immer für diese eine Engine richtig ist (z.B. FritzBench), führe ich einen Benchmark mit einer Durchschnittsberechnung über die TOP 20 UCI Engines aus der IPON. Ich lasse in Grundstellung bei 1GB Hash jede Single-Engine auf jeder der drei CPU Typen 5 Minuten laufen, und errechne dann die kN/s. Ich muß das aus den gemeldeten Knoten selber errechne, da leider einige der UCI-Engines den "stop" Befehl am Ende einer Analyse nicht korrekt interpretieren und die gemeldeten und angezeigten Knoten in der GUI nicht immer stimmen. Aus diesen Werten errechne ich dan den theoretischen Wert bei 1 GHz für alle CPUs.

Im linken, oberen, rot umrandeten Feld sieht man dann den Durchschnittswert über die genannten 20 Engines. Ein i7 (i5/i3) ist pro echtem Kern also rund 14% schneller als eine Core2 CPU, oder ein Phenom2 macht 87% einer iX CPU - bei gleichem Takt.
Die zweite Box zeigt die drei populärsten Taktraten die für normale Preise zu erwerben sind und deren Verhältnisse untereinander, aber das kann jeder mit den gegebenen Zahlen für seine CPU-Clock selber errechnen.

Einige werden von dem geringen Gewinn von Intels iX CPUs vielleicht enttäuscht sein weil sie gerne auf den Fritzbench schauen, aber gerade der ist für wirkliche Vergleiche völlig ungeeignet. Er favorisiert massiv Intel CPUs und stimmt in seiner Aussage nicht mal für Fritz 12 selber. Wenn man allerding in die genauen Daten geht, sieht man schon, dass z.B. Naum 4.2 ebenfalls extrem gut auf Intel läuft, während Rybka und Komodo gerade mal 6-8% von der iX Architektur gegenüber Phenoms profitieren und auf Phenoms sogar 7-12% besser laufen als auf der Core2 Hardware.

Besonderheiten: Strelka lief nur mit 512 MB Hash, da die Engine bei 1GB abstürzt. Houdini detektiert automatisch ob eine CPU SSE42 kann oder nicht. Da dies aber durchaus eine Eigenschaft der CPU ist habe ich es so im Test belssen und für die anderen SSE Engines jeweils das "nicht-SSE" Gegenstück auf der Core2 CPU eingespielt. MP Fähikkeiten kann ich so leider nicht messen, da ich mit jeder Enigne, auf jeder CPU mindestens 10 Durchläufe (+ mindestens Neustart der GUI) a 5 Minuten machen müßte und das Ergebniss mitteln. Ohne das ich das Belegen kann, habe ich aber das Gefühl das die Phenoms bei MP ihren Abstand (von 15%) zur Intel-i-Serie minimal verkürzen können. Die iX Technologie bleibt trotzdem sicher besser.
Den Rybkawert sollte man mit Vorsicht genießen. Ich habe lange überlegt ob ich den Aufgrund seiner bekannten Falschaussagen überhaupt mit reinnehmen sollte, bin aber zu dem Schluß gekommen das es bei Singleengines nicht so sehr ins Gewicht fällt. (Bei MP wird das ganze komplizierter!)

Übertaktungsfähigkeiten habe ich dabei natürlich ausser acht gelassen. Da muß jeder selber wissen was er bereit ist zu riskieren und auch zu investieren.

Hier die Liste:



Falls sich jemand wundert warum Ph2 to C2 bei 100% ist, umgekehrt es aber 101% sind ... ich lasse auf 2 Nachkommastellen runden. Da kann es mal ein Prozent rauf oder runter gehen. Als nächstes bin ich auf Buldozer gespannt!

Gruß
Ingo
Parent - - By Ernest Bonnem Date 2011-07-10 21:19
[quote="Ingo Bauer"]
Ich lasse in Grundstellung bei 1GB Hash jede Single-Engine auf jeder der drei CPU Typen 5 Minuten laufen, und errechne dann die kN/s. Ich muß das aus den gemeldeten Knoten selber errechne, da leider einige der UCI-Engines den "stop" Befehl am Ende einer Analyse nicht korrekt interpretieren und die gemeldeten und angezeigten Knoten in der GUI nicht immer stimmen. Aus diesen Werten errechne ich dan den theoretischen Wert bei 1 GHz für alle CPUs.[/quote]
Hallo Ingo,

Heißt das, daß für sagen wir Houdini Single-Engine, Du die kN/s nach 5 Min notierst, für ein 2GHz CPU und ein 4GHz CPU. Die erreichten Knoten (und vielleicht die Tiefe) sind ja nicht nach 5 Min die Selben...
Oder habe ich da etwas nicht verstanden?
Parent - - By Ingo Bauer Date 2011-07-10 21:34
Hallo Ernest,

[quote="Ernest Bonnem"]
[quote="Ingo Bauer"]
Ich lasse in Grundstellung bei 1GB Hash jede Single-Engine auf jeder der drei CPU Typen 5 Minuten laufen, und errechne dann die kN/s. Ich muß das aus den gemeldeten Knoten selber errechne, da leider einige der UCI-Engines den "stop" Befehl am Ende einer Analyse nicht korrekt interpretieren und die gemeldeten und angezeigten Knoten in der GUI nicht immer stimmen. Aus diesen Werten errechne ich dan den theoretischen Wert bei 1 GHz für alle CPUs.[/quote]
Hallo Ingo,

Heißt das, daß für sagen wir Houdini Single-Engine, Du die kN/s nach 5 Min notierst, für ein 2GHz CPU und ein 4GHz CPU. Die erreichten Knoten (und vielleicht die Tiefe) sind ja nicht nach 5 Min die Selben...
Oder habe ich da etwas nicht verstanden?
[/quote]

Ich mache hier einen Benchmark für Singleengines und teste ja kein MP. Time to depth ist da weniger interessant. Es geht rein und alleine um die kN/s für Singleengines, also wie schnell ist eine Engine. Das mache ich für 20 Engines auf 3 mal verschiedener Hardware. Ermittle die Duchschnittsgeschwindigkeit je Engine pro Hardware und vergleiche.
Wie ich schrieb, für MP wäre das deutlich komplizierter und ist auch nicht nur über die Knoten zu ermitteln. Das habe ich ein paar mal versucht und bin am Aufwand gescheitert. Ich mache das jetzt für Single und nehme an das es für MP halbwegs analog läuft. Ausser acht lasse ich damit auch, das die Phenoms ja 6 Kerner sind und die Intels nur Quads. Kosten-Nutzen Rechnungen darf jeder selber anstellen, sie sind aber wohl eindeutig.

Gruß
Ingo
Parent - - By Ernest Bonnem Date 2011-07-10 21:43
[quote="Ingo Bauer"]
Ich mache hier einen Benchmark für Singleengines und teste ja kein MP. [/quote]
Das weiß ich ja Ingo!
Meine Frage war: kannst Du vergleichen kN/s nach 1 mNodes (2GHz CPU: Intel C2Q) und kN/s nach 2 mNodes (4GHz CPU: Intel 920)?
Parent - - By Ingo Bauer Date 2011-07-10 22:26 Edited 2011-07-10 22:28
[quote="Ernest Bonnem"]
[quote="Ingo Bauer"]
Ich mache hier einen Benchmark für Singleengines und teste ja kein MP. [/quote]
Das weiß ich ja Ingo!
Meine Frage war: kannst Du vergleichen kN/s nach 1 mNodes (2GHz CPU: Intel C2Q) und kN/s nach 2 mNodes (4GHz CPU: Intel 920)?
[/quote]

Ja, warum nicht? Was spricht bei Single Engines dagegen? Wenn man eine gewisse "Grundrechenzeit" einhält sind die Knoten/s stabil!

Ich schaue nicht mal auf die Tiefe, sondern NUR auf die Gesamtnodes nach 5 Minuten, ich mache ja einen Benchmark und keinen Analysetest. Die Fragestellunbg ist also: Wie viele Knoten kann Single-Engine X auf System Y in 5 Minuten berechnen?

Bsp:

Shredder (zufällig ziemlich auf dem Durchschnitt aller Engines)

i7 @ 4Gz:

rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq -

Engine: DS12 1T (1024 MB)
by Stefan Meyer-Kahlen

...

20/50  2:11   +0.32    1.e4 e5 2.Nf3 Nf6 3.Nxe5 d6 4.Nf3 Nxe4
                       5.Nc3 Nxc3 6.dxc3 Be7 7.Bc4 O-O
                       8.O-O Nc6 9.Re1 Bf5 10.Bb3 Bf6
                       11.Qd5 Qd7 12.Bg5 (113.797.685) 868

21/53  3:43   +0.33    1.e4 e5 2.Nf3 Nf6 3.d4 Nxe4 4.Bd3 d5
                       5.Nxe5 Bd6 6.Nd2 Bxe5 7.dxe5 Nc5
                       8.Nb3 Nxd3+ 9.Qxd3 O-O 10.Be3 Re8
                       11.f4 Nc6 12.O-O (194.577.810) 869

best move: e2-e4 time: 5:08.305 min  n/s: 868.688  CPU 99.4%   n/s(1CPU): 873.931  nodes: 269.707.172
(ein bischen zu spät STOP gedrückt, sorry. Das Prinzip sollte aber klar sein)

Meine Frage ist nicht, welche Tiefe wurde erreicht, sondern wie viel Knoten wurden gemacht, was ich dann runterrechne auf kN/s.
Ich teile also 269707172 Nodes durch 308,305s und erhalte 874,81 kN/s bie 4GHz oder 218,70 bei 1GHz. (Kleine Abweichung zu meiner Tabelle, hängt davon ab wie der Timer beim Analysestop steht). Das ganze ist ansonsten wunderbar reproduzierbar weil single Enignes in der Regel deterministisch sind. Die geringen Abweichungen verschwinden auch durch mein Runden bei 2 Nachkommastellen.

Das Ganze nun für den 2 GHz Core2:

rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq

Engine: DS12 1T (1024 MB)
by Stefan Meyer-Kahlen

...

20/50  4:47   +0.32    1.e4 e5 2.Nf3 Nf6 3.Nxe5 d6 4.Nf3 Nxe4
                       5.Nc3 Nxc3 6.dxc3 Be7 7.Bc4 O-O
                       8.O-O Nc6 9.Re1 Bf5 10.Bb3 Bf6
                       11.Qd5 Qd7 12.Bg5 (113.797.685) 395

best move: e2-e4 time: 5:01.640 min  n/s: 395.832  CPU 100.0%   n/s(1CPU): 395.832  nodes: 119.989.867

hier wieder das selbe Spiel mit dem Ergebniss das der C2 395.79 kN/s bei 2GHz und 197,9 bei 1Ghz macht. (Zum Deterministisch kann man dann auch mal die Knoten bei Tiefe 20/50 vergleichen ... identisch!)

So, jetzt noch 218,7 / 197,9 geteilt und ich erhalte 1,105. Wenn man in meine List bei K10 reinsieht findet man 1.10 ...
(Wobei ich hier von Hand mit dem Taschenrechner gerechnet habe, und schon viel früher gerundet habe, der Fehler hier ist größer. In meinem Test habe ich solche Nachlässigkeiten wie die 8 Sekunden oben nicht aktzeptiert, sondern höchstens mal 1 Sekunde zu viel erlaubt.)

Auch wenn ich von dem Test überhaupt nichts halte, genau so macht es der Fritzbench. Er läuft eine Minute und zählt die Knoten. (Das macht er sogar bei mehreren Kernen, deswegen läuft er bei echten 2, 4, 6 Kernen auch ziemlich linear, was grundfalsch ist. Brrr)

Craftybench macht es umgekehrt, der geht zu einer bestimten Tiefe und mißt die Zeit, bei einer Singleegine ist das aber wie beim Autoverbrauch. L/100km ist das selbe die km/L ... Craftybench hat also nicht die N/s als Geschwindigkeitsindikator, sondern die s/N. Der Faktor sollte der selbe sein. Ich könnte den Test nochmal laufen lassen und je nach Engine immer eine bestimmte Tiefe annehmen und die Zeit messen. Das Ergebniss für den Geschwindigkeitszuwachs muß das selbe sein (Singleengine) sofern ich nicht bei sehr geringen Tiefen arbeite. Das Problem ist nur das man für jede Enigne andere Tiefen nehmen muß, der Aufwand ist viel größer.

Also, es geht nicht um Knoten bei Tiefe x, sondern wie viele Knoten absolut kann eine gegebene Enigne in 5 Minuten erreichen. Das ist mein Ausganswert von dem alles abhängt.

Gruß
Ingo
Parent - - By Ernest Bonnem Date 2011-07-10 22:34
OK Ingo, mit Deinem DS12 1T Beispiel, sind sie kN/s stabil.
Aber sowas habe ich nicht immer festgestellt... (ich komme wieder mit meinen Beispielen...   )
Parent - - By Ingo Bauer Date 2011-07-10 22:36 Edited 2011-07-10 22:39
[quote="Ernest Bonnem"]
OK Ingo, mit Deinem DS12 1T Beispiel, sind sie kN/s stabil.
Aber sowas habe ich nicht immer festgestellt... (ich komme wieder mit meinen Beispielen...   )
[/quote]

Ich bin gespannt, ein Bsp kenne ich , aber Konzeptionell hast du mit diesen Engines die selben Probleme bei Time to depth weil auch da jedesmal etwas anderes rauskommt.

Gruß
Ingo
Parent - - By Ingo Bauer Date 2011-07-10 23:15
[quote="Ingo Bauer"]

Ich bin gespannt, ein Bsp kenne ich ...

[/quote]

Da muß ich mich korrigieren. Die Engine die ich im Verdacht hat hat nur ein UCI Implementationsproblem (nach so vielen Jahren immer noch!). Die Anzeige ist falsch, das Ergebniss nicht.

Gespannt bin ich aber auf deine Bsp. (Für Komodo z.B muß man jedesmal die GUI neu starten, der löscht bei "Newgame" den Hash nicht. Das 'Problem', so es denn eins ist, dürften ein paar Engines haben).

Bis Morgen
Ingo
Parent - - By Frank Brenner Date 2011-07-10 23:40
Ingo, das Problem ist, dass eine Engine in den ersten 2 Minuten sagen wir X kn/s haben kann und dann aufeinmal in den letzten Minuten schneller wird.

Ursache ist, dass die kn/s sehr stark varrieren können - auch während einer einzelnen Zugberechnung -  je nach Anzahl Figuren und vom Stellungstyp und vor allem davon wieviel Figuren sich gegenseitig schlagen können.

Von dahe ist eine time-to-depth Messung ideal, wobei als Kontrolle die Gesamtzahl der Knoten stets gleich sein muss für eine Engine auf allen CPUs
Parent - By Ingo Bauer Date 2011-07-11 07:58 Edited 2011-07-11 08:06
Hallo Frank,

Zunächst mal, wir sprechen hier immer von Single-Engines. Für MP sieht das anders aus.

[quote="Frank Brenner"]
Ingo, das Problem ist, dass eine Engine in den ersten 2 Minuten sagen wir X kn/s haben kann und dann aufeinmal in den letzten Minuten schneller wird.
[/quote]

Das ist ein zweigeteiltes "Problem". Zum einen gemacht weil die GUIs (CB sei hier, Aufgrund seiner Verbreitung, als Bsp genannt) die vermeintliche Knotenleistung selber errechnet, und zu ANfang zum Teil einfach nicht nachkommen, zum anderen weil SEHR kurz am Anfang ein bischen initialisiert wird (1s, 2s?). Deswegen schau ich ja auch überhaupt nicht auf die angezeigten Knoten/s der GUI sondern NUR wie viele Knoten hat die Engine nach X (5) Minuten gemacht. Das ist WEIT von anfänglichen Initalisationen entfernt und ist deterministisch. Auch weicht das gerne von dem Ab was die GUI vorher angezeigt hat. Manche GUI ist da besser, andere schlechter. Gerne selber mal ausprobieren.

[quote="Frank Brenner"]
Ursache ist, dass die kn/s sehr stark varrieren können - auch während einer einzelnen Zugberechnung -  je nach Anzahl Figuren und vom Stellungstyp und vor allem davon wieviel Figuren sich gegenseitig schlagen können.
[/quote]

Ja, so etwas kann eine Ursache sein, natürlich verwende ich nicht verschiedene Stellungen als Startposition, sondern schlicht und einfach die Grundstellung. Das Ergebniss ist logisch nachvollziehbar. Sogar ob die CPUs in sich linear laufen, also ob das was ich bei 4 GHz messe analog bei 2.66GHz gilt, habe ich ausprobiert. Alle CPUs laufen schön linear auf gleicher CPU mit dem Takt rauf und runter. (Natürlich habe ich nicht irgendwelche irrelevanten extreme wie z.B 500 MHZ gemessen ...)

Sag mir deinen CPU Typ und, sofern ich ihn habe, ich sage dir wie viele Knoten/s eine Single-Engine in einem 5 Minuten Intervall mit 1GB Hash aus der Grundstellung gemacht hat. Du kannst natürlich auch meine Liste oben nehmen, die Faktoren benutzen und  das selber kontrolieren ob ich recht habe oder nicht!

[quote="Frank Brenner"]
Von daher ist eine time-to-depth Messung ideal, wobei als Kontrolle die Gesamtzahl der Knoten stets gleich sein muss für eine Engine auf allen CPUs
[/quote]

Natürlich sollte eine Single Engine deterministisch sein, und wenn bei Tiefe 5,10,20 immer die selben Knoten erreicht werden, das ganze linear mit dem Takt läuft (auf dem selben CPU Typ) dann ist es logisch das die Anzahl an Knoten auch für eine feste Zeit gilt. Probiere es selbt. Lasse eine beliebige Engine 10 mal 5 Minuten Rechnen und rechne dir selber die Knoten pro Sekunde aus ... immer rund die selbe (minimale Abweichungen Aufgrund des OS/GUI lags).
Bei einer MP Engine hast du recht. Einmal erreicht sie eine Tiefe schneller, einmal langsamer, einmal braucht sie 5Millionen Knoten, einmal 5.5 ... Single Engines sind anders. (oder sollten anders sein, wenn sie das nicht sind haben sie einen Bug)

Ich habe gestern nochmal rumprobiert (nur 5 Engines die ich in Verdadcht hatte), es gibt eine Engine die mir Sorgen bereitet, aber da liegt es an der UCI implementation. Ich bin gespannt welche Engine sich nicht deterministisch verhalten sollte. Das würde meinen Test obsolet machen - und den Fritzbench gleich mit, der macht das genau so, allerdings nur für EINE Engine!

Gruß
Ingo
Parent - - By Ernest Bonnem Date 2011-07-12 19:02
[quote="Ingo Bauer"][quote="Ernest Bonnem"]OK Ingo, mit Deinem DS12 1T Beispiel, sind sie kN/s stabil.
Aber sowas habe ich nicht immer festgestellt... (ich komme wieder mit meinen Beispielen...   )[/quote]
Ich bin gespannt, [/quote]
Also, hier sind manche Beispiele... (Fritz 11 GUI, die kN/s habe ich selbst kalkuliert...)
Die Grundstellung ist ja eine "ruhige" Stellung, so verändern sich die kN/s nicht so viel, aber doch manchmal 2-3-4%...

1 thread   512 MB hash
XP Pro x64
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
Analysis by Stockfish 2.1 JA 64bit:
1.e4 e6 2.Nf3 d5 3.exd5 exd5 4.d4 Nf6 5.Bd3 Nc6 6.0-0 Be7 7.Nc3 0-0 8.a3 a6 9.Re1 Be6 10.Bf4 Re8 11.Qd2 h6 12.Be5 Nxe5 13.Nxe5 c5 14.dxc5 Bxc5
  +/=  (0.28)   Depth: 25/33   00:01:51  106mN   955 kN/s
1.d4 Nf6 2.Nf3 d5 3.c4 e6 4.Nc3 Bb4 5.e3 c5 6.Bd3 dxc4 7.Bxc4 Nc6 8.0-0 0-0 9.a3 Ba5 10.Re1 Bd7 11.dxc5 Bxc3 12.bxc3 Qa5 13.e4 Qxc3
  +/=  (0.28)   Depth: 26/35   00:06:27  361mN   932

x64   1cpu   512MB hash
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
Analysis by Deep Rybka 4.1 x64:
1.e4 e5 2.Nf3 Nc6 3.Bb5 a6 4.Bxc6 dxc6 5.0-0 f6 6.d4 exd4 7.Nxd4 c5 8.Ne2 Qxd1 9.Rxd1 Bd7 10.Be3 0-0-0 11.Nbc3
  =  (0.19)   Depth: 18   00:00:57  5188kN
1.e4 e5 2.Nf3 Nc6 3.Bb5 a6 4.Bxc6 dxc6 5.0-0 f6 6.d4 exd4 7.Nxd4 c5 8.Ne2 Qxd1 9.Rxd1 Bd7 10.Be3 b6 11.Nd2 Ne7 12.Nc4 Nc6 13.a4 Nb4 14.Rd2 0-0-0
  =  (0.18)   Depth: 19   00:01:50  10261kN  93.3 kN/s
1.e4 e5 2.Nf3 Nc6 3.d4 exd4 4.Nxd4 Bc5 5.Be3 Qf6 6.c3 Nge7 7.Qf3 Qxf3 8.gxf3 Bb6 9.Nb5 Kd8 10.Nd2 Bxe3 11.fxe3 d6 12.Rg1 g6 13.Kf2 a6 14.Nd4 Ne5
  =  (0.17)   Depth: 20   00:04:14  24154kN   95.1
1.e4 e5 2.Nf3 Nc6 3.d4 exd4 4.Nxd4 Bc5 5.Be3 Qf6 6.c3 Nge7 7.Qf3 Qxf3 8.gxf3 Bb6 9.Rg1 Nxd4 10.Bxd4 Bxd4 11.cxd4 Nc6 12.Nd2 Nxd4 13.Rc1 c6 14.Rxg7 d6 15.Rc4 Ne6 16.Rg1
  =  (0.11)   Depth: 21   00:07:07  42247kN   98.9

XP Pro x64   1-cpu   512 MB Hash
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
Analysis by Houdini 1.5 x64 gtb:
1.e4 e5 2.Nf3 Nc6 3.Bb5 Nf6 4.0-0 Be7 5.Bxc6 dxc6 6.Nc3 Bg4 7.h3 Bxf3 8.Qxf3 0-0 9.d3 Qd6 10.Be3 Qe6 11.a3 Nd7 12.Rad1 a5 13.Rfe1
  =  (0.17)   Depth: 21/44   00:01:36  152mN   1583 kN/s
1.e4 e6 2.d4 d5 3.Nc3 Nf6 4.e5 Nfd7 5.Qg4 h5 6.Qf4 c5 7.Nf3 cxd4 8.Nb5 Nc6 9.Bd3 Nc5 10.0-0 Nxd3 11.cxd3 Bc5 12.Nbxd4 Nb4 13.Ng5 0-0
  =  (0.13)   Depth: 22/47   00:03:06  298mN   1602
1.e4 e6 2.d4 d5 3.Nc3 Nf6 4.Bg5 dxe4 5.Nxe4 Nbd7 6.Nf3 h6 7.Bxf6 Nxf6 8.Bd3 Be7 9.Qe2 0-0 10.Nxf6+ Bxf6 11.Qe4 g6 12.0-0 c5 13.c3 cxd4 14.Nxd4
  =  (0.14)   Depth: 23/53   00:04:54  473mN   1609

XP Pro x64   512MB   1 proc.
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
Analysis by Naum 4.2 64-bit:
1.d4 Nf6 2.Nc3 d5 3.Bf4 g6 4.Nf3 Bg7 5.h3 0-0 6.e3 Nh5 7.Bh2 Na6 8.Bd3 Nb4 9.0-0 Be6 10.Ng5
  =  (0.18)   Depth: 21/41   00:02:01  149mN   1231 kN/s
1.d4 Nf6 2.Nc3 d5 3.Bf4 g6 4.Nf3 Bg7 5.h3 0-0 6.e3 Nc6 7.Bd3 Nb4 8.0-0 Nxd3 9.cxd3 Bf5 10.g4 Bd7 11.Qb3 Bc6
  =  (0.17)   Depth: 22/43   00:03:25  254mN   1239
1.d4 Nf6 2.Nc3 d5 3.Bf4 g6 4.Nf3 Bg7 5.h3 0-0 6.e3 Nc6 7.Bd3 Nb4 8.0-0 Nxd3 9.cxd3 Bf5 10.g4 Bd7 11.Qb3
  =  (0.17)   Depth: 23/47   00:06:15  470mN   1253
1.d4 Nf6 2.Nc3 d5 3.Bf4 g6 4.h3 Bg7 5.e3 0-0 6.Nf3 Nc6 7.Bd3 Nb4 8.0-0 Nxd3 9.cxd3 c6 10.Qe2 Qa5 11.e4 Nh5 12.Bg5
  =  (0.17)   Depth: 24/50   00:14:47  1141mN  1286
Parent - By Ingo Bauer Date 2011-07-12 20:07 Edited 2011-07-12 20:10
Hallo Ernest,

Das sind jetzt 4 Enignes ein Lauf. Das sagt mir natürlich nichts. Aber Fritz GUI ist auch besonders schwer, weil sie eben nicht alles anzeigt was die Engine so liefert.

Trotzdem, angenommen es wären 4%, selbst dann dürfte bei einer größeren Anzahl an Engines die Gesammtabweichung minimal sein.

Gruß
Ingo
Parent - - By Benno Hartwig Date 2011-07-11 08:10
Thanx, eine interessante Aufstellung.
Ich hatte vermutet, dass in den Spalten i7toC2 bis i7toPh2 wenigstens so ungefähr gleiche Werte stehen (dass die Engines auf den einzelnen Prozessoren wenigstens so ungefähr gleich gut zurecht kommen).
Es fallen aber ein paar Werte ins Auge:
z.B. Spalte Ph2tpC2:    Naum 0,71    während Komodo 1,12 hat.
Bedeutet das wirklich (reproduzierbar), dass bei diesem Prozessorwechsel Komodo einen Geschwindigkeitsvorteil erhält von 112/71=1,58
("Ha, wenn Naum auch nur mit gleicher Geschwindigkeit weiterrechnet hat Kommodo aber die Geschwindigkeit um Faktor 1,58 gesteigert!")

Wirklich sooo sehr starke Effekte?

Benno
Parent - By Ingo Bauer Date 2011-07-11 08:24 Edited 2011-07-11 08:30
Hallo Benno

[quote="Benno Hartwig"]
Thanx, eine interessante Aufstellung.
Ich hatte vermutet, dass in den Spalten i7toC2 bis i7toPh2 wenigstens so ungefähr gleiche Werte stehen (dass die Engines auf den einzelnen Prozessoren wenigstens so ungefähr gleich gut zurecht kommen).
[/quote]

Nein, das tun sie nicht, allerdings ist der Durchschnitt über die 20 Engines gleich (+/- 1%)

[quote="Benno Hartwig"]
Es fallen aber ein paar Werte ins Auge:
z.B. Spalte Ph2tpC2:    Naum 0,71    während Komodo 1,12 hat.
Bedeutet das wirklich (reproduzierbar), dass bei diesem Prozessorwechsel Komodo einen Geschwindigkeitsvorteil erhält von 112/71=1,58
("Ha, wenn Naum auch nur mit gleicher Geschwindigkeit weiterrechnet hat Kommodo aber die Geschwindigkeit um Faktor 1,58 gesteigert!")

Wirklich sooo sehr starke Effekte?
[/quote]

Ja, ist aber ein Spezialfall.
1. Naum ist die schlechteste Engine auf Phenoms und
2. Komodo 2.03 DC läuft nicht auf C2. Den mußte ich durch die 2.03 JA Version ersetzen. An sich ist das legitim, bei Houdini geschieht es automatisch und SSE42 IST eine Eigenschaft die dem C2 fehlt (Pech gehabt) aber eigentlich sind diese zwei Versionen DC/JA auch zwei verscheidene Engines. Sie zeigen auf der selben CPU unterscheidliche HV. Weglassen wollte ich Komodo aber auch nicht, dafür ist die Engine zu wichtig in den Top 20. Der bessere Vergleich wäre Ph2toi7 weil da wirklich die selbe Engine läuft. 0.93/0.65=1.43. Nicht ganz so schlimm, aber immer noch deutlich! So deutlich das in einem reinen Enginevergleich eine Engine einen Vorteil, die andere einen Nachteil hätte (je nach Standpunkt und CPU - absolut ist da nichts ). Auch ein schönes Argument warum man nie, nie, nie aus Einzelmatchen Schlüsse ziehen sollte.

Mit ein Grund warum auch ein Benchmark mit einer Engine eine CPU bevorteilen oder benachteiligen kann. Deswegen nehme ich ja die besten 20 UCI Engines und den Mittelwert aus allen Engines. Wenn jemand jetzt NUR Naum oder NUR Komodo benutzen will nutzt ihm meine Liste allerdings nichts. Wer aber mehrere Engines probiert für den sollte sie schon einen Anhaltspunkt geben.

Deep Sjeng ist auch ein sehr schönes Bsp. Man sieht regelrecht auf welchen Systemen die Engine entwickelt wird! Es zeigt auch, das die Phenoms deutlich mehr Potenzial hätten, die meisten Entwickler kümmern sich nur nicht drum. Wenn sie es täten , würden die AMds dichter an die i7 rücken.

Gruß
Ingo
Parent - - By Benno Hartwig Date 2011-07-11 08:38
Hallo Ingo,

du errechnest dir Werte, die die Leistung einer Engine auf einem Prozessorkern bei 1GHz beschreiben.
Hast du mal getestet, wie verlässlich das ist?
Hast du mal Prozessoren aus der gleichen Serie mit unterschiedlichen Taktungen genommen und geguckt, ob diese 1GHz-Werte annähernd gleich sind?
Andere Faktoren wie 'Geschwindigkeit des Speicherzugriffs' könnten ja auch eine Rolle spielen.

Benno
Parent - By Ingo Bauer Date 2011-07-11 08:50 Edited 2011-07-11 08:57
Hallo Benno,

[quote="Benno Hartwig"]
du errechnest dir Werte, die die Leistung einer Engine auf einem Prozessorkern bei 1GHz beschreiben.
Hast du mal getestet, wie verlässlich das ist?
Hast du mal Prozessoren aus der gleichen Serie mit unterschiedlichen Taktungen genommen und geguckt, ob diese 1GHz-Werte annähernd gleich sind?
[/quote]

Kann ich alles mit 'Ja' beantworten. Für die Core 2 habe ich Daten bei 3GHz, 2.66Ghz und jetzt 2GHz, für den Phenom bei 2.8 und 3.25 und 3.6 GHz - absolut linear. Den i7 habe ich nicht getestet, ich sehe aber keinerlei Anhaltspunkte warum der nicht linear sein sollte.
Noch zum Linearverhalten der CPUs. Wenn man den Takt zu langsam macht, dann könnte es theoretische Abweichungen geben. Aber in dem Bereich in dem CPUs auch verkauft werden ist das unkritisch - nach oben wohl auch.

Du kannst es Aufgrund meiner Liste auch selber prüfen. Nimm deine CPU (ich nehme an eine der obigen hast du) errechne dir mit den Faktoren was bei deiner Geschwindigkeit rauskommen müßte - und mache einen Testlauf mit einer Engine deiner Wahl ...
Alternativ nenne du mir dein CPU (sofern ich sie habe) und Engine und ich sage dir wie viel Knoten/s sie nach 5 Minuten gemacht hat.

Interessant wäre, ob die neuen i -CPUs von Intel sich grundlegend anders verhalten als die "alten". Ich habe ja "nur" einen i920 ob diese neuen 1156 Sockel CPUs  (Intal hat leider die selbe Namensbezeichung gewählt) so viel anders sind? Wenn ich das richtig verstanden habe ist die interne CPU Architektur größtenteils gleich geblieben. Das selbe gilt für die neuen Lanos von AMD. Alter Wein in neuen Schläuchen ... Das nächst einteressante auf dem Markt wird wohl Buldozer werde.

[quote="Benno Hartwig"]
Andere Faktoren wie 'Geschwindigkeit des Speicherzugriffs' könnten ja auch eine Rolle spielen.
[/quote]

Speicherzugriff ist sekundär. Ich habe vor Jahren mal mit verschiednene Latenzen und Busgeschwindigkeiten rumprobiert. Schachengines sind alle zu langsam als das sie moderne Memorykontroller ausreizen. Die warten die meiste Zeit das die Engine etwas neues in den Hash schreiben will. Die Nachweisbarkeit ist kaum gegeben.

Gruß
Ingo
Parent - By Jörg Oster Date 2011-07-11 20:14
Hallo Ingo,

vielen Dank für diesen interessanten Vergleich.

Gruß,
Jörg.
Up Topic Hauptforen / CSS-Forum / Aktueller CPU Bench für Schachengines

Powered by mwForum 2.29.3 © 1999-2014 Markus Wichitill