Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

16.11.1984 - 

Leistungsvergleich verschiedener Betriebssystem-Implementierungen:

Elf Minirechner und Mikrocomputer in der Arena

Wäre jedes System ein gesunder Baum, würde bald keiner mehr vom Waldsterben reden. Ein nobler Vergleich, der leider über die eigentliche Problematik hinwegsehen läßt. Denn diese Naturverbundenheit verdeutlicht geradezu treffend die Sorgen des DV-Anwenders, der Im System-Dschungel vor lauter Bäumen schon keinen Wald mehr sieht. Die Flut an Information, die sich täglich auf seinem Schreibtisch stapelt, zeigt ihm zwar, daß Systeme stets billiger und besser werden. Welches für Ihn wohl das richtige sein mag, weiß er dann noch lange nicht: Welche Kriterien sind ausschlaggebend? Wie kann er Leistung und Preis verschiedener Systeme vergleichen? Sich da auf die Antwort von Verkäufern oder gut gestalteter Werbung zu verlassen, scheint doch sehr gewagt zu sein. Die folgenden Zellen sollen eine kleine Hilfe geben: Benchmarktests mit elf Mini- und Microcomputersystemen, alle multiuser- und multitaskingfähig unter verschiedenen Unix-Versionen, zeigt unter realen Bedingungen, was das Zusammenspiel von Hard- und Software jeweils an Leistungen hervorzaubert.

Die zum Benchmarktest benötigten Programme stammen aus dem US-Magazin BYTE, Ausgabe 8/84. Die getesteten Systeme sind alle in Deutschland erhältlich.

Die Benchmarktests ermöglichen einen direkten Vergleich der Systeme und zeigen die Leistungsfähigkeit vom Betriebssystem Unix, seiner Implementierungen und von der angewandten Hardware-Architektur. Die multiuser- und multitaskingfähigen Systeme sind für 4 bis 16 Plätze ausgelegt und kosten zwischen 50 000 und 150 000 Mark. Der IBM PC/XT, der Apple Lisa und die VAX-Rechner fallen preislich aus diesem Rahmen heraus, wurden aber berücksichtigt, um eine bessere Orientierungshilfe oder Vergleichbarkeit zu ermöglichen. Hier wäre anzumerken, daß die VAX-Rechner ursprünglich nicht für Unix ausgelegt sind und wohl auch in diesem Fall nicht ihre volle Leistung bringen. Da aber die Nachfrage nach dieser Konfiguration von Hard- und Software steigt, gab es keine Bedenken, die Systeme mit in den Test einzubeziehen.

Unix mausert sich zum Standard-Betriebssystem. Mehrere Versionen sind erhältlich: Version 6, Version 7, System III, System V (der neue Standard von AT&T, der bereits der MUNIX 5.2-Version von PCS zugrunde liegt), die Erweiterungen 4.1 BSD und 4.2 BSD Unix, Xenix, eine verbesserte Version von Version 7, Venix, mit Echtzeit-Möglichkeit, und andere.

Arbeiten alle Versionen gleich? Welche ist besser? Welche Kriterien müssen zur Vergleichbarkeit angesetzt werden?

Der Vergleichstest eines Betriebssystems ist weitaus komplexen als der eines Compilers. Optimal wäre, fest definierte Funktionen des Betriebssystems (etwa Pipe-Implementierung, Datendurchlauf der Platte, Aufwand des System-Aufrufs) zu testen. Dies ist nur sehr schwer durchführbar, da jedes Programm, das eine bestimmte Funktion des Betriebssystems durchführt, zusätzliche Befehle einbezieht, die bei der Prüfung nicht mit der eigentlichen Funktion zusammenhängen. Benötigt werden aber Programme mit möglichst wenig überflüssigen Befehlen.

Diese Befehle variieren von Programm zu Programm. Die Durchführzeiten können so schlecht zu einer Aussage über die Schnelligkeit einer bestimmten Betriebssystem-Funktion benutzt werden. Allerdings können sie zum Vergleich mit anderen Systemen herbeigezogen werden.

