Schachcomputer.info Community

Zurück   Schachcomputer.info Community > Schachcomputer / Chess Computer: > Die ganze Welt der Schachcomputer / World of chess computers


Antwort
 
Themen-Optionen Ansicht

  #1  
Alt 11.01.2023, 16:36
Benutzerbild von Chessguru
Chessguru Chessguru ist offline
Administrator
 
Registriert seit: 29.06.2004
Ort: Rostock
Alter: 55
Land:
Beiträge: 6.478
Bilder: 1
Abgegebene Danke: 1.589
Erhielt 4.594 Danke für 1.381 Beiträge
Member Photo Albums
Aktivitäten Langlebigkeit
10/20 20/20
Heute Beiträge
1/3 sssss6478
Mephisto Phoenix London - Geschwindigkeitsvergleiche + Hash Tables

Hallo,

ich bin verwirrt. Gut, werden die meisten User nun sagen, wissen wir, wo ist die Neuigkeit?

In den letzten Tagen habe ich mich ein wenig mit dem Mephisto Phoenix London beschäftigt. Partien gespielt, aber auch ein paar Geschwindigkeitsvergleiche durchgeführt. Was zur besagten Verwirrung geführt hat.

Bekanntlich bietet auch der Mephisto Phoenix London die Möglichkeit, größere Hash Tables (3 MB) zu aktivieren. Durch erneute Anwahl der London Emulation. Zu erkennen an der Anzeige „Mephisto London 3M“. Gleiches gilt auch für weitere Produkte (Reflection + Reflection II, Revelation II + AE) aus dem Hause Phoenix Chess System.

Über den Zweck von Hash Tables brauche ich wohl keine Worte verlieren. Grundsätzlich sollten diese ein Schachprogramm, insbesondere im Endspiel, deutlich beschleunigen.

Zu meiner Überraschung ist jedoch das Gegenteil, sowohl im Mephisto Phoenix London, aber auch im Reflection der Fall. Ähnlich, so vermute ich, wird sich auch der Revelation II verhalten.

Für die Geschwindigkeitsvergleiche hatte ich schon bei dem Erscheinen des Rev II Tests durchgeführt. Alwin hatte mich unterstützt und Werte für Turniermaschinen (68030 / 68040) beigesteuert.

Auf folgende Stellungen wurden die Geräte angesetzt:

Stellung 1:


1.g4 gewinnt, aber darum geht es nicht, sondern um die Zeit, bis eine bestimmte Rechentiefe erreicht wird.

Hier die Ergebnisse:

1. Weiß1. Weiß1. Weiß1. Weiß
Bib. AusBib. AusBib. AusBib. Aus
Hash anHash anHash anHash an
LondonTiefe 15Tiefe 16Tiefe 17Tiefe 18
min / sekmin / sekmin / sekmin / sek
Mephisto Phoenix244181210
Mephisto Phoenix 3 MB3594229456
Reflection II 1.7 GHZ4259133280
Reflection II 1.7 GHZ 3 MB59166351859
Reflection 1.5 GHz50133326647
TM 68040 80 MHz 2 MB70137275634
TM 68030 60 MHz 8 MB122195362850
Revelation II1383837391780


Die Unterschiede sind frappierend.

Die Emulation im Mephisto Phoenix basiert auf dem London 68000 und dieser hat 512 KB Hash an Bord. Mit 3 MB wird die Suche deutlich verlangsamt.

OK, zweiter Versuch.

Stellung 2:



1.f3

Ergebnisse:

1. Weiß1. Weiß1. Weiß
Bib. AusBib. AusBib. Aus
Hash anHash anHash an
LondonTiefe 7Tiefe 8Tiefe 9
min / sekmin / sekmin / sek
Mephisto Phoenix928180
Mephisto Phoenix 3 MB1032198
Reflection II 1.7 GHz1340271
Reflection 1.5 GHz1863379
TM 68040 80 MHz 2 MB30103611
Revelation II40121733
TM 68030 60 MHz 8 MB42130755


Auch in der Grundstellung zeigen sich deutliche Unterschiede. Nicht so gravierend wie in einer Endspielstellung, aber auch bei vollem Brett ist der Effekt erkennbar.


Ein letzter Versuch.

Dafür wurde die bekannte Stellung 4 aus den BT-Tests ausgewählt, die für unsere alten Kisten als (fast) unlösbar gilt. Einzig die V11, der Millennium ChessGenius Exclusive (bzw. ChessGenius Pro = gleiches Programm) sind in der Lage, den korrekten Zug 1.Df7! innerhalb der vorgesehenen 15 Minuten zu finden.

