Das wäre eine denkbare Erklärung - schließlich waren die meisten Bausteine damals noch etwas größer als heute!

Werden aber Programme nicht grundsätzlich ins RAM kopiert? Ich meine mich beispielsweise entsinnen zu können, das beim doch wesentlich älteren C64 bereits das Kernel und der BASIC-Interpreter stets ins RAM kopiert wurden, weshalb von den 64KB nur knapp die Hälfte für Anwenderprogramme übrig blieb. Vergleiche ich hier vielleicht Äpfel mit Birnen?

Die Beschleunigung durch größere Hashtables bricht signifikant ein, sobald der Speicher voll ist! Dies dürfte auch bei den im Vergleich zu PCs langsamen Brettcomputern recht schnell der Fall sein und daher beim BT-Test zu keinen nennenswerten Änderungen führen. Beim Endspiel sind die halbwegs sinnvollen Zugmöglichkeiten sowie möglichen Zugumstellungen nicht mehr so häufig, was wohl der Grund für die Zunahme der Bedeutung des Hashs in solchen Situationen ist. Aber die Hashgröße hat nach meinen Erfahrungen nicht nur einen Einfluss auf die Zeit, die zum Erreichen einer höheren Suchtiefe nötig ist, sondern unter Umständen auch auf früheres Erkennen taktischer Wendungen (d.h. eine Wendung wird mit größerem Hash u.U. bereits ein bis mehrere Plies eher entdeckt!), was bezüglich eines "Best-Move" gelegentlich zu einer enormen Zeitverkürzung führen kann. Diese Phänomen habe ich vor rund 10-12 Jahren zum ersten Male bewusst wahrgenommen und mit Rebel 6 sowie Fritz 4.01 untersucht. Eine eindeutige Erklärung eröffnete sich mir dabei jedoch nicht. Aber es stellte sich heraus, das Fritz einen derartigen Profit nicht erzielen konnte - im Gegensatz zu Rebel, der bei durchschnittlich 10% aller getesteten Stellungen bis zu 3 Suchtiefen früher eine taktische Wendung erkannte, wenn man den Hash signifikant vergrößerte. Bei dem spärlichen RAM der Brettcomputer dürfte das aber kaum zu erwarten sein. Ebensowenig dürfte es beim Blitzen mit Brettcomputern einen negativen Einfluss auf die Rechenleistung haben, wenn der Hash auf Maximum ausgebaut wird. Derartige Erscheinungen sind ja des öfteren bei PCs beobachtet worden (nicht von mir, denn ich blitze nicht!) und begründen sich anscheinend in einem höheren Verwaltungsaufwand für den größeren Speicher, der bei solch geringen Bedenkzeiten in keinem guten Verhältnis mehr zur eigentlichen Zugberechnung steht. Einem Brettcomputer würde ich daher immer das Maximum an Speicher verpassen...
MfG,
Wilfried

Zumindest nicht bei allen; die meisten Rechner (damit meine ich z. B. 6502-basierte) haben gar nicht genug RAM für solche Aktionen!

Und wenn die Geschwindigkeit der CPU nicht hoch genug ist, um die EPROMs speedmäßig auszureizen, besteht ja auch kein Grund dazu. Würde den Rechner ja nur unnötig verteuern!
Tja, dazu kann ich leider auch nix definitives sagen...


viele Grüße,
Robert

Hallo,

Also beim C64 wurde der Basic Interpreter (quasi ein Programm) ins Ram geladen.
Nicht aber der Kernel, der blieb im Rom, liegt dabei aber, da die 6510 Pro`s wie auch die 6502 etc nur 64kB addressieren können, "unter" dem Ram.

Das hat was damit zu tun, das diese Prozessoren völlig anders "denken" als Motorola 68xxx oder Intel. War irgendwas von Addressenorientiert und Registerorientiert.

Klingt kompliziert, ist es auch. Es gibt Berge von C64 Literatur dazu. Aber auch sehr praktisch. Der Prozessor kann praktisch mehrere Speicherbereiche sehen die bildlich gesehen über einanderliegen.

Das hatte zur Folge das man in Maschinensprache trotzdem fast die gesamten 64kB zur Verfügung hatte, unter Basic dagegen nur 38kB.

Auf jeden Fall können diese Prozessoren sehr schnell zwischen verschiedenen Speicherbereichen hin und herschalten was diese MHz-mäßig (schreckliches Wort) verhältnismäßig schnell machte, so war ein 6510 bei 1 MHz ungefähr so schnell wie ein Z80 bei 4 MHz.

Dies erklärt m.E. auch den ungewollten Erfolg der MM IV Turbo Module.

Grüße, Dirk

Hallo Dirk,

das stimmt! Bei Basic-Programmen bleibt der Kernel stets im ROM - obwohl es gleichzeitig auch im RAM vorhanden ist, weshalb die Kiste hier auch so sehr lahmt. Selbiges trifft leider auch auf jene Programme zu, die lediglich durch einen Assembler geschickt werden. Wer aber bei der Entwicklung/Programmierung ein Optimum an Performance erzielen will, befiehlt zunächst den Zugriff auf's RAM und passt das Kernel dann an die Bedürfnisse des Programms an. Damit können einerseits einige Bytes an Platz gewonnen und andererseits auch diverse Standardroutinen abgeändert werden. Der "Ottonormalanwender" hat für derartige Zugriffe allerdings kaum einen Bedarf. Na gottseidank arbeiten die anders - nämlich schön einfach und übersichtlich! Also ich möchte mich heute nicht mehr in die Assemblerprogrammierung eines x86 reindenken müssen. Das ist alles so fürchterlich kompliziert geworden - vor allem auch wegen der verschiedenen zu berücksichtigenden OS. Da ist der Umweg über Compiler natürlich wesentlich bequemer ... nur eben nicht der Weisheit letzter Schluss.Eigentlich nur zwei - das RAM und das an gleicher Adresse befindliche ROM. Wenn ich mich nicht irre, kann man an irgendeiner Adresse im unteren Speicherbereich (jedenfalls irgendwo unterhalb $0400) festlegen, ob auf das ROM, oder auf das RAM zugegriffen wird - hauptsächlich wird davon Gebrauch gemacht, um eigene Zeichensätze verfügbar zu machen.Es gibt sogar einige Operationen (ich glaube, ROL und ROR gehören auch dazu?), bei denen ein 6510 mit lediglich 1MHz sogar noch einen 386er das Fürchten lehrt! Ich bin der Meinung, ein 6510 oder auch 6502 ist für's Schach überhaupt ein guter Prozessor. Schade nur, das ohne Hilfsmittel nicht mehr als 64KB angesprochen werden können. Hätte man vor 20 Jahren schon CPUs vom Schlage 65802 bzw. 65816 zur Verfügung gehabt, wer weiss ob sich die 68xxx bei Schachcomputern überhaupt hätten durchsetzen können? Wir werden es wohl leider nie erfahren...

Gruß,
Wilfried