Benchmark my Computer!

Die ct‘ hat in der Ausgabe 10/1987 einen kleinen Benchmark vorgestellt, den sie dann auch einige Jahre lang genutzt hatte. Die als HL-Benchmark bezeichneten Programme (HL: für High Level) sollten auf Hochsprachenebene verschiedene Aspekte eines Computers testen:

• Berechnung mit Ganzzahlvariablen
• Berechnung mit Realzahlvariablen
• Berechnung transzendenter Funktionen
• Textausgabe
• Grafikausgabe
• Speichern auf den Massenspeicher (damals je nach System Floppy Disk oder Festplatte)

Die ct hat den Benchmark damals in BASIC, C und Pascal veröffentlicht. Getestet hat sie ihn auf IBM PC, AT und 286-er Rechnern, Macs, Atari ST, Amiga und dem CPC 6128. Was sie nicht gemacht hat, war es die anderen 8 Bit Rechner zu testen und das möchte ich nachholen – mit eurer Hilfe.

Ich habe die Benchmarks in diesem ZIP-Archiv zusammengepackt. Es enthält die BASIC-Version für den CPC 6128 als ASCII-Datei sowie die Benchmarks in C und Turbo Pascal für DOS-Rechner und als EXE. Wer seinen neuesten Rechner testen will, findet die Benchmarks auch in Lazarus, als Kommodzeilenprogramm unter CMD unter Windows lauffähig, Lazarus Quelltext für andere Systeme (läuft auch auf einem Raspberry Pi oder Mac) liegt bei.

Während die C und BASIC Benchmarks mit Ausnahme der Routinen für die Zeiterfassung der ct‘ entsprechen habe ich den Pascal Benchmark noch einige Jahre lang auf verschiedenen Rechnern getestet. Er hat daher auch noch eine Eingabe vor dem Start: den Skalierungsfaktor. Vereinfacht gesagt: die Benchmarks brauchten auf den Originalrechnern damals je nach Routine 1 bis 120 s pro Teilbenchmark. Heute sind die Rechner viel schneller und die Ausführungszeit rutscht dann in einen Bereich, denn die Betriebssysteme nicht sauber messen können. Windows hatte in der XP-Version z.B. eine Zeitauflösung von 20 ms. Mit dem Skalierungsfaktor werden die Schleifen häufiger ausgeführt und so eine präzisere Messung bekommen. Man kann mit dem Faktor 1000 anfangen und sich dann in Zehnerpotenzen hochangeln. Wer einen aktuellen Rechner mit SSD hat, sollte mit einem Faktor von 10.000 bis 100.000 beim Lazarus Benchmark arbeiten.

Was ihr in jedem Falle bei einem alten 8 Bit Rechner am Quelltext ändern müsst, ist das Anpassen der Zeiterfassung. Die wird vor jedem Benchmark gemacht und nach dem Benchmark die vergangene Zeit seit der Erfassung bestimmt. Bei meinem CPC gab es dazu das Time Kommando, das wiedergab, wie oft eine Variable durch den Interrupt (300-mal pro Sekunde) hochgesetzt wurde. Die C und Pascal Routinen nutzen für die Zeiterfassung die DOS-Funktion Gettime. Wenn das System die Zeitmessung nicht bietet, müsst ihr von Hand stoppen. Dann würde ich eine Zeile, in der das System wartet, einfügen (Readln, Input, getc …) damit ihr die Zeit aufschreiben und euch auf die nächste Messung vorbereiten könnt.

Anzupassen beim BASIC-Listing – ich vermute mal für die meisten 8 Bit Rechner gibt es keinen C oder Pascal Compiler – ist in jedem Falle die Grafikausgabe und das Speichern auf Disk.

Die Grafikausgabe besteht aus Folgendem:

• Umschalten in den Grafikmodus
• Plotten von 10.000 einzelnen Punkten von (1,1) bis (100,100)
• Umschalten in den Textmodus

Speichern:

• Datei fürs Schreiben öffnen.
• 1000-mal den String „qwertzuiop1234567890“ in die Datei schreiben
• Datei schließen
• Datei löschen

Mir ist klar, das viele ihren alten Compi nicht mehr haben. Inzwischen sind sie bei ebay sogar stellenweise noch teurer als zu den Zeiten, wo man sie noch neu kaufen konnte (der C64 wird übrigens neu gefertigt, wenn auch nicht mit Originalhardware, man kann ihn mit Joystick für 200 Euro bei Amazon kaufen). Daher akzeptiere ich auch Emulator-Ausgaben. Knackpunkt dürfte dabei das wirklichkeitsgetreue Emulieren der Disk sein, das ist wegen der Mechanik schwerer als bei der Elektronik. Da man für das Anpassen der Programme Kenntnisse der Computerhardware kennen muss, hoffe ich auf eure rege Teilnahme. Besonders gespannt bin ich auf die Ergebnisse vom C64, schließlich meinen die C64 Fans in den Kommentaren zu meinem Artikel, das diese ja so viel besser als ein CPC ist. Ich glaub es nicht, aber ich lasse mich gerne eines Besseren belehren.

Ich würde mich freuen, wenn wir eine Übersicht für möglichst viele 8 Bitter zusammenbekomme. Gerne aber auch für Macs, Atari ST und Amigas. Ergebnisse bitte hier posten, ich werde die Tabellen dann aktualisieren.

