Mich würde mal interessieren wie so der interne Datenspeicher beim Rechnen ausschaut. Also ganz platt mal ne Hartkopie vom "Speicher" während des Rechenvorgangs.
Ist das alles nur CODE oder wie ich mir auch vorstellen könnte aufgrund der "älteren" Programmierung "relativer Klartext". Welche Umfänge nimmt das an. Wie oft z.B. wird eine DIA A4 Seite voll neu berechnet mit Code ...

Welchen Speicher, und vieviel ist das in DIN A4 Seiten, hat z.B. mein 8bit Polgar (um mal nen langsameren zu nehmen) ?

u.s.w.

Hallo Stefan,

Ich bin kein Programmierer, deshalb sind das alles eher Spekulationen als Tatsachen, was ich jetzt von mir gebe!

Gerade die ältere Programmierung dürfte mehr auf Asssembler (Maschinensprache ohne jeglichen Klartext) basieren, da der Speicherplatz damals deutlich beschränkter war als heute und Assembler deutlich weniger Platz braucht als eine in Klartext lesbare Programmiersprache. Und vor allen Dingen ist Assembler in der Ausführung um ein Mehrfaches schneller!
Sein ROM hat 64 KB; eine Schreibmaschinen Din A4 Seite hat ca. 2000 Bytes, das ergibt in etwa 33000 Seiten.

Heutzutage hat ja jeder Büro-PC Platz und Speed im Überfluss, da braucht man nicht mehr platzsparend und geschwindigkeitsoptimiert programmieren...

Wenn ich zurückdenke, was man z. B. aus den <64KB eines Commodore 64 mit Programmiertricks alles herausgeholt hat; da könnten sich die Programmierer von heute viele Scheiben abschneiden...


viele Grüße,
Robert

64KB = 33.000 Seiten Die macht sich auch mein 8biter ständig voll ?
Das da viel hin und her geschoben wird ist mir klar - aber das das schon mit dem kleinen diesen Umfang hat ...
Ist bestimmt auch vom Modus, sprich gegönnte Rechenzeit abhängig - also mehr als 5sec/10sec kriegt meiner nicht - damit ich noch ne Chance habe


Stell ich mir das so richtig vor :
Brute force alles durchrechnen was mit dem 1. Halbzug geht.
Intern listen und weiter mit dem 2. und 3. Halbzug und dann später auf Basis dieser "Listen" selectiv weiterrechnen ? Kommt der überhaupt rechenleistungstechnisch darüberhinaus in der wenigen Rechenzeit ?

Von dem Umfang was da alles an Daten bewegt wird macht man sich gar keine Gedanken - daher auch dieser Trööt ...
Das ist ja schon interessant mal einzusteigen wie das so funzt - gibts da nen Link zum Thema ?

Hallo Robert,
mir geht es genau so wie Dir. Ich habe ein Buch hier vorliegen und das gibt folgendes dazu an:
Man rechnet mit 75 Anschläge pro Zeile, 40 Zeilen pro Seite.
ein ASCII-Zeichen kann mit 1Byte gespeichert werden (ein Farbpixel verbraucht 3Byte, Rot-Grün-Blau-Anteil)
1 Seite =75x 40=3000 Zeichen
Daraus berechne ich :22000 Seiten.
Ich weis aber nicht, ob meine Rechnung stimmt.

Paul

Habe nachgerechnet: Es sind 22 Seiten.

Hallo Robert!Da hast Du vollkommen recht! Zumindest die eigentliche Engine dürfte bei jedem Bretti pures Assembler sein. Bei den Routinen wie für die Displays etwa würde ich das nicht beschwören wollen, sehe aber keinen Grund, warum für sowas vergleichbar banales nicht Maschinencode gewählt wurde.Das ist wohl wahr. Die Prozessorarchitekturen haben sich aber auch sehr verkompliziert. Wollte man heute in reinem Assembler schreiben, müsste man sehr genau aufpassen, dass auch wirklich jede CPU mit dem Code klarkommt. Da tut man sich mit einer höheren Programmiersprache und gut darauf angepassten Assemblern einfacher. Der Code ist dann nur wesentlich aufgeblähter und natürlich langsamer. Aber bei der Vielzahl an verschiedenen Prozessoren wäre es ein Unding, von den Programmieren pures Assembler zu verlangen. Sie müssten sich dann zwangsläufig mit dem Code begnügen, den alle CPUs gemeinsam gleich interpretieren und auf diverse CPU-abhängige Beschleunigungsmöglichkeiten verzichten. Wird so langsam Zeit, dass DER ultimative Superprozessor entwickelt wird, damit dieses Problem der Vergangenheit angehört.Ja, hier konnte man ungemein tricksen! Die Ausführung von Assembler ist bei dem Ding locker bis zu 1000 mal schneller als die von Basic und man hat wesentlich mehr Speicher zur Verfügung. Selbst wenn man auf Routinen des Interpreters oder des Kernels direkt zugreifen will (um sich diverse Sachen einfacher zu machen), kopiert man einfach den entsprechenden ROM-Bereich ins RAM und fertig. Einerseits schade, dass mein 64er "gemopst" wurde - andererseits hätte ich heute kaum mehr die Zeit dafür.

