Vorbemerkung: Tonbandgeräte und Floppylaufwerke sind aus heutiger Sicht sehr verschieden, obwohl beide magnetisch aufzeichnen. Typische Tonbandgeräte nehmen analoge Töne auf und typische Floppylaufwerke schreiben digitale Informationen in Sektoren gebündelt auf ein Medium und verwalten diese als Cluster. Nachdem man aber gelernt hatte, digitale Informationen in Form analoger Töne zu kodieren, waren Tonbandgeräte für viele preiswerte Computer die übliche und oft einzige Option der dauerhaften Datenspeicherung geworden. Als sich nun die Welt der teuren Floppylaufwerke und der billigen Tonbandgeräte annäherten, entstanden auch technische Hybride, die diese beiden Welten auf ganz besondere Weise miteinander verbanden, z.B. das damalige "Floppylaufwerk" zum Commodore C64 und die "Microdrives" des Sinclair QL. Das "Floppylaufwerk" des C64 nutzte als Medium eine normale 130mm-Floppy, verwendete diese aber wie ein Tonband: jede Datei musste am Stück zusammen auf der Floppy liegen, eine Clusterverwaltung oder ein Directory gab es nicht. Für die Funktion "Directory" musste der Rechner die ganze Floppy durchkämmen, um zu sehen, was auf ihr alles gespeichert war. Die "Microdrives" des QL wiederum verwendeten als Medium zwar ein 5-Meter-Endlos-Tonband, schrieben jedoch im übrigen die Daten wie moderne Floppylaufwerke auf das Band: gegliedert in Sektoren, verwaltet als Cluster und mit ordentlichem Directory. Daher war der hier im Folgenden beschriebene Performance-Vergleich für mich damals so spannend wie heute.

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 (90mm, 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 (nachdem der gesuchte Sektor erst einmal gefunden war) lag bei 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 (130mm, Single Density, 166 KiB) für den C64 verbunden. Ich hatte gelesen, dass die Transferrate der Commodore Floppy angeblich nur 3,2 Kilobaud betragen sollte - was ich zunächst nicht glauben wollte!

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 exotischen 130mm-Floppylaufwerk (das ein Magnetbandgerät emuliert) keine Chance gegen das moderne 90mm-Floppylaufwerk an meinem 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 angeblich 30-mal höher als die der Commodore-Floppy 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. Um die Chancen des C64 weiter zu steigern, haben wir nicht einen großen Datenblock auf einmal geschrieben (wo die erwartete 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 der intelligenten I/O-Cache-Verwaltung im Betriebssystem des QL zu sehen: Im QL werden vom Betriebssystem diejenigen Teile des Arbeitsspeichers, die gerade von keinem Prozess belegt sind, automatisch (und dynamisch) als I/O-Cache-Memory verwendet, um die I/O-Zugriffe zu beschleunigen. Soweit also eine Sektorkopie der zu lesenden Daten noch irgendwo im Cache des QL vorhanden ist, spart sich der QL die Zeit für einen externen Datenzugriff und liest statt dessen die Daten direkt aus dem Arbeitsspeicher. Deshalb ist die "Wieder-Lesen"-Zeit küzer als die "Lesen"-Zeit und im Übrigen bei QL-Floppy und QL-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 QL-Microdrives sogar besser ausfiel als der 1. Lesewert der QL-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 sehr deutlich über das viel teurere C64-Floppy-System. Dass die QL-Floppy insgesamt sowohl über das QL-Microdrive als auch über die C64-Floppy siegen würde, war uns von Anfang an klar gewesen.

Diesen Test haben wir nur auf dem QL durchgeführt, der C64 hat ja nur insgesamt 64 KiB Speicher und kann selbst davon nur einen gewissen Teil auf einmal in sich hineinlesen. Bei diesem Test wollten wir den Unterschied zwischen den QL-Microdrives und (echten) QL-Floppies 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 - ein so knappes Ergebnis (19 Sekunden versus 21 Sekunden, beim Schreiben) hatten wir nicht erwartet! Einer der 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 jetzt, 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 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 oder den mit 8 MHz getakteten Siemens PC-D und dazu einen BASIC-Compiler besitzen und den Test nachholen, so wäre ich immer noch interessiert daran, die zwei in der obigen Tabelle fehlenden Ergebniswerte zu erfahren !

Dass der Sinclair QL beim Interpreter-Test 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 zeigte sich auf dem QL deshalb ein dramatisch 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-2015 Elmar Dünßer (Duensser)