i8088 / NecV20: Kleines Benchmark-Programm - Bitte um Teilnahme

1ST1

gute Arbeit gemacht im anderen Forum!

* "ys": es müßte eigentlich ein "müh" zeichen sein, statt dem "y", damit es korrekt ist. das "'müh" ist ein "y" mit geradem Aufstrich links. Ich war zu faul mir daß im Ascii Zeichensatz zu suchen und habe einfach ein y genommen (abgesehen davon gibt es auf alten Terminal-Rechner wie zb dem DMV eigene Zeichensatztabellen je nach eingestelltem Ländercode ... Und so habe ich zur Vereinfachung ein y genommen.)

* "tofro": nein, ich bin DoPe

Damit die im anderen Forum auch was von der Zusammenstellung (siehe voriger post) haben -> gerne dort posten.

Und die Anmerkung zur "efficiency" spalte wäre eigentlich auch gut. Ich halte diese Werte für SEHR interessant, weil man daran so gut sehen kann,

wie die CPU-Architektur für die Aufgabe/Test geeignet ist. Man sehe sich nur die Werte vom P4 oder 486er an ... Aber auch die Unterschiede zwischen 8 vs 16 Bit Systemen ...

Ich glaube unsere postings haben sich zeitlich überschnitten

ich habe eine aktualisierte tabelle von allen werten die hier im forum gepostet wurden veröffentlich (seite 4 fast ganz unten).

die ergebnisse vom anderen forum arbeite ich gerne ein, aber daß kann jetzt ein wenig dauern ... vielleicht erst morgen .

PAW

derartige "synthetische" tests wie "jmp-orgy" decken schwächen einer cpu-architektur auf. genau das sieht man nier ja auch an der "effizienz"

(verbratene cpu-cycles während der ausführung). genau diese effizienz (niedrigerer wert = besser) im vergleich 2er cpus sagt einem, wie gut die MHz in Leistung (speed) umgesetzt werden.

ops/sec: ja, das ist sozusagen der inverse Wert der Runtime - Fahrzeit vs km/h bei einer Autofahrt - und bedeutet wie oft die routine in 1 sec ausgeführt werden kann.

ad interrupts deaktivieren:

es ist natürlich richtig, daß bei aktiven interrupts die testroutine alle 54 ms unterbrochen wird, um die systemzeit zu aktualisieren, und diese zeit der timer-interrupt-service-routine im meßergebnis drin ist. aber das macht insofern nichts, als genau diese situation "real world" verhalten widerspiegelt. dreht man die interrupts ab, dann würde übrigens eine Messung die über 54 ms hinausgeht unmöglich werden. denn wenn während der laufzeit die systemuhr aufgrund deaktivierter timer ISR nicht mehr aktualisiert wird, wie soll man dann einen zeitunterschied zwischen startzeit und endzeit feststellen, der über das auslesen des internen 8253 counters (startwert/endwert und differenzbildung) hinausgeht? Denn es würden ja die countertoks (alle 54,925ms) und eventuelle änderung des stundenzählers verunmglicht werden ..... Kurz gesagt: bei deaktiviertem timer-interrupt bleibt die Uhrzeit stehen (bis auf max zeitspanne von 54,9ms).

PAW, bitte herausfinden welche CPU sich im HP Rechner befindet. danke.

Hier die letzte Zusammenstellung aller Ergebnisse (mit Korrekturen wie gewünscht) inkl. der Ergebnisse aus dem anderen Forum.

1ST1

vielen dank fürs posten in vcfed ... Die Erklägurng zu "ops/sec" ist aber nicht ganz korrekt bzw. könnte mißverstanden werden.

Daher für die technisch Interessierten: Es ist nicht die Anzahl der "loops" (klingt nach Hochsprachen-Programmierung) die pro Sekunde ausgeführt werden, sondern die Anzahl der Ausführungen des Testkerns.

Der Kern im Falle der JMPorgy ist "int 080H" x 500000.

Alle Werte sind durch Herausmessen "befreit" von jeglichem overhead der durch TP entsteht, also auch die Laufzeit der FOR-TO-LOOP (die es tatsächlich im sourcecode gibt und nur 1 Aufruf der testroutine erzeugt, aber vorhanden ist um flexibel zu bleiben). Ebenso herausgemessen wird der (1malige) Aufruf der Testprozedur und dessen Rücksprung (call / ret), sowie alle in der Testroutine enthaltenen Anweisungen die für das setup der Kernroutine notwendig sind aber nicht in die Laufzeitmessung hineingehören. D.h. der Wert "ops/sec" gibt an, wie oft die "Aktion" (500000 x int80h) in einer Sekunde ausgeführt werden kann.

