Unterthema: Ausstattung der C-Compiler
Unterthema: Paralleles C
Unterthema: Benchmarkergebnisse
Unterthema: Ergebnisse auf einen Blick
An sich sollte man meinen, da� C-Compiler sich doch weitgehend �hneln m�ssen, gerade wenn sie beide auf einem PC mit mindestens einer Transputer-Karte (kompatibel zu einer TEK 4/8 oder einem B004-Board von Inmos) laufen. Doch (leider) gibt es viele Unterschiede, was Portierungen nicht eben einfach macht, insbesondere bei der Implementierung von `Parallelit�t� kocht jeder seine eigene Suppe.
Die Dokumentation ist sinnvoll gegliedert, gut zu lesen und l��t selten Fragen offen - wenn man des Englischen kundig ist. Fragen waren in der Regel schnell durch einen Blick in das passende Handbuch zu kl�ren. Gute Dokumentation - das ist eine pers�nliche Auffassung - zeichnet sich auch dadurch aus, da� man schnell in ihr das findet, was man sucht. Differenzen zwischen Software und Beschreibung waren nicht festzustellen; das ist ja selbst bei Produkten dieser Preislage nicht immer der Fall.
Auch die Installation machte keine Probleme. Nach 16 Minuten des Diskettenwechselns, der Beantwortung einiger Fragen, sowie einigen Eintragungen in der autoexec.bat und config.sys, konnte mit einem Probelauf begonnen werden. Das erste `Hallo Welt� lief sofort. Leider waren einige Fragen der automatischen Installation erst nach gr�ndlichem Lesen des `Delivery Manuals� zu beantworten. Man sollte den Benutzer lieber bei der Installation weniger fragen und mehr installieren. Wenn etwas fehlt, ist dies f�r den Anf�nger nur schwer zu beheben.
Als sehr n�tzlich hat sich das `Handbook� herausgestellt. Da in ihm alle Optionen und Funktionen beschrieben sind, hat es in den meisten F�llen zur S�ttigung des Informationshungers ausgereicht. Eine Idee, die auch andere Hersteller aufgreifen sollten.
Leider lie� das Werk die Klarheit und Ausf�hrlichkeit des Inmos-Handbuchs vermissen. Einige beschriebene Optionen kannte der Compiler nicht (man mu�te die �nderungen einem Readme-File entnehmen). Nicht selten war mir nur noch in Erinnerung, etwas gelesen zu haben; zu finden war es dann erst nach l�ngerem Suchen.
Auch die Beschreibung der Installation war nicht vollst�ndig. Ein Hinweis fehlte, was alles in die autoexec.bat einzutragen ist. Dementsprechend gelang die komplette Installation nicht auf Anhieb. Einem kundigen PC-Benutzer sollte sie jedoch keine Schwierigkeiten machen. Nach sechs Minuten war der Compiler in der Lage, sein `Confidence testing� erfolgreich zu durchlaufen.
Sehr ausf�hrlich und gut gelungen sind die Beschreibungen zu den Erweiterungen von C, die Parsec f�r die Implementation der Parallelit�t in C eingef�gt hat. (Die Firma nennt die so erweiterte Sprache `Parallel C�, und ihr `Par C� die erste Implementation dieser Sprache). Die in diesem Kapitel angewandte Sorgfalt sollte Parsec/ACE auf alle Kapitel legen. Da beide Compiler keine Online-Hilfen bieten, sind die Handb�cher die einzige Informationsquelle bei Fragen, Fehlern und Unklarheiten.
Wie die vielen Disketten schon vermuten lassen, sollte man etwas gr��eres als einen XT mit Floppy besitzen, um die Compiler benutzen zu k�nnen. Das Inmos-C ben�tigt gute sieben Megabyte Plattenplatz, Par-C begn�gt sich mit zwei Megabyte. Beiden gemeinsam ist, da� ein schneller Rechner nicht schaden kann. Er braucht nicht viel Speicher zu haben (ein MByte reicht), aber flott sollte er sein. Der Test-Rechner war ein 386er mit 25 MHz Taktfrequenz; damit l��t sich arbeiten.
Der Compiler allein macht es nicht. Heutzutage ben�tigt man f�r eine z�gige Entwicklung neben dem �bersetzer noch diverse Hilfeprogramme, die die Arbeit erleichtern, Fehler verhindern und finden helfen. Besonders wichtig sind hierbei ein Debugger und ein Make. Wer schon einiges entwickelt hat, wei�, da� er diese beiden Tools neben dem Compiler am h�ufigsten braucht. Weiter hilfreich sind ein Editor, der auf den Compiler abgestimmt ist, ein separater oder integrierter Assembler, ein Librarian (Library-Verwaltungsprogramm), ein Profiler, Cross-Referenz-Tools, Object-Analyse-Programme, ein Programm zur Volltextsuche (grep zum Beispiel) und eventuell eine Oberfl�che (wie bei Borlands Turbo-Familie).
Wie kann man einen Compiler dieser Preisklasse so `nackt� verkaufen? Damit lassen sich zwar Programme erzeugen, aber kaum entwickeln, wenn man unter diesem Begriff zumindest noch das Debuggen fa�t. Da es sich bei den produzierten Programmen um solche f�r Transputer handelt, kann man auch nicht auf andere (PD-)Tools zur�ckgreifen; gar nicht zu denken an bestimmt auftretende Probleme in einem Transputer-Netz.
Der Source-Level-Debugger sucht seinesgleichen. Er hat diverse Funktionen, die auch die Suche nach Fehlern im Netz stark vereinfachen. So kann er beispielsweise Breakpoints verteilt �ber viele Prozessoren setzen, und stets die Source zu einem erreichten Breakpoint pr�sentieren. Hat man nur einen Transputer, so mu� man allerdings mit dem Postmortem-Modus vorlieb nehmen, da der Debugger immer einen Transputer f�r sich beansprucht. Hierzu existiert ein Programm namens `idump�, das auf Wunsch auch das komplette Netz in ein Postmortem-File verwandelt, das anschlie�end entwanzt werden kann.
Obgleich auf dem PC-Sektor Entwicklungsoberfl�chen nicht selten sind (und Inmos mit dem TDS keinen schlechten Wurf getan hatte), lassen sich alle - sowohl die Inmos- als auch die Parsec-Tools - nur �ber den COMMAND.COM `bedienen�. Bedienungskomfort erh�lt man erst nach dem Schreiben diverser Makefiles und Batch-Dateien.
Auch in der Art, wie ein Programm auf mehrere Transputer aufgeteilt wird, unterscheiden sich die beiden Kandidaten. Inmos w�hlt den konventionellen (statischen) Weg, eine Konfigurationsdatei zu erstellen, die ein Transputer-Netz und die darauf zu verteilenden Prozesse beschreiben. Daf�r hat man extra eine einfache, C-�hnliche Sprache entwickelt, um trotz der statischen Beschreibung m�glichst flexibel zu bleiben.
Nach dem Linken ist noch ein Konfigurations- und Sammeldurchlauf vonn�ten, wobei f�r jeden Transputer angegeben werden mu�, welche Prozesse auf ihm laufen, welche Verbindungen nach au�en wie hei�en, und so weiter. Nach dem Konfigurieren sind alle gebundenen und konfigurierten Dateien zu einem bootf�higen Programm zusammenzuholen: das erledigt das mitgelieferte Programm `icollect�. Das Konfigurieren kann entfallen, wenn man nur einen Transputer hat.
Diese Methode ist weitaus flexibler als die von Inmos, da man vor dem Start des Programms schnell noch ein paar Karten hinzustecken kann, um einer Probleml�sung Beine zu machen. Sie hat aber auch einen Nachteil: auf jedem Transputer mu� eine Kopie des gesamten Programms vorhanden sein. Wird das Programm zu gro�, mu� man alle Transputer mit mehr RAM versorgen.
Die Tabellenwerte zeigen, da� beide Compiler recht lange brauchen (das Inmos-C f�llt beim Linken kleiner Dateien besonders unangenehm auf). Der Flaschenhals - so k�nnte man vermuten - sei hierbei das 8-Bit-Link-Interface zum Transputer. Doch bis auf den Compiler und den Debugger des Inmos-C habe ich in diesem Test nur die PC-gest�tzten Tools verwendet, die ausschlie�lich auf dem PC laufen. Zwar liefert Inmos alle Programme auch in einer f�r Transputer ausf�hrbaren Form aus, diese sind jedoch noch viel langsamer. So gelang es nicht, mit dem Linker f�r den Transputer ein leeres Programm unter 36 Sekunden zu linken (einem Inmos-Mitarbeiter gelang dies nach eigener Aussage sehr wohl, doch das ist eine andere Geschichte).
Entgegen einiger Andeutungen im Handbuch laufen alle Programme des Par-C ohne Transputer. Beim Linken merkt man dies besonders. Der Linker arbeitet recht flott. Er hat auch keine 1,2 MByte gro�e Library zweimal zu beackern wie der Inmos-Linker, denn alle Libraries des Par-C-Compilers machen zusammen nicht einmal 100 KByte Code aus. Hier kann man sehen, was ein paar Optimierungen bringen k�nnen.
Die Programmgr��en gehen in Ordnung, denn der Transputer wird als CPU ohne Betriebsystem genutzt. In jedem Programm mu� das komplette Server-Protokoll zwischen Transputer und Host-PC eingebaut sein. Wenn da noch ein `printf()� und ein paar kleinere Routinen zusammenkommen, sind 20 KByte nicht zuviel. Ein `Hello World� auf einer Sparc `wiegt� dagegen 105 KByte. Wer will sich da noch beklagen?
Setzt man jedoch die 680 Zeilen der Whetstone-Source in Beziehung zu den 25 Sekunden, die es vom Source zum ausf�hrbaren Programm braucht, so l��t das erahnen, wie viel Zeit man an einem PC mit Warten verbringen mu�, wenn man an gr��eren Projekten arbeitet. Auf meinem 68030-System ben�tigt ein Compiler-Durchlauf inklusive Linken 7 Sekunden, Turbo-C l�uft da noch einiges schneller. Wo bleibt die Zeit?
Die Ausf�hrungszeiten sind leider nicht so, wie die langen Arbeitszeiten der Compiler vermuten lassen. Insbesondere die Dhrystone-Werte machen stutzig: F�r eine 32-Bit-CPU bei 25 MHz sollten schon 6000 bis 7000 Steinchen drin sein. Auch die kWhetstones sind nicht �berragend. In einem Werbeblatt zum Par-C-Compiler waren bessere Zeiten zu finden, doch trotz des Verlegens von Code und Data ins interne RAM lie� sich der Wert nicht �ber 1000 kWhetstones bringen.
Auch Inmos vermeldete weit bessere `Stone-`Ergebnisse. Nun haben Hersteller sicher die M�glichkeit und auch die Neigung, sich optimale Konfigurationen hinzustellen und zu nutzen, so da� auch Benchmarks die besten Ergebnisse liefern.
Oft st��t man im Handbuch zum Par-C auf den Begriff ANSI-C. Doch leider sind nur der Preprocessor und die Libraries (fast) ANSI-C-kompatibel. Der Compiler ist es nicht. Er unterst�tzt keine Prototypes und erlaubt auch nicht die Angabe der Parameter-Typen direkt hinter dem Funktionsnamen vor den Parameter-Bezeichnern. In der Library sind aber keineswegs alle ANSI-C-Funktionen zu finden. Wie so viele Hersteller hat sich Par-C die `locale�-Funktionen gespart; setjmp.h mit den Deklarationen zweier R�cksprungfunktionen fehlt ebenfalls.
Aus diesem Grund mu�ten einige Test-Programme an Par-C angepa�t werden. ANSI-C war und ist ein wichtiger Schritt in die richtige Richtung und sollte von keinem C-Compiler-Hersteller mehr mi�achtet werden. Es ist nicht klar, warum Parsec dies noch nicht ber�cksichtigt hat.
Das Inmos-C dagegen gl�nzt durch absolute Kompatibilit�t und unterst�tzt dar�ber hinaus auch 16-Bit-Transputer. Dies macht das Inmos-C besonders f�r Maschinensteuerungen interessant, da in einer genormten Hochsprache programmiert werden kann.
Die Idee ist faszinierend, aber die Implementierung noch nicht. Par-C mangelt es an manchem: an umgebenden Tools, an noch besserer Dokumentation, an ANSI-C-Konformit�t, an Fehlerfreiheit. Auch so Kleinigkeiten wie das Fehlen einer Meldung, wenn das Transputer-Errorflag gesetzt ist - das Transputer-Programm steht und es passiert nichts -, zeigen, da� an diesem Produkt noch gearbeitet werden mu�.
Inmos-C dagegen ist bieder, aber gut. Es ist nicht schnell, bietet auch nicht alles, was man gerne h�tte - aber das, was man bekommt, ist grundsolide, funktionell und bestens beschrieben; etwas mit dem man arbeiten und auf das man sich verlassen kann. Man sollte sich in England dazu durchringen, noch ein Make mitzuliefern und dem Linker ein wenig Beine zu machen. Sonst bleibt wenig an dem Produkt auszusetzen.
Da� Inmos das andere Konzept bei der Implementation von Parallelit�t gew�hlt hat, ist auf den zweiten Blick auch nicht so bedeutsam. Denn Parallelit�t auf einem einzigen Transputer macht wenig Sinn, und bei mehreren ist auch beim Par-C-Konzept die Eleganz dahin. Dann n�mlich reicht das `par�-Statement allein auch nicht mehr aus und man mu� mit geeigneten Programmkonstruktionen (if, for ...) entscheiden, auf welchem Prozessor gerade welcher Code laufen soll. Und damit bleibt letztendlich doch alles am Programmierer h�ngen, egal welches C er nun benutzt - auch wenn es ihm im einen Fall leichter gemacht wird. (bb)
[2] David G�hler, C-Zaren, Lattice 5.0 und Aztec 5.0 f�r den Amiga im Vergleich, c't 5/90, S. 92
| Par-C 1.31 | Inmos-C 1.42f | ||
| Compiler | |||
| Kommando-Zeile | + | + | |
| integrierte Oberfl�che | - | - | |
| ruft Linker | + | - | |
| Inline-Assembler | + | + | |
| T2-Support | - | + | |
| FPU-Direkt-Support | + | + | |
| Assembler-Output | + | + | |
| ANSI-kompatibel | - | + | |
| Editor | - | - | |
| separater Assembler | + | - | |
| Cross-Referenz-Lister | + | + | |
| Librarian | - | + | |
| Assembler-Debugger | - | ++ | |
| Source-Level-Debugger | - | ++ | |
| Make | - | - 2) | |
| Objekt/Library-Analyse | - | + | |
| weitere Analyse-Programme | - | + | |
| Profiler | + 1) | - | |
| Hilfsprogramme wie grep,diff... | - | - | |
| Installations-Programm | + | + | |
| Dokumentation | +- | ++ | |
| in Deutsch | - | - | |
| Bibliotheken ANSI-kompatibel | - | + |
- nicht vorhanden,
+ vorhanden
++ vorhanden und sehr gut
+- vorhanden, aber mit M�ngeln
1) im Source zum �bersetzen
2) es existiert jedoch ein Makefile-Generator
Inmos ging den ersten Weg, Parsec mit Par-C den zweiten. Der Erstgenannte hat den Vorteil, den Pfad der Tugend - des reinen C - nicht zu verlassen, daf�r aber den Nachteil, so manche Verrenkung beim Programmieren in Kauf nehmen zu m�ssen. Was in Occam eine einfache Anweisung war, f�hrt in C jeweils zu einem Funktionsaufruf. Dies ist h�ufig nicht nur schlechter zu lesen, es zwingt den Programmierer oft, selbst Ressourcen zu allozieren, zu testen, ob er sie erhalten hat, und zuletzt wieder freizugeben. In Occam war das nie ein Thema.
Par-C dagegen ist die Implementierung von `Parallel C� - ein Standard-C mit drei Erweiterungen: der `par�-Anweisung, dem Datentyp `channel� und der `select�-Anweisung. Sie entsprechen weitgehend den Occam-�quivalenten.
M�chte man bei einer Anweisung keine Funktion aufrufen, sondern mehrere Anweisungen nacheinander ausf�hren lassen - jedoch parallel zu allen anderen innerhalb des par-Blocks -, so ist, wie in C �blich, ein Block mit geschweiften Klammern zu benutzen. Ein Beispiel:
par
{
lieswas(ein, zwei);
tuwas();
{ i = 5;
j = i + 5;
}
schreibwas(drei);
}
In der komplizierten Form hat das par die Syntax der for-Anweisung. Dieses Beispiel erzeugt acht parallele Prozesse, die alle die Funktion `BerechneSpalte� aufrufen:
par (i=0; i <8; i++)
{
{ BerechneSpalte(array,i);
}
}
Jeder Proze� bekommt aber sein eigenes `i�. Die Kompatibilit�t zum for geht sogar soweit, da� ein
par (;;)erlaubt ist, was aber stets zu einem Runtime-Error f�hrt - wer hat schon unendlich viel Speicherplatz?
channel reinraus;Nun kann man die Variable `reinraus� wie bei jedem anderen elementaren Datentyp (wie int, long, char ...) auch in Zuweisungen und Funktionsaufrufen benutzen. Steht `reinraus� links in einer Zuweisung, wird der Wert der Zuweisung in den Kanal geschrieben, steht sie rechts, wird sie aus dem Kanal gelesen. Es lassen sich auch Felder aus Kan�len definieren, oder Kan�le in Strukturen unterbringen. Es geht alles, was mit einem elementaren Datentyp zu machen ist.
Eine m�gliche Kette von parallellaufenden Prozessen, die verzahnt Daten weiterreichen, sieht so aus:
channel feld[10]; int i;
par
{
berechne_irgendwas(0, 0L, feld[0]);
par (i = 1; i <= 9; i++)
{
berechne_irgendwas(i, feld[i-1], feld[i]);
}
berechne_irgendwas(9, feld[9], 0L);
}
Wie in Occam ist es m�glich, mehrere Kan�le gleichzeitig abzuhorchen. Kommt etwas an irgendeinem Kanal an, verzweigt select in die passende Routine, die die ankommenden Daten entgegennimmt. Anders als in Occam wird hierbei jedoch das Byte, welches den Kanal aktiviert und die select-Anweisung dazu bringt, in eine bestimmte Funktion zu verzeigen, nicht von der select-Anweisung geschluckt. Es mu� von der aufgerufenen Funktion gelesen werden. Dies ist aber in den meisten F�llen von Vorteil, da ein verschicktes Byte meist auch eine auszuwertende Bedeutung hat.
Auf ein Beispiel m�ssen wir hier verzichten, da die Syntax und die Funktion von select zu viele Erkl�rungen erfordern w�rde.
| Name | Source | Comp-Zeit | Object | Link-Zeit1) | Code |
| Leer | 21 | 4 | 274 | 14 | 20393 |
| Hello | 71 | 5 | 345 | 14 | 24517 |
| Ackermann | 820 | 7 | 745 | 16 | 29877 |
| Quicksort | 1028 | 7 | 1217 | 15 | 30564 |
| Dhrystone | 17717 | 262) | 7794 | 20 | 41235 |
| Whetstone | 15626 | 15 | 4422 | 14 | 33342 |
| Laufzeiten | |
| Ackermann (3,9) | 40,12 |
| QuickSort (50000) | 8,80 |
| kWhetstones | 1218 |
| Dhrystones 2.1 | 3225 |
1) Zeiten f�r `ilink� und `icollect�
2) Compiler zweimal gestartet (f�r dhry_1 und dhry_2)
Parsec Par-C
| Name | Source | Comp-Zeit | Object | Link-Zeit1) | Code |
| Leer | 17 | 3 | 64 | 3 | 1161 |
| Hello | 71 | 4 | 104 | 3 | 14723 |
| Ackermann | 709 | 5 | 612 | 4 | 20968 |
| Quicksort | 1144 | 6 | 878 | 4 | 21632 |
| Dhrystone | 17717 | 21 | 6358 | 4 | 26186 |
| Whetstone | 15626 | 20 | 11876 | 4 | 25097 |
| Laufzeiten | |
| Ackermann (3,9) | 107,0 |
| (83,5) 1) | |
| QuickSort (50000) | 15,1 |
| (12,1) 1) | |
| kWhetstones | 906 |
| Dhrystones 2.1 | 3030 |
1) mit Code und Data im internen RAMGr��enangaben in Byte, Zeiten in Sekunden; Dhry- und Whetstones in Durchl�ufen (h�here Werte = besseres Ergebnis)Host-Rechner: 25 MHz AT mit 80386, DOS 3.3, VGA 16 Bit, 4 MByte RAM
Transputer: TEK4/8 mit T800, 25 MHz, 1 MB RAM (120 ns)
[ + ] volle ANSI-C-Implementierung
[ + ] sehr gute Dokumentation
[ + ] unterst�tzt T2-Transputer
[ + ] zuverl�ssig
[ + ] viele Tools inklusive Debugger
[ + ] Server auch als Source
[ - ] langsam
[ - ] Make fehlt
[ - ] Bedienungskomfort
Parsec/ACE Par-C
[ + ] gutes Sprachkonzept
[ + ] flotter Linker
[ + ] geringer Platzbedarf (kleine Libraries)
[ + ] separater Assembler
[ + ] Server auch als Source + Library
[ - ] diverse Entwicklungstools inklusive Debugger fehlen
[ - ] nicht ANSI-C-kompatibel
[ - ] Bedienungskomfort
[ - ] keine T2-Unterst�tzung
[ - ] Dokumentation etwas un�bersichtlich