deutsch English Esperanto

Inoffizielle Fan-Seite

Mein Sinclair QL (Betriebssystem-Version JS) war um 512 KiB zu insgesamt 640 KiB RAM (608 KiB Arbeitsspeicher + 32 KiB VideoRAM) und um einen MP-Floppycontroller aufgerüstet worden, an dem wiederum ein Mitsubishi Floppylaufwerk (3.5 Zoll, Double Density, 720 KiB) angeschlossen war. Dieses arbeitete mit einer Datentransferrate von 240 Kilobaud. Von den Microdrive-Laufwerken waren im Sinclair QL standardmäßig zwei eingebaut. Ihre Datentransferrate (sobald der gesuchte Sektor erst einmal gefunden war), betrug 100 Kilobaud.

Für die Vergleichstests hatte ich mich mit einem Arbeitskollegen zusammengetan, der einen Commodore C64 besaß: dieser hatte insgesamt 64 KiB RAM und war mit dem speziellen Commodore Floppylaufwerk (5.25 Zoll, Single Density, 166 KiB) für den C64 verbunden. Die Transferrate der Commodore Floppy sollte angeblich nur 3.2 Kilobaud betragen !

Sowohl der C64 als auch der QL waren zur Protokollierung der jeweiligen Anfangs- und Endzeit an je einen Drucker angeschlossen (der Drucker am QL über eine heute eher ungewöhnliche serielle RS232C-Verbindung).

Wir haben eine möglichst einfache BASIC-Schleife gewählt, die auf beiden Computern möglichst gleich aussehen sollte. Jeder Test wurde zweimal durchgefürt, einmal mit dem jeweiligen BASIC-Interpreter, dann noch einmal mit demselben Programm, jedoch kompiliert.

Es war uns von vornherein klar, dass der C64 mit seinem 5.25-Zoll-Floppylaufwerk keine Chance gegen das modernere 3.5-Zoll-Laufwerk am QL haben würde. Unklar war uns jedoch, ob der C64 mit seinem Floppylaufwerk eine Chance gegen eins der im QL serienmäßig eingebauten Microdrive-Laufwerke haben würde, denn deren Transferrate sollte zwar immerhin noch 30-mal höher sein, aber das 5-Meter-Band in den Microcartridges muss ja erst mal zu den gesuchten Sektoren gefahren werden, bevor der eigentliche Datentransfer beginnen kann. Und um die Chancen des C64 weiter zu steigern, haben wir nicht einen großen Datenblock auf einmal geschrieben (wo die hohe Transferrate der Microdrives voll zugeschlagen hätte), sondern per BASIC lauter einzelne klitzekleine Schreibvorgänge mit Vier-Zeichen-Strings zum Test benutzt.

10 OPEN_NEW#5,mdv2_testout
20 OPEN#6,ser1
30 c$=DATE$
40 FOR i=1 TO 20000
50 PRINT#5,"ABCD"
60 NEXT i
70 CLOSE#5
80 d$=DATE$
90 PRINT#6,c$\d$

10 OPEN#5,mdv2_testout
20 OPEN#6,ser1
30 c$=DATE$
40 FOR i=1 TO 20000
50 INPUT#5,a$
60 NEXT i
70 CLOSE#5
80 d$=DATE$
90 PRINT#6,c$\d$

10 TI$="000000"
20 OPEN4,4
30 OPEN2,8,12,"TESTOUT,S,W"
35 PRINT#4,"PROGRAMMSTART:  ";TI$
40 FOR I=1TO20000
50 PRINT#2,"ABCD"
60 NEXT
80 CLOSE2
90 PRINT#4,"PROGRAMMENDE :  ";TI$
95 CLOSE4

10 TI$="000000"
20 OPEN4,4
30 OPEN2,8,12,"TESTOUT,S,R"
35 PRINT#4,"PROGRAMMSTART:  ";TI$
40 FOR I=1TO20000
50 INPUT#2,A$
60 NEXT
80 CLOSE2
90 PRINT#4,"PROGRAMMENDE :  ";TI$
95 CLOSE4

