Hab ma reingeschaut, eine 68030 TM in WM-Version hat:
1 SRAM 150ns Zugriffszeit 8 kByte zur dauerhaften Speicherung Einstellungen/Partien (sonst im Display)
64 üblich schnelle DRAM mit 70ns Zugriffszeit und insgesamt 8 MByte
8 extrem schnelle SRAMs mit 25ns Zugriffszeit und insgesamt 256 kByte

Der schnelle SRAM scheint im Wiki nicht konkret erwähnt zu werden. Auch die Anzeige im Display zählt diesen RAM nicht mit. Könnte das L2 Cache sein? Gab es sowas beim 68030?

Wies im 68020 ausschaut, kann ich heut abend mal schauen. Ich meine aber mich zu erinnern, dass auch hier 2 unterschiedliche Arten RAM verbaut sind.

Nachtrag:

Zeiten mit eingeschalteten HT:

Mephisto London 68030 /33 MHz 21 Sekunden
Mephisto London 68020 /12 MHz 58 Sekunden

Der Prorammspeicher (ROM) beträgt 256 KB bei Vancouver und Genius. Wer hat wieviel HT oder sonstigen RAM ?
Meiner Ansicht ist es so (in KB):

Vancouver 68000: 512 HT, 256 RAM
Vancouver 68020: 1024 HT, 256 RAM
Genius 68030: 512 HT, 256 RAM (Quelle: CSS 5/94)

Das heißt: Zunächst (bis 1991) wurde nur der "werbewirksame" Hashtable-Speicher angegeben. Und beim Genius 68030 hat man dann den sonstigen RAM-Speicher mit dazu gezählt.

Gruß
Wolfgang

In das schnelle SRAM könnte einfach der Inhalt der ROMs kopiert werden.

Ja, das wäre eine Idee. Möglicherweise muss das sogar so passieren, da nur ein einziges 8 Bit Eprom verwendet wurde. Das heißt, mit einem Zugriff ständen nur 8 Bit zur Verfügung.

Ich habe zu L2 Cache bei Motorola auch nichts gefunden, bei Intel war es ja mehr oder weniger Standard...

Ich schau mal heut Abend in Van 68000 und Van 68020 rein und schreib die Werte hier mit hin. Im Wiki könnte man die konkreten Werte dann im Fließtext erwähnen.

Hallo Wolfgang,

ich habe gerade mal einen neuen Versuch gestartet
1. a4 Sf6
2. a5
ohne Hash Tiefe 6

1. Versuch
68030 33 Mhz 46 sek mit 2...e5
68020 12 Mhz 132 sek mit 2...Sc6
ergibt einen Faktor von 2,86 also wieder kein grosser Unterschied

2. Versuch
68030 33 Mhz 46 sek mit 2...e5
68020 12 Mhz 132 sek mit 2...Sc6

Faktor wie Versuch 1.

nun das ganze nochmal mit Hash

1. Versuch
68030 33 Mhz 19 sek mit 2...Sc6
68020 12 Mhz 55 sek mit 2.. Sc6

Faktor 2,89

2. Versuch
68030 33 Mhz 20 sek mit 2. ...Sc6
68020 12 Mhz 74 sek mit 2. ....e5
Faktor 3,7

mein erstes Fazit
Anscheinend sind laut Programmstruktur 2...Sc6 und 2...e5 gleichwertig und je nachdem in welchem Zweig vom Baum gerechnet wird, ändern sich da die Zeiten, weil unterschiedlich viel gerechnet werden muss. Bei gleicher Antwort sind der 68020 und der 68030 bei gleicher Mhz Zahl nahezu gleich schnell.
Diesen Eindruck hatte ich auch seinerzeit beim testen mit verschiedenen Teststellungen. Da habe ich jede Stellung mehrmals durchrechnen lassen, weil es teils erhebliche Unterschiede in den Lösungszeiten gab, evtl, ist das immer dann der Fall, wenn es für das Programm laut seinen Berechnungen mehrere ähnlich gute Züge zur Auswahl gab.

viele Grüße
Markus

Hallo Markus,
Danke für Deine Erkenntnisse. Für mich gilt grundsätzlich bei derartigen Tests:
1. Permanent Brain aus
2. Zufallsgenerator aus
3. Hohe Spielstufe

und: Das erste Ergebnis zählt!