Benchmark in TP	Integer	Realzahlen	Funktionen	Text	Grafik	Speichern
IBM XT, Herkules Karte	1,23	37,44	53,74	64,20	6,59	9,94
Schneider PC 8086, 8 MHz	0,71	15,82	22,19	49,12	1,93	9,88
V30 8 MHz	0,33	14,72	21,09	21,42	1,59	2,20
Kapyro AT	0,22	10,33	10,89	32,44	2,47	9,83
Atari ST	0,42	10,10	13,98	43,48	1,30	35,11
Macintosh	0,45	41,42	77,28	51,35	8,35	9,82
Macintosh II	1,10	6,15	7,68	44,83	5,20	3,20
CPC 6128	7,92	67,59	117	39,65	7,89	16,48

 

 

 

Benchmark in BASIC	Integer	Realzahlen	Funktionen	Text	Grafik	Speichern
ATARI ST GFA Interpreter	11,07	9,42	4,58	44,86	10,28	52,84
ATARI ST GFA Compiler	5,07	3,57	3,78	44,85	7,35	50,35
Amiga	30,78	26,17	118,86	158	21	10,54
CPC 6128	42,72	66,66	62,89	59,67	21,85	22
CPC 6128 compiliert	6,85	34,6	59,93	59,57	6,89	19,57
C64	190	106	125	53		72
C64 Simons BASIC	126	112	122	54	66	76
VC 20	191	90	101	49		71
C128	136	65	62	90	84	48
Sinclair QL	79	61	28	197	99	7
Alphatronic PC	95	107	176	100

Benchmark in C	Integer	Realzahlen	Funktionen	Text	Grafik	Speichern
ATARI ST GFA Interpreter	0,32	3,12	2,46	41,06	1,59	21,37
Amiga	0,4	4,40	2,96	49,58	2,82	6,84

Ein paar Bemerkungen. Ohne Mulitplikations- und Divisionsbefehle im Befehlssatz der Z80 sieht die 8 Bit CPU des CPC bei den Integerrechnungen schlecht aus. Bei den Realzahlen und Funktionen, die auch die anderen Rechner mit Routinen berechnen müssen, schrumpft der Nachteil zusammen. Bei der Ausgabe von Text rückt das Feld eng zusammen. Hier ist im Prinzip die Video-CPU bestimmend und das ist bei IBM Kompatiblen und dem CPC ein 6845. Er bremst durch die Synchronisation des Auslesens der Grafik und damit Blockade des Speichers die CPU aus. Dasselbe gilt auch für Grafik, wobei hier die Interpreter deutlich schlechter sind, denn das Setzen eines Punktes ist ja eine elementare Grafikoperation, die schnell gehen müsste. Hier ist die Schleife, die 10.000-mal durchlaufen wird, geschwindigkeitsbestimmend. Beim Speichern (hier nur die Benchmarks mit Floppys, es gibt auch welche mit Festplatten doch die sind dann nicht vergleichbar gibt es die meisten Überraschungen. Einige 16-Bitter sind tatsächlich langsamer als ein CPC, obwohl der nicht mal Disketten ohne Skew/Interleave einlesen kann. Die Häufung von 10 Sekunden spricht für eine Limitierung durch die Hardware, obwohl die Datei mit 10 KByte eher klein ist.

Beim Sinclair QL tippe ich bei den nur 7 Sekunden beim Store auf einen Emulator-Effekt, das heißt man hat sich nicht die Mühe gegeben, die Mechanik des Microdrives zu emulieren. Der Sinclair QL, VC20, C128 und C64 beherrschen keine Ganzzahl Variablen, sodass die Rechnungen in Ganzzahlen durch die Konvertierung sogar langsamer als bei Fließkommazahlen ist. Das finde ich etwas komisch, sind dies doch Berechnungen die die CPU nativ ausführen kann, während Realzahlen nur durch eine Bibliotheksroutine möglich sind.

Mit einem mathematischen Coprozessor, der bei den Tests nur in IBM Kompatiblen steckt, beschleunigt die Fließkomma Benchmarks um den Faktor 4 und bei den Funktionen, die intern über Taylorreihen berechnet werden, sogar um den Faktor 20. Wenn jemand den Lazarus Benchmark einsetzt, sollte daran denken, dass die alten Real-Typen dort nicht mehr unterstützt werden und alles mit dem Coprozessor berechnet wird. Die Tabelle ist daher auch die mit Coprozessor bei der Ausgabe.

[Edit] ich habe inzwischen wieder mal ein DOS auf einer CF-Karte installiert und kann die Benchmarkwerte für einen Icore I5-4590 (Haswell, 3,9 GHz Takt) nachliefern:

• Ganzzahl: 0,001
• Realzahlen: 0,0033
• Trigonometrie: 0,00186
• Textdarstellung: 0,72
• Grafikdarstellung: 0,01648
• Store: 0,21 (auf 2 GB SD-Karte)

Wie man sieht ist im Laufe von mehr als drei Jahrzehnten die Textdarstellung am „wenigsten“ in der Geschwindigkeit gesteigert worden, nur um den Faktor 30. Bei der Integerberechnung ist es dagegen der Faktor 10.000. Gegenüber den letzten Rechnern mit 386 oder 486 Prozessor (und höher) die ich testete, ist der Sprung nicht so groß. Gegenüber einem fast 20 Jahre alten Athlon mit 750 MHz z.B. nur der Faktor 2,8.