Praktischer ist es, typische, vom Anwender aufgerufene Funktionen wie Sortieren Kompilieren, Erstellen, Listen oder Löschen von Datensätzen auszufahren. Auch hier können die Zeiten untereinander verglichen werden.

In diesem Benchmarktest werden die beiden beschriebenen Möglichkeiten berücksichtigt.

Ein Benchmarktest kann nur praxisbezogen sein, wenn Vorgänge verarbeitet werden die auch der täglichen Anwendung entsprechen. Unix hat zahlreiche Eigenschaften, die sehr oft benutzt werden. Sind sie effizient implementiert, können sie die eventuellen Nachteile einer langsamen Hardware ausgleichen. Umgekehrt kann eine leistungsfähige Hardware mit einer schlechten Implementierung zum. Flaschenhals werden.

Unix ist ursprünglich auf einem System mit geringer Speicherkapazität entwickelt worden. So ist der Platten-Zugriff sehr intensiv. Diese Tatsache wird in den Tests berücksichtigt.

Alle Anfragen des Benutzers werden von der Shell, der Schnittstelle zum Betriebssystem, bearbeitet. So ist auch diese Schnittstelle Test-Gegenstand.

In den folgenden Tests werden verschiedene Zeiten gemessen: Die Gesamtzeit, die Benutzerzeit und die Systemzeit.

Die Systemzeit ist die Zeit, die die CPU benötigt, um vom Benutzer-Programm aufgerufene Routinen zu verarbeiten. Unter Benutzerzeit versteht man die Zeit, in der der Rechner sich in dem Benutzer-Programm befindet. Die Gesamtzeit ist die Summe von Benutzer-, System- und Administrationszeit (Zeitaufwand für interne Verwaltungs-Routinen).

Aufgrund der verschiedenen Implementierungen der Unix-Zeitmeßfunktionen treten manchmal leichte Unstimmigkeiten auf, die die Gesamtzeit kleiner erscheinen lassen als die Summe von Benutzer- und Systemzeit.

Benutzer- und Systemzeit ergeben zusammen die Verarbeitungszeit des Prozessors.

Die angewandten Richtlinien für die saubere Durchführung des Benchmarks sind im Kasten gesondert beschrieben.

Programm 1: Die Pipe

Die Pipe ist eine I/O-Leitung, die von einem Programm geladen und von einem anderen gelesen wird. Pipes werden von einer Anzahl von Unix-Utilities benutzt (unter anderem von der Unix-Benutzer-Schnittstelle Shell) und oft auf Platte gepuffert. Die Pipe ermöglicht Hintergrund-Bearbeitung verschiedener Prozesse wie Sortieren, Kompilieren etc. ohne die Arbeit des Anwenders zu Beeinflussen. Die Pipe kann in ihrer Funktion mit der eines Drucker-Spoolers verglichen werden.

Programm 1 generiert einen Prozeß, um die Pipe mittels des Systems-Aufrufs zu lesen und überspielt 0,5 NB auf die Pipe-Leitung.

Außerdem wurden die Zeiten gemessen, die das Programm braucht, um System-Aufrufe wie

fork()

read()

write(), etc.

auszufahren.

Zwei wichtige Ergebnisse des Programms sind die System- und die gesamte abgelaufene Zeit. Die Systemzeit zeigt, wie lange das Programm braucht, um das Piping herzustellen und auszufahren und ist so ein direktes Maß an Leistungsfähigkeit der Pipe. Die beste Gesamtzeit bei diesem ersten Test erreichte die VAX 11/780 mit 3,9 Sekunden. Auch bei der Systemzeit schnitt die VAX mit 1,2 Sekunden am besten ab, dicht gefolgt vom Zilog-Rechner 8000/32 mit 15 Sekunden.

Mit der Gesamtzeit kann die Geschwindigkeit der Platte ermittelt werden. Gesamtzeit minus Systemzeit minus Benutzerzeit ergibt den Zeitaufwand der Festplatte. Diese, Zeit ist besonders für Mikrocomputer wichtig, da diese meist keine sehr schnellen Plattenlaufwerke haben. Die Benutzerzeit ist von geringer Bedeutung.