BT-2630 - 4
T.D. Harding, 1978


Für die Turniermaschine London (68030 / 36 MHZ / 2 MB) noch ein unlösbares Rätsel, so stellt diese Aufgabe für den Mephisto Phoenix London kein großes Problem dar. Aber auch in diesem Fall zeigt sich die genannte Hash Table Problematik.

Ergebnisse für 1.Df7:
Code:
Mephisto Phoenix London      - 191 Sekunden
Mephisto Phoenix London 3 MB - 274 Sekunden

Somit geht meine Bitte an Ruud, sich der Problematik anzunehmen.

Irgendetwas geht bei der Adressierung des größeren Hash-Speichers in die Hose.

Gruß
Micha

P.S.: Noch ein Nachtrag zu den Testergebnissen. Sämtliche Lang Programme, die mit Hash Tables unterwegs sind, zeigen immer wieder Differenzen bei der Testung. Also nicht wundern, solltet ihr leichte Abweichungen bei der Überprüfung feststellen. Mein Ansatz, der Test erfolgte immer nach dem Neustart des Programms.
Mit Zitat antworten
Folgende 8 Benutzer sagen Danke zu Chessguru für den nützlichen Beitrag:
applechess (11.01.2023), Beeco76 (12.01.2023), borromeus (22.11.2023), Chess Monarch (12.01.2023), Egbert (11.01.2023), Fluppio (11.01.2023), Oberstratege (11.01.2023), pato4sen (11.01.2023)
  #2  
Alt 11.01.2023, 17:48
Benutzerbild von Mapi
Mapi Mapi ist offline
Schachcomputer Koryphäe
 
Registriert seit: 25.04.2006
Ort: Bocholt
Alter: 59
Land:
Beiträge: 1.237
Abgegebene Danke: 6.216
Erhielt 2.043 Danke für 707 Beiträge
Aktivitäten Langlebigkeit
6/20 18/20
Heute Beiträge
1/3 sssss1237
AW: Mephisto Phoenix London - Geschwindigkeitsvergleiche + Hash Tables

Hallo Micha,

Ich glaube nicht, das Ruud da was ändern kann.
Die Emulationen laufen auf der Grundlage der 16 bit Module.
Der Zugriff auf den Hashtables Speicher läuft über einen 16 bit Datenbus, was nicht besonders schnell von statten geht.
Bei grossen Hashtables wird über den "langsamen" 16 bit Datenbus die kompletten 3 MB beschrieben und abgefragt, was die suche mit 3 Mb deutlich verlangsamt.
Würden die Emulationen auf 32 Bit Datenbusse zugreifen können würde das ganze mit einer wesentlich höheren Geschwindigkeit laufen.

Sehr schön zu sehen ist das bei dem de Koning Gerät Risc 2500.
ab 512 KB bis 2 Mb gibt es erst bei längeren Analysen richtig messbare Geschwindigkeitsvorteile.
Ansonsten sind die 2 MB Hash bei nicht so langen Analysen auch schlechter als mit 512 KB, nur halt nicht soviel, weil der Zugriff über den 32 bit Bus wesentlich flotter geht.
Daher nutze ich bei den Emulationen für Wettkämpfe mit den Lang Modulen auch nur 512 KB.

viele Grüße
Markus
Mit Zitat antworten
Folgende 9 Benutzer sagen Danke zu Mapi für den nützlichen Beitrag:
Beeco76 (12.01.2023), Bryan Whitby (11.01.2023), Chessguru (11.01.2023), Egbert (11.01.2023), Fluppio (11.01.2023), mickihamster (12.01.2023), Oberstratege (12.01.2023), pato4sen (11.01.2023), Wolfgang2 (11.01.2023)
  #3  
Alt 11.01.2023, 18:38
Benutzerbild von Egbert
Egbert Egbert ist offline
Lebende Foren Legende
 
Registriert seit: 20.12.2009
Ort: Dreieich
Alter: 59
Land:
Beiträge: 9.553
Abgegebene Danke: 13.920
Erhielt 16.420 Danke für 6.395 Beiträge
Member Photo Albums
Aktivitäten Langlebigkeit
14/20 15/20
Heute Beiträge
1/3 sssss9553
AW: Mephisto Phoenix London - Geschwindigkeitsvergleiche + Hash Tables