Gruß, Willi

Ach ja - wie so ein Programm beim Rechnen ausschaut, will ich mal im Groben schildern:
Der Code selbst -nebst Bibi- bleibt freilich unverändert. Das Programm legt die Ergebnisse seiner aktuellen Berechnung in einer Tabelle im RAM ab. Die wesentlichen Informationen hieraus werden direkt ans Display geschickt. In der Tabelle wird (ich glaube nach vollständiger Berechnung des ersten Ply) festgelegt, in welcher Reihenfolge gesucht werden soll (damit die "besseren" Züge in Hinblick auf die Zeitkontrollen zuerst berechnet werden). Diese ändert sich nur dann, wenn ein besserer Zug gefunden wurde als in der Ausgangsberechnung. Der vormals beste Zug wandert damit auf Platz 2. Weitere Änderungen finden dort erst einmal nicht statt. Das in dieser Tabelle eine vollständige Umstellung in die Reihenfolge der besten Bewertungen aus Sicht des aktuellen Halbzuges stattfindet, ist bei den wenigsten Programmen der Fall - warum auch immer das so ist. Weiterhin wird die beste errechnete Variante im RAM festgehalten - als Ausgangspunkt für die Berechnungen im nächsten Halbzug. Alles andere (bis auf die gespeicherte Reihenfolge) "vergisst" das Programm wieder, will heissen: Es wird nicht im RAM abgelegt. Nur so ist es möglich, dass die Dinger mit nur wenig RAM überhaupt komplexe Zugfolgen ermitteln können. Bei ausreichend Speicher werden halt mehr Positionen für eine weitere Berechnung festgehalten, nebst der bisherigen Bewertungen. Das läuft dann aber bereits in Richtung "Hashtables". Bezogen auf ein Programm wie das des Polgar bedeutet das: Der Code bleibt bis auf die abgelegte kleine Tabelle weitgehend statisch. Natürlich verändern sich permanent sie Inhalte diverser Variablen, etc. Das führt dann dazu, das es aussieht als würde sich der Code fließend bewegen. Dies trifft aber eher aus der Sicht der CPU zu - von unserer Warte aus bewegt sich da praktisch nichts - ausser der Tabelle eben.

"Wissen" tu ich das aufgrund meiner Erfahrungen mit dem C64. Prinzipiell ist das auf alle 6502 Maschinen übertragbar und mit hoher Wahrscheinlichkeit auch auf alle anderen Brettis aus der "guten alten Zeit". Bei Ruud's Monstern mag das ein wenig anders ausschauen, aber darum ging es hier ja nicht.

Vielleicht haben wir uns da etwas missverstanden: die 64KB sind ROM (read only memory) Da wird nix hin- und hergeschoben (da ja nur gelesen und nicht geschrieben werden kann), nur abgearbeitet!

Du meinst wohl eher das RAM, den Arbeitsspeicher...
das eher nicht; im RAM werden u. a. alle Variablen gespeichert, die der Schachcomputer so braucht: Hauptvariante, verbrauchte Zeit, eingestellte Stufe, gespielte Züge (um die Zurücknahme möglich zu machen) und vieles, vieles mehr...
So sollte das stimmen, ja.
Wieso nicht? Das ganze ist natürlich von der Rechengeschwindigkeit und der Bedenkzeit abhängig! Auf der untersten Stufe schafft ein langsamer Rechner vielleicht gerade mal den Brute-Force-Sockel; je mehr Zeit er hat (oder je schneller er ist), desto tiefer kommt er.
Tja, das ist im Grunde alles EDV-Basiswissen. Google sollte da wohl einige Millionen Treffer liefern (auch zur Schachprogrammierung)


viele Grüße,
Robert

auf der titelseite der css zur ausgabe mit dem mm5 (glaube ich) ist doch
das bild des listings, also dieser stapel papier, abgebildet. ganz schön dick.

__________________
Die ganze Welt des Computerschachs

Hallo Paul und Robert,

so langsam zweifle ich an meinen Rechenkünsten...
Dein Beispiel hat mit Robert's eines gemein - ich verstehe es nicht!
Wenn eine Seite (wie Robert beschrieb) ca. 2000 Byte hätte und ich mal der Einfachheit halber auf 2048 Byte "aufrunde", so sind das doch bereits 2 KB, oder etwa nicht? 64 KB / 2 KB (Seite) = 32 Seiten! Bei deinen 3000 Zeichen (= 3000 Byte) wären es dann so gesehen rund 21 bis 22 Seiten - und aus! Wo kommen denn bei Euch die vielen Nullen her?
Liege ICH hier falsch oder was geht ab? Muss mich sonst wohl mal einem umfassenden Systemcheck unterziehen...??

Gruß, Willi

Lieber Willi,
es sind 22 Seiten. Bitte kein Systemcheck durchführen. Ich habe im Kopf 10 hoch 3 und 10 hoch 6 vertauscht.

Paul

nö, klar, du hast recht! Man ist schon gar nicht mehr gewohnt, mit soooo kleinen Einheiten umzugehen! (ich sollte vielleicht doch während der Arbeit keine Postings verfassen, in denen man mit Zahlen umgehen muss! )


Robert