Programm 2: System call

Programm 2 mißt den Zeitaufwand des System-Aufrufes

getpid()

indem das Betriebssystem 25 000 mal hintereinander abgefragt wird.

Diese, Information wird in einem Zentralspeicher festgehalten, der Zugriff ist entsprechend schnell, solange keine anderen Prozesse den Prozessor beeinflussen oder befragen. Daher auch die Notwendigkeit eines unbelegten Systems (siehe auch Kasten). Bei diesem Programm ist die Gesamtzeit interessant, da der Gesamtaufwand des Systems gemessen werden soll. Die Systemzeit liegt nahe bei der Gesamtzeit, die Benutzerzeit ist entsprechend klein, und beide haben eine geringere Bedeutung für den Test.

Auch bei diesem Test liegen die VAX 11/780 und die Zilog 8000/32 mit Abstand ganz vorne. Die Zeiten betragen jeweils 4,8 und 5 Sekunden.

Programm 3: Function call

Programm 3 ermittelt die benötigten Zeiten für verschiedene Funktions-Aufrufe, die für die Leistungsfähigkeit des C-Compilers ausschlaggebend sind.

Es gibt verschiedene Möglichkeiten, den Zeitaufwand eines Funktions-Aufrufes zu messen. Die hier benutzte Methode ist genauer als andere. Zwei Programme werden geschrieben: Ein Programm benutzt eine Funktion um ein bestimmtes Ziel zu erreichen. Das andere benutzt diese Funktion nicht. Nach dem Durchlauf beider Programme wird die Zeit des zweiten Programmes von der des ersten Programmes subtrahiert. Diese Differenz stellt den benötigten Zeitaufwand der Funktionsaufrufe dar und kann durch die Anzahl der Aufrufe dividiert werden (hier 50 000), um den Zeitaufwand eines einzigen Aufrufes zu ermitteln. Diese Zeiten werden dann von System zu System verglichen.

Mit dem C-Preprozessor ist es möglich, zwei verschiedene Programme in einer Textzeile unterzubringen. Das Programm für die Funktions-Aufrufe ist einmal mit -DEMPTY (zum Generieren des Programms mit Funktions-Aufruf) und mit -DASSIGN (zum Generieren des Programms, das diese Funktion nicht benutzt).

In der Berechnung des Zeitaufwandes wird die Benutzerzeit und nicht die Echtzeit verwendet, weil die Benutzerzeit sehr viel genauer ermittelt werden kann. Da ein nichtrelatives numerisches Ergebnis, das keine virtuelle Systemzeit benutzt, erzeugt wird, ist es wichtig, eine Messung mit einer größtmöglichen Genauigkeit zu haben.

Bei diesem Test lag das Altos-System 98 6 mit 0,4 Sekunden mit Abstand vorne, Die Sun 2/120 benötigt die doppelte Zeit.

Programm 4: Das "Sieb des Eratosthenes"

Oft wird ein Compiler-Benchmarktest mit dem bekannten "Sieb des Eratosthenes" assoziiert, der die Leistungsfähigkeit des C-Compilers und den Durchsatz des Prozessors recht gut testet. Es ist ein gutes Programm, um die Merkmale von Schleifendurchläufen, Tests und Inkrementierungen zu prüfen. Programm 4 ist eine leicht veränderte Version dieses "Siebs". Alle unnötigen Ein- und Ausgaben wurden hier beseitigt. Dafür wurden für möglichst viele Variablen Register-Deklarationen vorgenommen. Hier ist die Gesamtzeit die wichtige Zeit. Die Benutzerzeit ist der Gesamtzeit ähnlich, die Systemzeit ist sehr klein.

Das Zilog-System 8000/32 war bei diesem Test am schnellsten und brauchte genau 1 Sekunde, gefolgt von der VAX 1 1 /780 (1,7 Sekunden).