Vielen Dank Micha, für das Teilen der auch für mich überraschenden Erkenntnisse und auch besten Dank an Markus für die durchaus nachvollziehbare Erläuterung. Die logische Konsequenz daraus hat Markus bereits erwähnt und so werde ich ich es auch in Zukunft halten:

Zitieren:
...Daher nutze ich bei den Emulationen für Wettkämpfe mit den Lang Modulen auch nur 512 KB.
Schade, aber offenbar nicht zu ändern.

Gruß
Egbert
Mit Zitat antworten
  #4  
Alt 11.01.2023, 18:52
Benutzerbild von Chessguru
Chessguru Chessguru ist offline
Administrator
 
Registriert seit: 29.06.2004
Ort: Rostock
Alter: 55
Land:
Beiträge: 6.478
Bilder: 1
Abgegebene Danke: 1.589
Erhielt 4.594 Danke für 1.381 Beiträge
Member Photo Albums
Aktivitäten Langlebigkeit
10/20 20/20
Heute Beiträge
1/3 sssss6478
AW: Mephisto Phoenix London - Geschwindigkeitsvergleiche + Hash Tables

Hallo Markus,

 Zitat von Mapi Beitrag anzeigen
Ich glaube nicht, das Ruud da was ändern kann.
Die Emulationen laufen auf der Grundlage der 16 bit Module.
Der Zugriff auf den Hashtables Speicher läuft über einen 16 bit Datenbus, was nicht besonders schnell von statten geht.
Bei grossen Hashtables wird über den "langsamen" 16 bit Datenbus die kompletten 3 MB beschrieben und abgefragt, was die suche mit 3 Mb deutlich verlangsamt.
ok, deine Erläuterung klingt durchaus logisch. Die Frage wäre, ab wann kippt das Verhalten? Sind die 512KB bereits das sinnvolle Maximum?

Allerdings würde daraus folgen, dass man diese Speichererweiterung wieder entfernen sollte, da sie keinen praktischen Nutzen in sich trägt. Im Gegenteil, sie suggeriert einen deutlichen Zugewinn, der im praktischen Spiel nicht vorhanden ist. Schlimmer sogar, es bewirkt eine Verschlechterung der Spielstärke. Oder zumindest sollte es im Manual entsprechend vermerkt werden.

Gruß
Micha
Mit Zitat antworten
Folgende 2 Benutzer sagen Danke zu Chessguru für den nützlichen Beitrag:
Chess Monarch (12.01.2023), Egbert (11.01.2023)
  #5  
Alt 11.01.2023, 18:57
Hartmut Hartmut ist offline
Lebende Foren Legende
 
Registriert seit: 01.04.2010
Ort: Nürnberg
Alter: 60
Land:
Beiträge: 2.173
Abgegebene Danke: 3.211
Erhielt 1.543 Danke für 897 Beiträge
Aktivitäten Langlebigkeit
3/20 14/20
Heute Beiträge
0/3 sssss2173
AW: Mephisto Phoenix London - Geschwindigkeitsvergleiche + Hash Tables

 Zitat von Mapi Beitrag anzeigen
...Sehr schön zu sehen ist das bei dem de Koning Gerät Risc 2500.
ab 512 KB bis 2 Mb gibt es erst bei längeren Analysen richtig messbare Geschwindigkeitsvorteile.
Ansonsten sind die 2 MB Hash bei nicht so langen Analysen auch schlechter als mit 512 KB, nur halt nicht soviel, weil der Zugriff über den 32 bit Bus wesentlich flotter geht....
Die Frage ist halt... wie lange dauert es bei den (im Vergleich zu heutigen PC-Programmen) langsamen Geräten bis der Hash-Speicher vollgeschrieben ist und entsprechend wirken kann. Auch bei einem Stockfish auf dem PC (mit dort zugegeben 8-16 GB Hash) dauert es eine ganze Zeit bis der Hash überhaupt wirken kann und der Wert für die NPS nach oben geht. In einer aktuellen Fernschachpartie musste ich das Teil ca. 1 h analysieren lassen bis der Hash überhaupt voll war. Danach ging die Geschwindigkeit nach oben. Nun haben zwar unsere Oldies weit weniger Hash als ein PC, sind aber eben auch weit langsamer. Interessant wäre es die Sache zu beobachten, indem man die Programme weit länger rechnen läßt (auf Analysestufe 1 h aufwärts) und dann die Werte vergleicht. (Also in jedem der genannten Beispiele gut 2 Halbzüge tiefer). Ich denke dass bei den meisten unserer Oldies der Hash allenfalls bei ganz einfachen Endspielstellungen irgendwas bringt. In einer normalen Schnellpartie oder auch bei Turnierpartien dürfte er eher ein Klotz am Bein sein...
__________________
Mein Profil beim ICCF (International Correspondence Chess Federation)
https://www.iccf.com/player?id=89948&tab=3
Mit Zitat antworten
Folgender Benutzer sagt Danke zu Hartmut für den nützlichen Beitrag:
Egbert (11.01.2023)
  #6  