Dieses "Runterbrechen" auf den Testkern habe ich mir deswegen angetan, weil ja ursprünglich von JZander dargelegt wurde, daß der DMV entgegen dem Erbsenzählen (Summierung der lt. Manual ausgewiesen cpu-cycle times aller für die Abarbeitung von 500000 x int80h notwendigen op-codes) deutlich länger braucht. Ich wollte und will also möglichst genau an die "wahre" Laufzeit heran, um die Beobachtung Zanders bestätigen oder verwerfen zu können.

Und somit zurück zur ursprünglichen Frage, ob J.Zander tatsächlich Recht hat, daß der DMV ein Performanceproblem hat, welches er schlechter RAM performance zuschreibt (wohl davon ausgehend, daß die cpu tatsächlich mit 6,67 MHz getaktet war und er keinen Programmierfehler gemacht hat).

Obwohl wir unter den bisherigen Resultaten noch keinen Eintrag für einen DMV haben (die Programmversion für den DMV ist noch nicht geschrieben; da gibt es einige Probleme anderer Art (Aufsetzen/Konfigureren der ANSI-MsDos Version von TP3 auf einem "modernen" Rechner) und mir mein DMV zZt nicht zugänglich ist, um zügig voranzukommen und so nicht den Umweg über 33 Testversionen über das Forum nehmen zu müssen), lassen sich doch aus den bisherigen Ergebnissen mit 8088/V20 cpu vorab einige Informationen ziehen, die einen vorläufigen Rückschluß erlauben, ob die von Zander handgemessenen 12,8 sek für die JMPorgy zuviel sind oder nicht.

Das Cycles-Zählen sah so aus (lt. cpu manuals):

;
; NEC V20:                      8088:
; int 80h -> 50c / 2 bytes      71c
; iret    -> 39c / 1 byte       44c
; loop    -> 13c / 2 bytes      17c
;

Zu diesen Angaben der Anzahl der cycles muß aber noch bei int80 und loop jeweils 4c dazugezählt werden. Dies ist notwendig, da die Angaben zwar das Hereinholen von 1 weiteren opcode byte beinhalten, aber das jeweils 2. Byte der 2b-Befehle noch nachzuladen ist, bevor der Befehl ausgeführt werden kann.

Das macht in Summe für den

V20: 50+39+13 + 4 + 4 = 110 cycles

8088: 132 + 4+ 4 = 140 cycles

Man sieht als erstes, daß der V20 bei diesem Test deutlich besser aufgestellt ist. Alle anderen Faktoren gleich (MHz, Wait-States, ...)

sollte der 8088 rechnerisch eine um (140/110)-1 -> 27% längere Laufzeit haben.

THEORIE:

Die Abarbeitung dieser Cycles durch die beiden CPUs bei 4,77 MHz mit 500.000 Wiederholungen ergibt rechnerische Laufzeiten:

V20: 110 * 500.000 = 55.000.000 c --> 55 Mio / 4,77 Mhz = 11,53 sek

88: 140 * 500.000 = 70.000.000 c -> 70 Mio / 4,77 Mhz = 14,67 sek

Praxis:

Für den V20 (4,77 MHz) gibt es lt.Tabelle 2 Werte, aber da der eine Wert von einem Rechner mit S-RAM ist (kein refresh!!!) scheidet dieser

aus und als Vergleichswert gilt 12.955.569,500 usec.

Lt. Tabelle gibt es zwei 8088 (4,77 MHz) Einträge mit den Laufzeiten 15.117.788,442 und 15.166.749,118 usec.

Die liegen eng beieinander (gut so), der Mittelwert beträgt 15.142.268,78 usec

Ergebnis:

a) Der V20 ist in der Praxis um 1,4 Sekunden langsamer als lt. den Angaben im Manual. Das sind herzhafte 12 %.

b) Der 8088 ist um nur 0,5 Sek langsamer als er theoretisch sollte, das sind nur 3 %,

Das deutet zumindest in die Richtung, daß Zander's Interpretation seiner Handmessung überzogen war/ist.

