Sehr treffend formuliert. Unterschreibe ich hiermit ebenfalls.

Gruß - Stefan

Der Umkehrschluß scheint aber auch berechtigt: Eine "Eindruckgewinnung" oder wie man es sonst nennen will über einige Dutzend Partien sagt auch schon was aus. Leider werden diese Postings hier gleich angefeindet, auch wenn der Begriff "Test" peinlichst vermieden wird.

Lese ich richtig?

"Ich lasse auf meinem Quadcore-Notebook sogar nur 3 Partien gleichzeitig laufen, damit Windoofs sich wohlfühlt und nicht reinstört. Und mit meinem Testtempo von 70"+700ms schaffe ich so ca. 1200 Partien in 24 Stunden. Ein 5000er Testrun dauert also gut 4 Tage. Ist doch kein Problem"

Du hast eines Quadcore-Prozessor mit VIER echten Kernen und lässt drei Partien gleichzeitig laufen? An jeder Partie sind zwei Programme beteiligt, die jeweils eines Kern benötigen. Das bedeutet, bei drei Partien gleichzeitig müssen zwei Programme auf die "Kerne" ausweichen, die durch Hyper-Threading "nachgebildet" werden und die nur eine Bruchteil der Leistung der echten Kerne haben. Das fällt nur deswegen nicht so auf, weil der Task-Scheduler von Windows immer bestrebt ist aktive Threads auf die richtigen Kerne zu legen und er darin ziemlich gut ist. Daher werden alle sechs Programme andauernd zwischen den vier Kernen hin und her geschoben. Wenn dann aus irgendwelchen Gründen ein Programm öfters (oder seltener) von einem echten Kern herunter geworfen wird, hast Du sofort verfälschte Messergebnisse ohne jede Chance, das später sauber zu reproduzieren.

Vielleicht war der Stockfisch vom 15.11. ja während seines Testlaufs auch nur besonders gut im "Kerne klammern"...

Stell Dir mal vor, Microsoft ändert bei einem Patchday (wie gerade heute) beim Abstellen einer Sicherheitslücke irgendwas am Task-Scheduler. Offiziell tun sie es ja nicht, aber willst Du Dich darauf verlassen?

Gruß Jens

Manche Engines sind bei timelosses stärker anfällig (Houdini 4 z.B.) als andere. Bei Komodo 8 kann man ja sogar einen Parameter verstellen, damit sich die Engine etwas Zeitpolster aufhebt und damit sozusagen einstellen, wie timeloss-anfällig sie ist. Gull ist von Hause aus eher robust.
Ich würde dennoch immer nur maximal soviele Partien laufen lassen, wie Cores vorhanden sind.

Was du noch probieren kannst: Du kannst im Taskmanager, nachdem du die LBG gestartet hast (aber noch nicht das Spiel mit dem Go-Button) bestimmten Prozessen einen oder mehrere Cores fix zuweisen. Du solltest im Taskmanager bei dir 4 Cores vorfinden, nämlich 0-3. Wobei Core 1 und 3 virtuelle Hyperthreading-Cores sind. Fixiere dort mal den LBG-process auf Core 0 und 2. Das schaltet das Hyperthreading de facto aus (übers BIOS geht es bei den meisten Notebooks nicht). Vielleicht gibts dann keine timelosses. Wenn es schon unbedingt4 Partien auf 2 Cores sein sollen. Aber ob das hilft, weiß ich nicht.
Andere Möglichkeit: Eine Kopie der LBG.exe zusätzlich starten, so daß 2 LBGs gleichzeitig laufen, und in jeder der beiden jeweils 2 Partien starten. Und ggf. jeder der LBG einen Core (0 bzw. 2) im Takmanager zuweisen.

Viel Spaß beim Rumprobieren. Seriöse Testarbeit würde ich so aber nicht machen. Da sollte es wei gesagt maximal eine Partie pro realem Core sein. Aber für ein paar über-Nacht-Tests just-for-fun kann man da sicer mal was anderes probieren. Die LBG ist für sowas prädestiniert, da extrem robust und "gutmütig".
Den Engine-procesesses, die die LBG startet, nachdem man Go gedrückt hat, kann man übrigens keine Cores zuweisen. Genauer: Man kann schon, aber die processe werden nach Partieende terminiert und neu processes gestartet, sodaß die Reservierung im Taskmanager dadurch wieder entschwindet...Also ist das de facto nicht möglich, bzw. nur für eine einzige Partie

Stefan