Zitat von
Mapi
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