Alt 11.01.2023, 19:52
Beeco76 Beeco76 ist offline
Mephisto Montreux
 
Registriert seit: 23.03.2020
Beiträge: 254
Abgegebene Danke: 1.313
Erhielt 409 Danke für 179 Beiträge
Aktivitäten Langlebigkeit
0/20 4/20
Heute Beiträge
0/3 ssssss254
AW: Mephisto Phoenix London - Geschwindigkeitsvergleiche + Hash Tables

 Zitat von Chessguru Beitrag anzeigen
Hallo,

ich bin verwirrt. Gut, werden die meisten User nun sagen, wissen wir, wo ist die Neuigkeit?

In den letzten Tagen habe ich mich ein wenig mit dem Mephisto Phoenix London beschäftigt. Partien gespielt, aber auch ein paar Geschwindigkeitsvergleiche durchgeführt. Was zur besagten Verwirrung geführt hat.

[...]

Ergebnisse für 1.Df7:
Code:
Mephisto Phoenix London      - 191 Sekunden
Mephisto Phoenix London 3 MB - 274 Sekunden

Somit geht meine Bitte an Ruud, sich der Problematik anzunehmen.

Irgendetwas geht bei der Adressierung des größeren Hash-Speichers in die Hose.

Gruß
Micha

P.S.: Noch ein Nachtrag zu den Testergebnissen. Sämtliche Lang Programme, die mit Hash Tables unterwegs sind, zeigen immer wieder Differenzen bei der Testung. Also nicht wundern, solltet ihr leichte Abweichungen bei der Überprüfung feststellen. Mein Ansatz, der Test erfolgte immer nach dem Neustart des Programms.
Hallo Micha,

AFAIK basieren die Emulationen auf dem Motorola 68000.

Dieser hat nur intern 32bit, nutzt aber nach außen nur 24bit:

Zitieren:
As you know, the 68000 has a 32 bit Program Counter and 32 bit address registers.
[...]
the 68000 behaves as if its addresses are 24 bit quantities, not 32 bit quantities. That means that the addressable memory space of the 68000 is in practice only 224 bytes, or 16 megabytes. Note that addresses in the 68000 are still represented as and stored as 32 bit numbers, even if only the first 24 bits of those numbers are actually used.

This limitation does not exist with the newer members of the 68000 family. The 68020, 68030 and 68040 have a fully connected 32 bit address bus and a true
address space of 4 gigabytes.
Quelle und nähere technische Details:
https://www.cs.mcgill.ca/~cs573/fall...c273/lecture9/

Vielleicht ist es mühsamer die Register mit "24bit-Happen" zu füttern als es intern wieder selbst auszurechnen.

Das erklärt jedoch nicht die Unterschiede bei den echten 32bit CPUs.

MOVE-Befehle haben ein Suffix, wie viele bit auf einmal transportiert werden:

B = 8bit
W = 16bit
L = 32bit

Die Frage, die sich mir stellt, ist, ob der Programmcode bei den 32bit-CPUs für 32bit optimiert wurde, also Verwendung von:
MOVE.L

Die internen Rechenbefehle (ADD, SUB, etc.) können auf den Registern auch beim 68000er in einem Zyklus ausgeführt werden.

Daher vermute ich, dass einfach der gleiche Assemblercode wie beim 68000er verwendet wurde und
dieser viele MOVE.B-Befehle enthält, d.h. wir schaufeln immer noch mit 16-bit Eimern die Daten hin und her.

Eine Takterhöhung sagt nur aus, dass schneller mit 16bit-Eimern geschaufelt wird.

Wie gesagt, das ist nur eine Vermutung. Daher würden mich eure Kommentare interessieren.


Viele Grüße
Markus

Ergänzung: Eine andere Quelle berichtet über einen 16bit-Bus, beschreibt aber die Operationen auf dem Speicher in Kurzform:

