|
|
|||||||||||
AW: 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. [...] 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. 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. 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. 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 |
Folgende 3 Benutzer sagen Danke zu Beeco76 für den nützlichen Beitrag: | ||
|
||||||||||||
AW: Mephisto Phoenix London - Geschwindigkeitsvergleiche + Hash Tables
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. 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 |
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) |
![]() |
|
|
![]() |
||||
Thema | Erstellt von | Forum | Antworten | Letzter Beitrag |
Turnier: Mephisto Phoenix mit Mephisto Glasgow-Emulation | Egbert | Partien und Turniere / Games and Tournaments | 1965 | Gestern 20:38 |
Test: Mephisto IIIS Glasgow Phoenix | mclane | Partien und Turniere / Games and Tournaments | 108 | 01.04.2024 14:35 |
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 |