Vielleicht sind ja die Zahlen im Manual des V20 zu optimistisch.

ABER: Er maß 12,8 Sekunden für den V20 bei 6,67 MHz.

Das ist soviel wie der Wert aus der Tabelle für den soeben besprochenen V20 bei 4,77 MHz - 12,96 Sekunden.

PAW

ad CPU Identifizierung: suche mal nach dem tool "speccy64" bzw "speccy32" im Netz ....

ad "Effizienz"-Spalte

der Grund warum im Vergleich zu anderen CPUs manche erstaunlich schlecht / gut abschneiden, liegt an der "Prozessorarchitekur" einerseits und dem Stück Programm das es abzuarbeiten hat. Der Testcode JMPorgy ist ein voll synthetischer und an sich nutzloser Code. Mit so einem Code der nichts anderes tut als 1 Million Mal (2x500000) einen "FAR JMP" auszuführen (zum int80 und retour) ist kein Blumentopf zu gewinnen. Darauf ist keine CPU seit dem 486er mehr vorbereitet, sie sind intern so ausgelegt, daß typische Programme schnellstmöglich ausgeführt werden, nicht aber so ein "Test". Er läuft dem internen Aufbau solch moderner CPUs zuwider. Daher schneiden alte CPUs im Vergleich dazu relativ viel besser ab. Den Vogel schießt hier der 486er ab, mit der schlechten "Effizienz" überhaupt. Die Werte in dieser Spalte sind für sich bedeutungslos, man kann sie immer nur im Vergleich mit anderen verwenden (also anderer Architektur) . Niedrigere Werte sind besser und bedeuten eine "produktivere" Umsetzung der MHz in Leistung (ops/sec). Die Zahl die in dieser Spalte steht kann kann man als CPU Zyklen" verstehen, die "verbraten" werden mußten/wurden, um das Testprogramm zu absolvieren. Je weniger, desto effizienter wurden die CPU clocks verwendet.

Der Analyse Teil 2:

Zuerst noch Wiederholung und eine Ergänzung zum Teil 1.

Beide CPUs absolvieren den JMP-Test langsamer als "am Papier steht", V20 um 12%, 8088 um 3%.

In der Theorie ergab sich rechnerisch ein Laufzeitunterschied zwischen V20 und 8088 von 27 % zugunsten des V20.

Die Praxis zeigte, daß dieser Unterschied real nur 16,8 % beträgt.

JZander ermittelte für den JMP-Test eine Laufzeit von 12,8 Sek, bei 6,67 MHz (V20).

Bei 6,67 MHz sollte theoretisch die Laufzeit 8,24 Sek betragen. Addiert man versuchsweise zu diesem theoretischen

Wert 12% (aus dem Praxisbeispiel oben) hinzu, ergibt das eine prognostizierte Laufzeit in der Praxis von 9,2 Sek.

Einen Eintrag für einen V20 mit 6,67 MHz haben wir in Tabelle noch nicht, auch keine Laufzeit in dieser Größe.

Aber da läßt sich dank einer beobachtbaren Linearität ein Wert errechnen.

Einmal gibt es da die 2 Ergebnisse des Commodore PC20 (8088), mit 4,77 und 9,54 MHz

und weiters den NuXT 2.0 (mit V20), ebenfalls mit 4,77 und 9,54 MHz

Man sieht an deren Ergebnissen, daß die Laufzeiten sich linear zur Taktung verhalten, doppelte MHz = halbe Laufzeit, also

offensichtlich das ganze System 1: 1 mitmacht. Das heiißt dann aber auch, daß die "Efficiency" (CPU-cycles)

gleich/stabil/konstant (bis auf ein geringes Rauschen) bleibt! Diese Logik mache ich mir im Folgenden zu eigen.

Damit läßt sich am Beispiel des Commodore PC20 (8088 !!!) ein Wert für 6,67 MHz Taktung rechnerisch aus den Praxisdaten ermitteln.

Dazu nimmt man den Wert aus "Efficiency" Spalte, die die Anzahl der verbratenen CPU-cycles angibt und dividiert sie durch

den Wert der MHz, für die man die Laufzeit errechnen möchte. Ich verwende den Commodore PC20 (8088), weil wir den Unterschied in

