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
Sinclar QL 79 61 28 197 99 7
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.

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.

4 thoughts on “Benchmark my Computer!

    1. Funktioniert leider nicht. Weder kann man den typ mit anderen Flieskommatypen nutzen (nicht mal explizite Typwandlung mit Real48() oder Double() noch ihm Konstanten zuweisen. Das wundert bei der Definition aber auch nicht:

      type real48 = array [0..5] of Byte;

      Ist damit ein Feld und keine Fließkommazahl

      1. Tja, das hätte ich mir wohl genauer ansehen sollen… Aber wer rechnet damit, dass es einen Datentyp gibt mit dem man nichts tun kann außer ihn in andere Fließkommatypen umzuwandeln?

        Dann fällt mir nur noch ein {$E+} zu verwenden – aber auch das wird (wenn überhaupt) wohl nur unter DOS funktionieren und erfordert die Unit ‚EMU387‘.

  1. Ich hatte ja gehofft das da es hier Fans anderer Heimcomputer gibt, ich noch einige Resultate von anderen Rechnern bekommen würde.
    Ich habe jetzt das Programm für den Sinclair QL angepasst und auf einem Emulator laufen gelassen. Die Ergebnisse sind nicht so berauschend – in allen Disziplinen bis auf das Speichern hat er die rote Laterne.

    Die Tabelle wurde entsprechend erweitert.

    Könntet ihr nicht wenigstens die Ergebnisse für den C64 mit seinem völlig anderen BASIC ermitteln. Angeblich soll das doch so ein toller Rechner sein und meine Kritik völlig aus der Luft gegriffen…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.