Zitieren:
The 68000 processor has a rather orthogonal and powerful instruction set with core instructions supporting different addressing modes (direct to/from register, indirect with address register
with and without index etc.) and working on either 8, 16 or 32 bit of data.
Address calculations of the addressing modes are always 32 bit.

The data bus of 16 bit is only relevant when external memory is read or written. The data sheet
contains a lot of information about how many reads and writes occur given an instruction and its
address mode.

A simplified view is:

16 bit reads and writes are easy as they directly match the data bus width.
32 bit reads and writes require two reads / two writes on the bus. The data sheet doesn't say in which order they occur.
For 8 bit reads and writes, the processor indicates on a pin if the upper or lower byte should be read.

When multiple reads are required, the instruction is not executed until all the reads have completed.
So from a programmer's view, you don't ever see that the bus is only 16 bit (or 8 bit for the 68008). The programming model is simple and consistent. The same goes for writes and 8 bit operations.
Quelle: https://electronics.stackexchange.co...on-32-bit-data

Außerdem müssen wir auch bedenken, dass der Registerspeicher schneller ist als der Hauptspeicher.

Geändert von Beeco76 (11.01.2023 um 20:04 Uhr) Grund: Ergänzung
Mit Zitat antworten
Folgende 3 Benutzer sagen Danke zu Beeco76 für den nützlichen Beitrag:
Bryan Whitby (11.01.2023), Egbert (11.01.2023), Oberstratege (12.01.2023)
  #7  
Alt 11.01.2023, 20:08
Benutzerbild von Mickey1259
Mickey1259 Mickey1259 ist offline
Novag Savant
 
Registriert seit: 30.10.2019
Ort: Niedernberg, Unterfranken
Land:
Beiträge: 26
Abgegebene Danke: 22
Erhielt 56 Danke für 16 Beiträge
Aktivitäten Langlebigkeit
1/20 5/20
Heute Beiträge
0/3 sssssss26
AW: Mephisto Phoenix London - Geschwindigkeitsvergleiche + Hash Tables

 Zitat von Mapi Beitrag anzeigen
Hallo Micha,

Ich glaube nicht, das Ruud da was ändern kann.
Die Emulationen laufen auf der Grundlage der 16 bit Module.
Der Zugriff auf den Hashtables Speicher läuft über einen 16 bit Datenbus, was nicht besonders schnell von statten geht.
Bei grossen Hashtables wird über den "langsamen" 16 bit Datenbus die kompletten 3 MB beschrieben und abgefragt, was die suche mit 3 Mb deutlich verlangsamt.
Würden die Emulationen auf 32 Bit Datenbusse zugreifen können würde das ganze mit einer wesentlich höheren Geschwindigkeit laufen.

Sehr schön zu sehen ist das bei dem de Koning Gerät Risc 2500.
ab 512 KB bis 2 Mb gibt es erst bei längeren Analysen richtig messbare Geschwindigkeitsvorteile.
Ansonsten sind die 2 MB Hash bei nicht so langen Analysen auch schlechter als mit 512 KB, nur halt nicht soviel, weil der Zugriff über den 32 bit Bus wesentlich flotter geht.
Daher nutze ich bei den Emulationen für Wettkämpfe mit den Lang Modulen auch nur 512 KB.

viele Grüße
Markus
Hallo,

Diese Erklärung bedeutet, dass die Emulationen jeden Befehl zyklusgenau emulieren. Der 68000 besitzt durchaus Instruktionen, die 32 Bits mit einem Befehl laden bzw. speichern können. Der PI-Prozessor läuft je nach drunterliegendem Betriebssystem im 32- oder 64-Bit-Modus. Daher könnte die Emulation auch mit 32 Bit auf den Hash-Speicher zugreifen, vorausgesetzt die passenden Befehle werden benutzt. Der 68000 ist nach außen ein 16-Bit-Rechner, aber intern 32 Bit. Ein Befehl, der ein 32-Bit-Register aus dem Speicher lädt, braucht auf realer Hardware tatsächlich zwei Speicherzugriffe, könnte aber in einer Emulation durchaus schneller sein. Man würde damit natürlich auch das Zeitverhalten der emulierten SW ändern. Wenn man die Emulation aber schon beschleunigt, dann könnte man auch durchaus solche Dinge beschleunigen. Man kann natürlich nichts ändern, wenn das Programm nur 16-Bit-Transfers benutzt, dann würde ich aber sagen: Schlecht programmiert, und das glaube ich bei Richard Lang nicht.