Laufzeit des 8088 zum V20 bereits berechnet haben und somit das Ergebnis noch korrigieren können. Der NuXT verwendet zwar den V20, aber

verwendet SRAM (ohne refresh), weshalb seine Laufzeiten von vornherein kürzer und daher nicht korrekt korrigiert werden könnte.

eff 72.289.782,1 / MHz 6,77 = 10,8 Sekunden (8088)

Korrektur: Der V20 ist lt. Praxistest 16,8 % schneller als der 8088, somit beträgt die Laufzeit für V20 (6,77 MHz) = 9,3 Sek

Wenn meine Annahmen und mein Rechengang richtig sind und JZander auch keine Fehler gemacht hat, dann hat

der DMV tatsächlich ein Problem. Gemessene Laufzeit 12,8 Sek, "errechneter" Soll-Praxiswert 9,3 Sek.

Der Unterschied ist "kein Lercherl" wie man in Wien sagt.

Ja, der Z80 dient zum Booten / Initialisieren, wenn der bootsector gelesen wurde, wird entschieden ob es mit dem Z80 (cp/m) oder 8088 (dos) weitergeht.

die motorola 68008 kann glaube ich mit dem p-system genutzt werden, habe das aber nie ausprobiert.

1ST1

ja, für alle cpus gleich.

tokabln

welche mhz zahl wurde eingegeben? 4,7 nehme ich an, oder? man sollte immer möglichst genau die mhz eingeben,

das dritte bild nehme ich an ist vom tinput - test? dieser test ist obsolet, er diente einer fehlersuche und das problem ist behoben.

beim tinput test scheint jedenfalls 4,7 eingegeben worden zu sein, weil der Kehrwert davon die angezeigten 0,2128 (gerundet) ergibt.

falls die ergebnisse von bild 1 und 2 mit 4,7 mhz eingabe gemacht wurden, der tats. takt aber 4,77 ist -> bitte test nochmal durchführen

Kennt jemand ein tool mit dem man zuverlässig bei alten rechnern feststellen kann, welche Taktung tatsächlich anliegt?

tokabln

ja, diese MHz info werde ich bei der Anzeige mit den Ergebnissen einarbeiten. Dann weiß man wenigstens (falls screenshot gezeigt wird) ob einer getrickst hat, denn diese Angabe fließt in die Berechnung der Effizienz ein.

Berechnung:

"Effizienz" = RunTime(µsec) * ( 1 / MHz) = Anzahl der CPUcycles used

1ST1

ich kann die Frage nach der Taktung des RAMs nicht wirklich beantworten. Ich glaube das funktioniert bei diesen alten Rechnern anders.

Das Anzeichen (eigentlich der Beleg) dafür sind die ausgewiesen Laufzeiten bei den Rechnern, wo jemand einmal mit 4,77 und ein weiteres Mal mit 9,54

getestet hat. Man sieht hier eindeutig, daß die Laufzeit 1:1 sich halbiert, wenn der Takt verdoppelt wird. Das heißt, das RAM wird mit der Geschwindigkeit der CPU angesprochen.

siehe:

1ST1

mein DMV läuft mit 8 MHz ... (kann aber nicht mittesten weil zZt unzugänglich verstaut)

WD (Wolfgang Dreyer) hier im forum (Techniker bei der Entwicklung des DMV) hat dazu zumindest gesagt, daß der DRAM controller im DMV genauso eingebaut und benutzt wird wie beim XT.

DIe Lösung des RAM Performance-Problems des DMV wird sich vielleicht auf ganz anderem Wege letztlich ergeben, weil zZt gerade RAM-Erweiterungsplatinen für den DMV entwickelt werden, die mit SRAM bestückt sind. Und wenn es so ist wie der Hauptentwickler funkenzupfer kürzlich feststellte, daß der DRAM controller auf dem mainboard stillgelegt werden kann, dann iwurde aus der Not eine Tugend und der DMV wird schneller als erlaubt

Wieso soll eine langsame CPU wie der Z80 (4 MHz) nicht mit RAM umgehen können, das selbst mit 8 MHz CPUs betrieben werden kann?

Nach unten ist immer Luft ...

tokabln

wenn man die ergebnisse mit denen des NuXT (S-RAM) vergelcht, dann würde ich sagen, dein Rechner hat auch S-RAM ....

oder es ist das c't bios welches den gleichstand trotz DRAMS herstellt ...