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.

15 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…

  2. Hier die Ergebnisse aus dem C64 Emulator, der ist auch beim Floppylaufwerk sehr akkurat im Timing, wenn man „True Drive Emulation“ einschaltet.
    Leider habe ich momentan nicht die Zeit, Grafikausgabe im Originalbasic zu testen. Da müsste eine Menge Basic-Code geschrieben werden, um die
    paar Pixel zu setzen, und die Geschwindigkeit wäre stark abhängig von der Implementierung.
    Integer: 190s
    Real: 106s
    Trig.: 125s
    Text: 53s
    Store: 72s

    Ein Hoch auf Commodore BasicV2, das Integervariablen beherrscht, damit aber nichts machen kann. Für jede Art von Rechnung, selbst A%=A%+1 wird
    erst zu Fließkomma konvertiert, gerechnet, und dann zurückkonvertiert.
    Ich garantiere für nichts, vielleicht habe ich auch irgendwo einen Fehler gemacht, aber die Größenordnungen dürften stimmen.
    Jetzt das Ganze noch einmal mit Simons‘ Basic, das auch einen Plot-Befehl kennt:

    Integer: 126s
    Real: 112s
    Trig.: 122s
    Text: 54s
    Plot: 66s
    Store:76s

  3. Arne T. hat mir nun die werte für den C64 geliefert und ich habe die Tabelle ergänzt. Ich war etwas erstaunt weil er in allen Disziplinen um den Faktor 2-3 langsamer als mein CPC war. Wei kann das sein, ist er doch nach den Kommentaren im C64 Artikel ein so toller computer 🙂

    1. Warum nimmst Du nicht die Benchmark-Daten für den CPC von dem ct‘ Artikel? Dass der BASIC Interpreter auf dem CPC schneller läuft, liegt ja vielleicht unter anderem auch an dem höheren CPU Takt? Dass der von Microsoft hingebastelte Basic Interpreter keine Meisterleistung darstellt ist ja nun allseits bekannt.

      1. Ich musste das Programm sowieso neu schreiben, weil ich es compiliert als Vergleich haben wollte. der ct Artikel gibt an, das im PC eine Vortex-RAM Karte eingebaut war. Es ist also keine Originalkonfiguration. Inzwischen liefen sie Benchmarks auch auf echten CPC 6128 mit Abweichungen unter 1 s von den Emulatorwerten.

  4. Jetzt noch für den VC20, leider wieder ohne Plot, weil das Basic das nicht kann.

    Integer: 192s
    Real: 90s
    Trig.: 101s
    Text: 49s
    Plot: –
    Store:71s

    1. Danke Arne, ich habe es eingepflegt. Was mich etwas wundert ist, das der C128 nicht doppelt so schnell wie der C64 ist, was ich angesichts des Prozessors angenommen habe. Dagegen ist der drei Jahre ältere VC20 in den meisten Disziplinen schneller…

      Ich hoffe mal das dein Beispiel andere animiert sich ebenfalls zu beteiligen z.B. mit MSX, Apple II, Tandy TRS-80 …

  5. Hallo Bernd,
    das lag am Basic 7.0 des C 128. Der Interpreter brauchte länger, um die Befehle aus der längeren Befehlsliste zu identifizieren. Das war auch beim Fast 2Mhz so.

    Das galt auch für den C64 und VC 20 wenn man das Basic mit mehr Befehlen aufpeppte.
    Dann wurden sie auch langsamer.

  6. Was den Text angeht, muss der C128 80×25 Zeichen scrollen, während der VC20 nur 22×23 hat. Der Textbenchmark macht m.E. nicht viel Sinn. Die eigentliche Zeichenausgabe ohne Scrollen macht nur einen kleinen Teil der gemessenen Zeit aus, und auf allen 8 Bittern ist das Scrollen sowieso schneller als man lesen kann.

    1. Der CPC hat gar keinen Textmodus sondern nur einen Grafikmodus und schlägt beide Geräte mit Textmodus spielend, trotz Scrolling … Es kommt eben auf die Implementierung an, wie ich in meinen C64 Artikel schrieb; was nützt die tollste Hardware wenn die Software sie nicht nützt.

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.