Mein Kommentar:

Wir haben den Lese-Test zweimal hintereinander durchgeführt, um den Einfluss des dynamischen Cachings im Betriebssystem des QL zu sehen: Im QL wird vom Betriebssystem derjenige Teil des Arbeitsspeichers, der gerade von keinem Prozess belegt ist, automatisch als I/O-Cache-Memory verwendet, um die I/O-Zugriffe zu beschleunigen. Soweit eine Kopie von zu lesenden Daten noch irgendwo im Cache-Memory des QL vorhanden ist, werden diese dann also nicht mehr wirklich neu eingelesen, sondern gleich aus den gespeicherten Beständen geholt. Deshalb ist die "Wieder-Lesen"-Zeit bei Floppy und Microdrive gleich.
Beim C64 gibt es keine solchen Cache-Mechanismen, daher ist dort der "Lesen"-Wert gleich dem "Wieder-Lesen"-Wert.

Dass beim QL der 1. Lesewert des Microdrives sogar besser ausfiel als der 1. Lesewert der Floppy, verstehe ich zwar nicht ganz, aber vielleicht konnte das Microdrive-Laufwerk besonders günstig an das kürzere Microdrive-Directory und die kürzere Cluster-Tabelle herankommen als das Floppy-Laufwerk, die Tendenz aller Messungen lag jedoch im Rahmen der Erwartungen.

Die Leistungen des C64-Floppylaufwerks fielen allerdings deutlich schlechter aus als von uns erwartet - und bestätigten dadurch, dass die oben erwähnte niedrige Transferrate von nur 3.2 Kilobaud (gegenüber den 100 Kilobaud der Microdrives) durchaus kein Mythos war ! Trotz der wesentlich längeren Wartezeit, die auf einem Endlosband gegenüber einer Floppy bis zum Lese-Start zu erwarten ist, siegte das Microdrive-System deutlich über das C64-Floppy-System.

Diesen Test haben wir nur auf dem QL durchgeführt, die Platzverhältnisse auf dem C64 wären nicht adäquat gewesen. Bei diesem Test wollten wir nur den Unterschied zwischen den Microdrives und (echten) Floppylaufwerken sehen, wenn beide - anders als im vorigen Test - eine große Datenmenge AUF EINMAL speichern oder lesen müssen.

10 OPEN#5,ser1
20 SDATE 1986,1,1,0,0,0
30 c$=DATE$
40 SBYTES mdv2_yyy,500000,100000
50 d$=DATE$
60 PRINT#5,c$\d$

10 OPEN#5,ser1
20 SDATE 1986,1,1,0,0,0
30 c$=DATE$
35 a=RESPR(100000)
40 LBYTES mdv2_yyy,a
50 d$=DATE$
60 PRINT#5,c$\d$

Mein Kommentar:

Dieser Test zeigt deutlich die erstaunliche Performanz der Microdrives ! Einer dieser Werte allerdings (nämlich der Lesewert der Floppy, die schon das erstemal nach nur 6 Sekunden fertig war) hat mich jedoch nachträglich stutzig gemacht: er ist gar zu gut und ich vermute, daß mir damals bei diesem Test der Floppycontroller einen Streich gespielt hat - wahrscheinlich besaß er on-board einen eigenen Cache-Speicher, der durch das Rücksetzen des QL nicht ebenfalls zurückgesetzt worden war, und so konnte er sich damals vermutlich mit seinem erhalten gebliebenen Privat-Cache die Arbeit erleichtern ... leider ist mir das erst Jahre später im Nachhinein aufgefallen, so dass ich den Test nicht mehr mit der gleichen Hardware wiederholen konnte (ich hatte sie inzwischen verschenkt).