Programm 5: Disk write, disk read

Mit dem Pipe-Test wurde die Grenze der Platten-Leistungsfähigkeit fast erreicht. Eine gründlichere Beleuchtung ist aber sinnvoll. Mit Unix sind Möglichkeiten des sequentiellen und des direkten Zugriffs auf die Platte möglich. Die Tests 5a und 5b testen die Implementierung des Platten-Direktzugriffs. Programm 5a erzeugt, öffnet und schreibt eine 256 x 512-Bit-Datei. Die Anzahl der manipulierten Blöcke ist durch die Aussage

# define

spezifiziert, und kann leicht verändert werden, wenn sie für die Implementierung eines kleinen Mikrocomputers zu umfangreich ist.

Das Programm 5b öffnet und liest direkt die von Programm 5a erzeugte Datei. Da der Plattenzugriff meist direkt erfolgt, berücksichtigt dieser Test keinen sequentiellen Zugriff.

Da die in Programm 5a erzeugte Datei relativ umfangreich ist, kann sie nicht auf einem einzigen Segment einer Platte abgelegt werden. Sie wird in mehrere Blöcke unterteilt, in Abhängigkeit davon, wie von das Dateiensystem gerade ist. Leistungsfähige Unix-Implementierungen unterteilen eine Platte in mehrere logischen Speicherzonen. Jede Speicherzone ist dann ein Dateiensystem. Wird ein solches Dateisystem erzeugt, sind alle benötigten Speicherzonen aneinandergrenzend.

Der Test sollte auf jeden Fall in einem aktiven, geordneten Dateiensystem laufen, um praxisnahe Ergebnisse zu ermöglichen. Dieser Benchmark ist in großem Maße von der Plattenaufteilung abhängig, und zeigt so auch die jeweiligen Plattenmerkmale.

Bei diesem Test ist die Gesamtzeit wichtig, da die Wartezeit für die Beendigung der Ein- und Ausgabe-Routinen nicht jeder Benutzer- oder Systemzeit zugeordnet wird.

Beim Beschreiben der Platte waren die Systeme Cadmus 9200 und Sun 2/120 mit 1 7 und 1,8 Sekunden am schnellsten. Beim Lesen lag die Zilog-Maschine 8000/32 mit 4 Sekunden wieder ganz vorne,

Programm 6: Allgemeiner Shell-Test

Dieses Programm simuliert die praktische Anwendung des Systems. Es ruft einige typische Unix-Kommandos auf und benutzt sie für den direkten Platten-Zugriff. Von der Möglichkeit der direkten und indirekten Adressierung des Shell-I/O zum Sortieren Speichern, Manipulieren und Lesen einer Liste von Wörtern wird bei diesem Programm Gebrauch gemacht. Die benutzten Utilities (sort, od, grep, tee, wc, rm) sind alle Standard-Unix-Tools. Durchführzeiten für dieses einfache Programm schwanken erheblich von Rechner

zu Rechner.

Bei allen drei ermittelten Zeiten (Gesamt-, System- und Benutzerzeit) war die Zilog 8000/32 am schnellsten. Die Werte stehen in der Tabelle.

Programm 6b: Multitasking-Benchmark

Nimmt man Programm 6a als Basis, kann es im Hintergrund öfter aufgerufen werden, damit zu sehen ist, wie lang das System benötigt, um das Programm 1, 2, 3, 4, 5 oder 6mal durchlaufen zu lassen.

Das Bild zeigt die grafische Darstellung der benötigten Zeiten für die Hintergrund-Durchläufe. Diese Durchläufe simulieren keineswegs das Laden des Programmes durch andere Benutzer, weil diese Hintergrund-Durchläufe eine geringere Priorität haben. Sie zeigen aber, wieviele Prozesse ein System komfortabel im Hintergrund laufen lassen kann.

Dies ist ein wichtiges Merkmal für kleinere Systeme, da hier ein Benutzer oft nur einen beschränkten Speicherplatz oder eine beschränkte Prozessor-Leistung zur Verfügung hat, Weiterhin limitieren manche Unix-Implementierungen die Anzahl von zu Öffnenden Dateien oder von zu laufenden Prozessen, auch bei einer geringen Anzahl von Benutzern.