Speziell bei den RL-Programmen ist es meines Erachtens ein "Muss", dass man stets mit klaren, einheitlichen Verhältnissen (garantiert leerem Speicher) starten muss.
Beispiel: Bei einer eingegebenen Studie, die ich mehrmals rechnen lasse, gehe ich vor jedem Start in das Setup der Stellung, lösche eine Figur, setzte diese dann wieder ein. Und starte dann erst.

Ich sehe aber jetzt keine so große Diskrepanz in unseren Ergebnissen. In erster Linie ist Dein 68020-er wohl ein paar Prozentpunkte schneller als meiner.

Der 030 hatte gegenüber dem 020 nur 256 Byte Datencache zusätzlich, außerdem einen Burst-Zugriff.

In den 030-Rechnern von damals gab es keinen Bedarf für weiteren Cache. Beim Amiga 4000 hat man einfach alles mit 25 MHz getaktet. Der Atari TT war mit nur 16 MHz entwickelt, weswegen man angesichts der Amiga-Konkurrenz letztlich die CPU auf 32 MHz getaktet hat, aber den Systembus auf 16 MHz gelassen hat.

Es geht wenn dann um externen Cache (L2). Es muss einen Grund geben, wieso hier für 256 kByte RAM teure 25ns Bauteile hergenommen wurden. Die 70er werden mit Wait-States belastet.

Ergänzung nach dem Öffnen der Module:
68000 hat 4 DRAMs mit insgesamt 512 kByte, dazu 2 Eproms, sodass hier das Programm vermutlich direkt im ROM läuft
68020 hat 8 DRAMs mit insgesamt 1 MByte, dazu 1 Eprom, ev. wird hier auch das ROM nach RAM umkopiert

Das sind auch die Werte, die im Display angezeigt werden. Auf keinen Fall ist die Hashtablegröße identisch. Irgendwo müssen ja auch andere Dinge wie Suchbaum etc. abgelegt werden. Die Werbung war damals also nicht ganz korrekt. Aber hat das wer erwartet?

So, mir ließ das ganze natürlich keine Ruhe

Um die Ergebnisse noch etwas genauer zu bekommen, habe ich die Stufe auf Suchtiefe 7 erhöht.
alle Tests mit London Programm und Hashtables

1. a4 Sf6
2. a5

Ergebnis:
68020 mit 12 Mhz 2...e5 477 sek
68030 mit 33 Mhz 2...e5 172 sek
68000 Emu Reflection 2...e5 35 sek

Daraus ergibt sich nun folgende Geschwindigkeit für den Reflection

68020 mit 163,2 Mhz entspricht Reflection
68030 mit 161,7 Mhz entspricht Reflection

Auch hier zeigt sich wieder, dass der 68020 fast identische Leistungen zum 68030 bringt, es liegen nur 1,5 Mhz dazwischen

viele Grüße
Markus

Ich hab keinen Genius, aber grad ein Bild im Wiki gefunden und der Aufbau weicht etwas ab von den anderen. Er enthält 8 ICs SRAM 20ns mit insgesamt 256 kByte ähnlich wie die TM 68030. Dazu ist ein sog. Pseudo SRAM vorhanden mit 512 kByte und 100ns Zugriffszeit. Hauptgrund für den Einsatz dürfte der begrenzte Platz im Modul gewesen sein. Dazu kommt noch das 8 Bit Programm Eprom mit 256 kByte.

Markus, Deine Messungen deuten darauf hin, dass am Code für den 68030 nichts optimiert wurde und die CPU lediglich wegen der höheren verfügbaren Taktfrequenzen eingesetzt wurde. Ähnliches hatten wir auch mal bei den Fidelitys Vxx festgestellt, wenn ich mich nicht irre...

Zur Verteilung Programm/Hash-RAM fiel mir noch was ein. Wenn denn tatsächlich das ROM in den 256 k SRAM umkopiert wird, dann kann hier durchaus auch noch Platz für klassischen "Arbeitsspeicher" bleiben, da das Eprom nicht zu 100% gefüllt ist. Somit ist es technisch doch möglich, dass die Hashtables den kompletten "langsameren" DRAM (bzw. PSRAM beim Genius) einnehmen, die Angaben von H&G also stimmig sind. Meine obige Bemerkung hierzu ziehe ich also zurück