Wir haben dazu nicht die FOR-Schleife benutzt, denn wir wussten nicht genau, ob der eine oder andere Interpreter besondere Optimierungen benutzt - und womöglich erkennt, dass in der Schleife außer dem Hochzählen des Counters gar nichts passiert und die Schleife weg-optimiert. So haben wir uns für ein simples Inkrementieren des Counters und einen bedingten Rücksprung entschieden, um möglichst gleiche Sprungbedingungen in allen betroffenen PC's zu erreichen.

Näheres zum Siemens PC-D auf meiner Seite über den Siemens PC-D

10 OPEN_NEW#4,ser1hc:BAUD 600
20 SDATE 1986,1,1,0,0,0
30 PRINT#4,"Programmstart: ";DATE$
40 a=0
50 a=a+1
60 IF a<100000 THEN GO TO 50
70 PRINT#4,"Programmende: ";DATE$
80 PRINT"Programmende:  ";DATE$
90 CLOSE#4

10 OPEN4,4
20 TI$="000000"
30 PRINT#4,"PROGRAMMSTART: ";TI$
40 LET A=0
50 LET A=A+1
60 IF A<100000 THEN 50
70 PRINT#4,"PROGRAMMENDE :  ";TI$
80 PRINT"PROGRAMMENDE :  ";TI$
90 PRINT#4:CLOSE4

Mein Kommentar:

Im Siemens PC-D, der diesen Test mit deutlichem Vorsprung gewonnen hat, war wohl ein flinker Interpreter am Werk. Es überrascht andererseits auch nicht sehr, denn es war immerhin der am schnellsten getaktete Computer im Test (siehe die Ergebnistabellen-Kopfzeile). Leider hatten wir damals keine BASIC-Compiler für die beiden MSDOS-Computer, doch kann man den Unterschied zwischen interpretiertem und kompiliertem BASIC auch an den für den Sinclair QL und den C64 gemessenen Werten deutlich erkennen.
Sollte jemand noch einen mit 4.77 MHz getakteten IBM PC-XT und dazu einen BASIC-Compiler besitzen, so wäre ich immer noch sehr interessiert daran, den in der obigen Tabelle fehlenden Ergebniswert dieses Tests zu erfahren !

Dass der Sinclair QL beim Interpreter-Test so relativ langsam war, so dass er den viel langsamer getakteten IBM PC XT nur knapp schlagen konnte, zeigt auf, dass der BASIC-Interpreter des QL ein ganz besonders langsames Exemplar seiner Gattung war. Das BASIC des QL, genannt "SuperBASIC" war tatsächlich ein sehr weiterentwickeltes BASIC, mit schachtelbaren Anweisungen, parametrisierbaren Prozeduren und Funktionen, Definition lokaler Variable (so dass auch rekursive Programmierung möglich war), usw. usw. Da es aber unglaublicherweise zusammen mit dem ebenfalls ungewöhnlich guten und sowohl Fenstertechnik als auch präemptives Multitasking unterstützenden Betriebssystem QDOS gemeinsam in ein nur 48 KiB (!!) großes ROM gequetscht worden war, hatte der Programmierer des Interpreters die internen Integer-Rechenroutinen einfach weggelassen, um Platz zu sparen. Der Interpreter wandelte folglich bei jedem Schleifendurchgang die Integer-Zahl in Variable A ins interne Gleitkommaformat um, addierte eine Gleitkomma-Eins dazu, und wandelte das Ergebnis wieder ins Integerformat zurück, um die Schleifenbedingung zu prüfen - es zeigt die deutliche Leistungs-Überlegenheit der 68008 CPU, dass sie mit dem Programm dennoch in anständiger Zeit fertig wurde. Beim kompilierten SuperBASIC zeigt sich auf dem QL deshalb ein sehr viel besserer Wert.

DISCLAIMER: Alle Angaben auf dieser Seite erfolgen nach bestem Wissen, jedoch ohne Gewähr.
Dies ist eine nicht-kommerzielle Fan-Website

zurück zur Seite über den Sinclair QL
© 2005-2006 by Elmar Dünßer, Germany