Programm 7: Loops

Dieses kleine Programm testet ganzzahlige Arithmetik und ist voll, an die Rechenleistung des Prozessor gebunden.

Die VAX 11/780 kommt hier als schnellstes System auf eine Zeit von 2,6 Sekunden, gefolgt von dem Zilog-System 8000/32 (Zeit: 4 Sekunden).

Die kleineren Systeme von IBM und Apple sind noch lange nicht reif, um mit Maschinen von Altos, Sun oder Zilog zu konkurrieren. Interessant ist jedoch, daß der IBM PC bei manchen Durchläufen bessere Werte erzielte als die PDP 11/23 (etwa beim Lesen einer Datei von der Platte).

Bei Multitasking-Betrieb gehen IBM und Apple ganz schnell in die Knie. Wo bei einem einzigen Background-Prozeß das Zeitverhältnis IBM PC/ XT, Zilog 8000/32 bei rund 5 liegt, beträgt es bei 6 Prozessen rund 14. Dann braucht nämlich das Zilog-System 9 Sekunden, bei IBM muß der Anwender ganze 130 Sekunden warten.

Leistungen alleine zählen nicht. VAX und Zilog liegen in diesem, Benchmarktest eindeutig ganz vorne. Der Test soll dem Anwender lediglich eine Orientierungshilfe sein, und so sollte er auch verstanden werden. Denn weitere Faktor en spielen eine Rolle: Zunächst einmal der Preis eines Systems. Dann kann der Anwender sich viel Ärger sparen, wenn er vorher Punkte wie Dokumentation, Service und Support berücksichtigt.

Testvoraussetzungen

1. Die Tests sollten in einer Multiuser-Umgebung durchgeführt werden. damit der übliche Aufwand des Betriebssystems berücksichtigt wird. Einige Unix-Implementierungen bieten sowohl ein Single-user- als auch ein Multi-user-Modus.

2. Die Benchmarks müssen mehrere Male durchlaufen werden, damit eine Durchschnittszeit ermittelt werden kann, um eventuell Zeiteinbußen, hervorgerufen durch Hintergrund-Durchläufe auszugleichen.

3. Die Tests, sollten dann durchgeführt werden, wenn das gesamte System ruht, damit die zu ermittelnden Zeiten möglichst nicht von der Arbeit anderer Benutzer beeinflußt werden. Bei kleineren Systemen kann ein einziger zusätzlicher Benutzer die Werte völlig verfälschen, (siehe Programm 2, system call)

4. Sämtliche Optimierungsmöglichkeiten sollten genutzt werden. Zum Beispiel eine Compiler-Option für Objekt-Code-Optimierung oder schnelle Register, wenn die Hardware sie unterstützen kann. In diesen Benchmarktests sind alle Variablen, die Register sein können, als solche deklariert.

5. Die Programme müssen auf allen Systemen exakt übereinstimmen. Die Benutzung bestimmter Softwareerweiterungen (zum Beispiel eine Binärbaum-Suchfunktion) stellt keine Optimierung dar, Um einen objektiven Vergleich verschiedener Systeme zu ermöglichen, sollen wirklich nur Optimierungsmöglichkeiten benutzt werden.

6. Einige Tests können spezifische Funktionen der Betriebssystem- und Compiler (C)-Implementierung ausfahren.

7. Die Programme beinhalten auch das Testen allgemeiner Leistungen, Indem sie alltäglich auftretende, typische Benutzer-Kommandos simulieren. So zum Beispiel das Durchlaufen von Background-Prozessen, um die Leistungen der Systeme bei Mehrplatzbetrieb zu ermitteln,

8. Unix hat eine Zeitmeß-Funktion, die die Gesamtzeit und die Prozessorzeit ermittelt. Die Prozessorzeit Ist unterteilt in Benutzer- und Systemzeit.