Wenn man eine Analyse nach dem Aufbau einer Stellung macht, also nach einem Neustart der Emulation, dann sind die Hashtables auch gelöscht. Ich denke der Geschwindigkeitsvorteil kommt auch erst nach einer längeren Analyse, wenn die Tables voll sind. Vorher muss ja für jede Stellung erstmal ohne die Tables die Hash-Einträge erzeugt werden und gespeichert werden, was auch Zeit benötigt. Erst wenn man bei der weiteren Analyse auf einen passenden Hash-Eintrag stößt, dann kann man an der Stelle abbrechen, weil man dann ja die Bewertung schon kennt. Ein vernünftiger Hash-Algorithmus muss um den passenden Eintrag zu finden i. A. nicht die gesamte Tabelle durchsuchen, sondern weiß anhand des Hashwertes wo der Eintrag ist. Deshalb ist das Füllen des Hashs das Zeitraubende und nicht das spätere Durchsuchen. Und ein größerer Hash braucht natürlich länger bis er gefüllt ist.

Interessant wäre sicher, ob reale Geräte auch dieses Verhalten zeigen.

Viele Grüße und ein gesundes neues Jahr
Michael
Mit Zitat antworten
Folgende 6 Benutzer sagen Danke zu Mickey1259 für den nützlichen Beitrag:
Beeco76 (11.01.2023), Bryan Whitby (11.01.2023), Chess Monarch (12.01.2023), Egbert (11.01.2023), Mapi (11.01.2023), Oberstratege (12.01.2023)
  #8  
Alt 11.01.2023, 20:16
Beeco76 Beeco76 ist offline
Mephisto Montreux
 
Registriert seit: 23.03.2020
Beiträge: 254
Abgegebene Danke: 1.313
Erhielt 409 Danke für 179 Beiträge
Aktivitäten Langlebigkeit
0/20 4/20
Heute Beiträge
0/3 ssssss254
AW: Mephisto Phoenix London - Geschwindigkeitsvergleiche + Hash Tables

 Zitat von Mickey1259 Beitrag anzeigen
Hallo,

Diese Erklärung bedeutet, dass die Emulationen jeden Befehl zyklusgenau emulieren. Der 68000 besitzt durchaus Instruktionen, die 32 Bits mit einem Befehl laden bzw. speichern können. Der PI-Prozessor läuft je nach drunterliegendem Betriebssystem im 32- oder 64-Bit-Modus. Daher könnte die Emulation auch mit 32 Bit auf den Hash-Speicher zugreifen, vorausgesetzt die passenden Befehle werden benutzt. Der 68000 ist nach außen ein 16-Bit-Rechner, aber intern 32 Bit. Ein Befehl, der ein 32-Bit-Register aus dem Speicher lädt, braucht auf realer Hardware tatsächlich zwei Speicherzugriffe, könnte aber in einer Emulation durchaus schneller sein. Man würde damit natürlich auch das Zeitverhalten der emulierten SW ändern. Wenn man die Emulation aber schon beschleunigt, dann könnte man auch durchaus solche Dinge beschleunigen. Man kann natürlich nichts ändern, wenn das Programm nur 16-Bit-Transfers benutzt, dann würde ich aber sagen: Schlecht programmiert, und das glaube ich bei Richard Lang nicht.

Wenn man eine Analyse nach dem Aufbau einer Stellung macht, also nach einem Neustart der Emulation, dann sind die Hashtables auch gelöscht. Ich denke der Geschwindigkeitsvorteil kommt auch erst nach einer längeren Analyse, wenn die Tables voll sind. Vorher muss ja für jede Stellung erstmal ohne die Tables die Hash-Einträge erzeugt werden und gespeichert werden, was auch Zeit benötigt. Erst wenn man bei der weiteren Analyse auf einen passenden Hash-Eintrag stößt, dann kann man an der Stelle abbrechen, weil man dann ja die Bewertung schon kennt. Ein vernünftiger Hash-Algorithmus muss um den passenden Eintrag zu finden i. A. nicht die gesamte Tabelle durchsuchen, sondern weiß anhand des Hashwertes wo der Eintrag ist. Deshalb ist das Füllen des Hashs das Zeitraubende und nicht das spätere Durchsuchen. Und ein größerer Hash braucht natürlich länger bis er gefüllt ist.

Interessant wäre sicher, ob reale Geräte auch dieses Verhalten zeigen.

