deutsch Esperanto    
Inoffizielle
Fan-Seite

Performance-Vergleich:

Microdrive-Laufwerk versus Floppy-Laufwerk
und
Sinclair QL versus Commodore C64
bzw.
Die #1 der Hightech-Szene 1984 versus die #1 der Videospiel-Szene 1984
durchgeführt im Februar des Jahres 1986

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).



TEST 1:

Vergleich der Floppy am QL, des Microdrive-Laufwerks im QL, und der Floppy am C64
Testinhalt: 20000-mal den String "ABCD" in eine Datei schreiben, und von dort wieder 20000-mal herauslesen

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.

20000-mal 4-Zeichen-String schreiben:
 
20000-mal 4-Zeichen-String lesen:
 
QL SuperBASIC:
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$
QL SuperBASIC:
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$
C64 BASIC:
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
C64 BASIC:
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
In beiden Programmen werden zunächst zwei Ausgabe-Kanäle geöffnet, einer für das Schreiben in die Datei, und der andere zum Schreiben der Anfangs- und Endzeit auf den Drucker. Dann wird die identisch programmierte Testschleife (Zeile 40 - 60) 20000-mal durchlaufen, dann die Datei wieder geschlossen und die verstrichene Zeit protokolliert. Wir haben damals nur auf die Identiät der eigentlichen Testschleife geachtet, nicht auf die völlige Konformität der Einleitung und des Schlusses, da wir für die Testvorbereitung nicht viel Zeit hatten, sorry. Im QL-Programm wurden höhere Kanalnummern als im C64-Programm verwendet, da beim QL die unteren Kanalnummern bereits durch geöffnete Bildschirm-Fenster-Kanäle belegt waren.

Den QL haben wir jedesmal zwischen dem Schreib-Test und dem Lese-Test ausgeschaltet und neu gestartet, damit er keine Chance hatte, sich mit Hilfe seiner intelligenten I/O-Cache-Verwaltung heimlich Vorteile zu verschaffen (Ich sage "intelligent" nicht deshalb, weil ich ein Bewunderer bin, sondern weil das das Fachwort dafür ist). Zwischen dem Lese-Test und dem Wieder-Lesen-Test haben wir die Computer dagegen eingeschaltet gelassen, eben um das Maß der Beschleunigung zu sehen, die der "intelligente I/O-Cache" mit sich bringt.
Beim "tumben" C64 spielte es erwartungsgemäß keine Rolle, ob er zwischen den Tests eingeschaltet blieb oder nicht.

Und hier das damalige Test-Ergebnis:
Testmodus:QL mit 90mm-Floppy:QL mit Microdrive: C64 mit 130mm-Floppy:
 Schreiben:Lesen:Wieder-Lesen: Schreiben:Lesen:Wieder-Lesen: Schreiben:Lesen:Wieder-Lesen:
interpretiertes BASIC 2min 50sec 3min 28sec 2min 42sec 4min 10sec 3min 18sec 2min 41sec 9min 48sec 9min 28sec 9min 28sec
kompiliertes BASIC 1min 10sec 1min 33sec 1min 09sec 1min 44sec 1min 49sec 1min 09sec 9min 05sec 8min 31sec 8min 31sec

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.



TEST 2:

Vergleich des Microdrive-Laufwerks und der Floppy am Sinclair QL
Testinhalt: 100000 Byte (Speicherabzug) am Stück in eine Datei schreiben und von dort wieder herauslesen

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.

Speicherabzug (100000 Byte) schreiben:
 
Bereich reservieren und 100000 Byte einlesen:
 
QL SuperBASIC:
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$

QL SuperBASIC:
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$
In diesem Programm wird zunächst der SER1-Kanal zum Drucker (der beim QL an der seriellen Schnittstelle hängt) geöffnet, um die Zeit protokollieren zu können. Der eigentliche Testschritt besteht im Schreib-Programm aus dem einzigen Befehl SBYTES, der hier 100000 Byte ab Speicheradresse 500000 in eine Datei speichert (was das für Daten waren, war für den Test bedeutungslos).
Im Lese-Programm habe ich zunächst einen 100000 Byte-Block im Speicher reserviert, und dann mit dem LBYTES-Befehl die ganze vorher produzierte Datei "yyy" in diesen Block hineingelesen - natürlich habe ich auch diesmal vor jedem Lesen den QL wieder mit der Reset-Taste zurückgesetzt, damit er sich nicht mit Hilfe seiner I/O-Cache-Technik einen Vorteil verschaffen konnte. Nur vor den "Wieder-Lesen"-Tests ist er eingeschaltet geblieben. Da diesmal die gesamte Action innerhalb eines einzigen BASIC-Befehls stattfand, haben wir das Ganze nur mit dem eingebauten Interpreter getestet - eine Kompilierung hätte hier wohl nichts geändert.

Und hier das damalige Test-Ergebnis:
Testmodus:QL mit 90mm-Floppy:QL mit Microdrive:
 Schreiben:Lesen:Wieder-Lesen: Schreiben:Lesen:Wieder-Lesen:
interpretiertes BASIC 0min 19sec 0min 06sec 0min 07sec 0min 21sec 0min 20sec 0min 07sec

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).



TEST 3:

Wettrennen der BASIC-Interpreter des Sinclair QL, Commodore C64, IBM PC XT, und des Siemens PC-D
Testinhalt: 100000-mal eine praktisch leere Schleife durchlaufen

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

QL SuperBASIC:
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
C64 BASIC:
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
Die BASIC-Listings für den IBM PC XT und den Siemens PC-D sind leider verloren gegangen, aber ich bin mir sicher, dass ich die Schleife dort vollkommen identisch programmiert hatte.

In diesem Programm wird zunächst ein Ausgabe-Kanal zum Drucker zwecks Zeitprotokollierung geöffnet, und nach Ausgeben der Anfangszeit wird die Testschleife in Zeile 50 und 60 einhunderttausend mal durchlaufen und jedesmal die Variable A um 1 hochgezählt.

Und hier das damalige Test-Ergebnis:
Testmodus: Sinclair QL
(68008 / 7.5 MHz)
Commodore C64
(6510 / 1 MHz)
IBM PC XT
(8088 / 4.77 MHz)
Siemens PC-D
(80186 / 8 MHz)
interpretiertes BASIC 7min 17sec 19min 22sec 8min 07sec 3min 37sec
kompiliertes BASIC 0min 36sec 2min 47sec mangels Compiler
nicht gemessen
mangels Compiler
nicht gemessen

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)