Viele Grüße und ein gesundes neues Jahr
Michael
Hallo Michael,

ich habe Stockfish auf dem PC mal ganze 8GB Hauptspeicher als Hash gegeben und das Durchsuchen des vollen Speichers hat beim "Herunterklettern in eine höhere Suchtiefe" keine Verbesserung gebracht, sondern war eher langsamer als z.B. 1GB Hash.

Viele Grüße
Markus
Mit Zitat antworten
  #9  
Alt 11.01.2023, 20:32
Benutzerbild von Mickey1259
Mickey1259 Mickey1259 ist offline
Novag Savant
 
Registriert seit: 30.10.2019
Ort: Niedernberg, Unterfranken
Land:
Beiträge: 26
Abgegebene Danke: 22
Erhielt 56 Danke für 16 Beiträge
Aktivitäten Langlebigkeit
1/20 5/20
Heute Beiträge
0/3 sssssss26
AW: Mephisto Phoenix London - Geschwindigkeitsvergleiche + Hash Tables

 Zitat von Beeco76 Beitrag anzeigen
Hallo Micha,

AFAIK basieren die Emulationen auf dem Motorola 68000.

Dieser hat nur intern 32bit, nutzt aber nach außen nur 24bit:



Quelle und nähere technische Details:
https://www.cs.mcgill.ca/~cs573/fall...c273/lecture9/

Vielleicht ist es mühsamer die Register mit "24bit-Happen" zu füttern als es intern wieder selbst auszurechnen.

Das erklärt jedoch nicht die Unterschiede bei den echten 32bit CPUs.

MOVE-Befehle haben ein Suffix, wie viele bit auf einmal transportiert werden:

B = 8bit
W = 16bit
L = 32bit

Die Frage, die sich mir stellt, ist, ob der Programmcode bei den 32bit-CPUs für 32bit optimiert wurde, also Verwendung von:
MOVE.L

Die internen Rechenbefehle (ADD, SUB, etc.) können auf den Registern auch beim 68000er in einem Zyklus ausgeführt werden.

Daher vermute ich, dass einfach der gleiche Assemblercode wie beim 68000er verwendet wurde und dieser viele MOVE.B-Befehle enthält, d.h. wir schaufeln immer noch mit 16-bit Eimern die Daten hin und her.

Eine Takterhöhung sagt nur aus, dass schneller mit 16bit-Eimern geschaufelt wird.

Wie gesagt, das ist nur eine Vermutung. Daher würden mich eure Kommentare interessieren.


Viele Grüße
Markus

Ergänzung: Eine andere Quelle berichtet über einen 16bit-Bus, beschreibt aber die Operationen auf dem Speicher in Kurzform:



Quelle: https://electronics.stackexchange.co...on-32-bit-data

Außerdem müssen wir auch bedenken, dass der Registerspeicher schneller ist als der Hauptspeicher.
Hallo Markus,

ich habe jahrelang 68000-Geräte programmiert. Der 68000 ist ein 16/32-Bit-Mix-Prozessor, d.h. er arbeitet intern mit 32 Bit und nach außen schaufelt er die Daten mit 8 Bit oder 16 Bit, je nach verwendetem Befehl. Die 24 Bits beziehen sich nur auf den nach außen geführten Adressbus, d.h. sie bestimmen, wieviel Speicher adressiert werden kann. Es wird also nicht in "24-Bit Happen" sondern in "16 Bit-Happen" geschaufelt, und zweimal 16 Bit zu 32 Bit zusammenzusetzen ist einfach. 32-Bit-Befehle brauchen länger, weil durch den 16-Bit-Bus die eben in zwei "Happen" aufgeteilt werden müssen. Bei den Nachfolgern 68020, 68030, 68040 ist das nicht so, die können mit tatsächlichen 32-Bit-Happen arbeiten.

Aus meiner Sicht erklärt die Bus-Breite nicht unbedingt den großen Zeitunterschied. Denn prozentual müsste der sich auch mit einer 32-Bit-Hardware so ergeben. Wenn ich einen 1 KByte Speicher mit 16-Bit-Happen fülle, dann brauche ich eine gewisse Zeit, mit 32-Bit-Happen eben nur die Hälfte. Bei einem 2KByte-Speicher brauche ich in beiden Fällen die doppelte Zeit. D.h. ein 32-Bit-System kann den Speicher schneller füllen, jedoch sollte eine Verdopplung in beiden Fällen prozentual einen ähnlichen Zeitzuwachs ergeben.

Noch eine Bemerkung zu den Hash-Tabellen. Wenn man nach dem Neustart anfängt zu analysieren, dann muss die Tabellen ja erstmal gefüllt werden, d.h. die Analyse braucht länger. Bei den nächsten Zügen, die dann ausgeführt werden, kann man eine Menge Zeit einsparen, denn man wird dann ja auch einen Großteil der zu analysierenden Stellungen schon im Hash finden. Deshalb hat man im Endspiel tatsächlich Vorteile, die sich aber erst wirklich bemerkbar machen, wenn das Endspiel schon eine Vorgeschichte hatte.

Viele Grüße
Michael
Mit Zitat antworten
Folgende 5 Benutzer sagen Danke zu Mickey1259 für den nützlichen Beitrag:
Beeco76 (11.01.2023), Bryan Whitby (11.01.2023), Egbert (12.01.2023), Mapi (11.01.2023), Oberstratege (12.01.2023)
  #10  
Alt 11.01.2023, 20:45
Benutzerbild von Mickey1259
Mickey1259 Mickey1259 ist offline
Novag Savant
 
Registriert seit: 30.10.2019
Ort: Niedernberg, Unterfranken
Land:
Beiträge: 26
Abgegebene Danke: 22
Erhielt 56 Danke für 16 Beiträge
Aktivitäten Langlebigkeit
1/20 5/20
Heute Beiträge
0/3 sssssss26
AW: Mephisto Phoenix London - Geschwindigkeitsvergleiche + Hash Tables

 Zitat von Beeco76 Beitrag anzeigen
Hallo Michael,

ich habe Stockfish auf dem PC mal ganze 8GB Hauptspeicher als Hash gegeben und das Durchsuchen des vollen Speichers hat beim "Herunterklettern in eine höhere Suchtiefe" keine Verbesserung gebracht, sondern war eher langsamer als z.B. 1GB Hash.

Viele Grüße
Markus
Hallo Markus,

Ich hatte ja geschrieben, dass ein vernünftiger Hash-Algorithmus weiß, wo der Eintrag für einen Hashwert ist. Das benötigt jedoch Verwaltungsaufwand, und je größer der Hash ist, ist der Aufwand auch größer. Deshalb sind die Zeiten, die Micha gemessen hat, auch nicht 6 mal so lang (das wäre das Verhältnis von 512K zu 3M). Irgendwann gibt es zwischen Verwaltung und der Größe des Speichers einen Break-Even, wo also der Zeitvorteil wieder kleiner wird. Dieser hängt vom System ab, man kann da also keinen exakten Wert für alle Systeme angeben. Wenn das Verwalten länger braucht als die Analyse, dann hat man natürlich sogar einen Zeitnachteil.

Und hast Du auch mehrere Züge gemacht, denn der Hash profitiert eben auch von der Vergangenheit?

Viele Grüße
Michael
Mit Zitat antworten
Folgende 2 Benutzer sagen Danke zu Mickey1259 für den nützlichen Beitrag:
Beeco76 (12.01.2023), Egbert (12.01.2023)
Antwort

Themen-Optionen
Ansicht

Forumregeln
Du bist nicht berechtigt, neue Themen zu erstellen.
Du bist nicht berechtigt, auf Beiträge zu antworten.
Du bist nicht berechtigt, Anhänge hochzuladen.
Du bist nicht berechtigt, deine Beiträge zu bearbeiten.

BB code ist An
Smileys sind An.
[IMG] Code ist An.
HTML-Code ist An.

Gehe zu

Ähnliche Themen
Thema Erstellt von Forum Antworten Letzter Beitrag
Test: Mephisto IIIS Glasgow Phoenix mclane Partien und Turniere / Games and Tournaments 94 27.03.2024 23:00
Turnier: Mephisto Phoenix mit Mephisto Glasgow-Emulation Egbert Partien und Turniere / Games and Tournaments 1864 24.02.2024 20:34
Test: London Mephisto Phoenix vs CT800 PeWa Grandmaster pato4sen Partien und Turniere / Games and Tournaments 17 11.01.2023 23:09
Frage: Hash for DCCs IvenGO Die ganze Welt der Schachcomputer / World of chess computers 11 25.02.2014 20:43


Alle Zeitangaben in WEZ +1. Es ist jetzt 11:10 Uhr.



Powered by vBulletin (Deutsch)
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
©Schachcomputer.info