Wie schnell ist ein PowerMac? In unserem Leitartikel brütet Rick Holzgrafe über Rechnergeschwindigkeit und zeigt uns ein kleines Programm, das er seit 20 Jahren auf verschiedenen Rechnern laufen lässt. Lassen Sie sich überraschen, wie ein Power Mac G3 im Vergleich mit einer Cray Y-MP abschneidet! Ausserdem untersucht Adam diese Woche die neuen Header, die Sie am Anfang jeder Mail in den Listen TidBITS und TidBITS Talk sehen. In den Nachrichten veröffentlicht Apple Mac OS X Server und eine Public Beta von QuickTime für Java und kündigt an, mit Darwin auf den OpenSource-Zug aufzuspringen.
Autorisierte Übertragung der TidBITS#472/22-MAR-99.
Die Originalausgabe finden Sie unter: <http://www.tidbits.com/tb-issues/TidBITS-472.html>
Copyright 1999 TidBITS Electronic Publishing. All rights reserved.
Information: <info@tidbits.com> Comments: <editors@tidbits.com>
Copyright ab 7/98 der deutschen Version: Heike Kurtz Übersetzungsdienst.
Information: <http://www.heikekurtz.de> Comments: <mail@heikekurtz.de>
Themen:
<http://www.tidbits.com/tb-issues/TidBITS-472.html> <ftp://ftp.tidbits.com/pub/tidbits/issues/1999/TidBITS#472_22-Mar-99.etx>
Die Originalausgabe ist via FTP auf den meisten Info-Mac-Mirrors
verfügbar, so etwa:
<ftp://ftp.univie.ac.at/mac/info-mac/per/tb/tidbits-472.etx>
<ftp://sunsite.cnlab-switch.ch/mirror/info-mac/per/tb/tidbits-472.etx>
<ftp://ftp.rrzn.uni-hannover.de/pub/mirror/info-mac/per/tb/tidbits-472.etx>
Übersetzung: Sonja Krause-Harder <translation@skh.de>
**Apple kündigt Darwin als Open Source an** -- Vergangene Woche kündigte Apple an, den Quellcode der Basiskomponenten des Mac OS X Server über eine Open Source Initiative namens Darwin verfügbar machen zu wollen. Entwickler, die der Apple Public Source Lizenz zustimmen, können sich bei Apple registrieren lassen, und bekommen dann Zugang zum Quellcode. Der zur Verfügung gestellte Code umfasst Apples Erweiterungen des Mach 2.5 Microkernels im Mac OS X Server sowie einige Apple-eigene Technologien wie AppleTalk, das Dateisystem HFS Plus, und die neue verteilte Datenbank NetInfo. Apple kündigte an, es solle noch weitere Software als Open Source veröffentlicht werden, doch es ist kaum zu erwarten, dass der Quellcode von Apples Brot-und-Butter-Technologien (wie das aktülle MacOS, QuickTime, WebObjects oder der Applikationslayer von NeXT) als Open Source erhältlich sein wird. Die Quellen von Darwin sollen den Entwicklern Anfang April zur Verfügung stehen. Es bleibt abzuwarten, ob Darwin für Entwickler wirklich nützlich sein wird, oder ob Apple nur auf der grossen Open Source Welle mitschwimmen will. Zu diesem Thema finden Sie eine aktülle Diskussion auf TidBITS Talk. [GD]
<http://www.opensource.org/>
<http://www.apple.com/darwin/>
<http://www.publicsource.apple.com/apsl.html>
<http://db.tidbits.com/getbits.acgi?=tlkthrd=629>
**Mac OS Server wird ausgeliefert** -- Vergangene Woche lieferte Apple den Mac OS X Server aus, ein neues, UNIX-basiertes Betriebssystem für den Einsatz auf High-End-Servern. Bislang unter dem Codenamen Rhapsody bekannt, umfasst der Mac OS X Server den bekannten Webserver Apache, die WebObjects von Apple, die Möglichkeit, neuere Macintosh-Modelle über NetBoot zu starten, eine leistungsfähige Java Virtual Machine, Netzdienste wie DNS und das Apple File Protocol, webbasierte Administration und eine einheitliche, MacOS-ähnliche Oberfläche (siehe dazu auch "Neue iMacs, Neue G3 und MacOS X Server" in TidBITS #462). Im Mac OS X Server läuft ein BSD Unix 4.4 auf dem Mach 2.5 Microkernel (was in Kombination präemptives Multitasking und geschützte Speicherbereiche bedeutet) sowie von NeXT übernommene Applikationstechnologien. Mac OS X Server soll auch die Blü Box enthalten und somit fähig sein, Programme auszuführen, die für das MacOS geschrieben wurden. Nach allen Berichten soll die Blue Box die Möglichkeit bieten, Mac OS X Server auf Workstations einzusetzen sowie aktülle Serversoftware für das MacOS zu nutzen. Die Unterstützung der Entwickler für den Mac OS X Server wächst, einige Unternehmen haben schon Pläne veröffentlicht, für den Mac OS X Server zu entwickeln, und weitere werden folgen. Der durchaus wettbewerbsfähige Preis des Mac OS X Server liegt bei $499, die Anzahl der Clients ist nicht begrenzt. Apple hat darüber hinaus 400MHz G3-Server ab $4999 im Programm, auf denen Mac OS X Server vorinstalliert ist (laut Apple die schnellste Plattform für den Apache Server unter $5000). [GD]
<http://www.apple.com/macosx/server/>
<http://www.apache.org/>
<http://db.tidbits.com/getbits.acgi?tbart=05235>
**QuickTime im Koffeinrausch** -- Apple kündigte eine öffentliche Betaversion von QuickTime für Java an und weiteten damit den Einsatzbereich von QuickTime auf alle Programme aus, die in Java geschrieben wurden, sowohl auf MacOS als auch auf Windows. Im Moment werden sich nur Entwickler für QuickTime für Java interessieren, doch die Javaunterstützung ist ein wichtiger Schritt zur von Apple angestrebten Omnipräsenz von QuickTime. QuickTime für Java setzt eine Installation der MRJ 2.1 (oder, wenn Sie das Windows Java Runtime Environment verwenden, JRE 1.1.x oder 1.2) und QuickTime 3.0.2 voraus. Weitere Informationen finden Sie auf der Installationsseite für QuickTime für Java bei Apple. [ACE]
<http://www.apple.com/quicktime/qtjava/>
von Adam C. Engst <ace@tidbits.com>
Übersetzung: Sonja Krause-Harder <translation@skh.de>
Wenn ich Neulingen erkläre, wie Email funktioniert, nenne ich
die Header immer das "Kauderwelsch da oben": für uns Menschen
sind sie nicht allzu leicht verdaulich. Die Header sind Textzeilen,
die dem eigentlichen Inhalt einer jeden Internet-Email vorausgehen.
Sie beinhalten beschreibende Information über die Nachricht, nicht
die Nachricht selbst. Vermutlich sind Ihnen die Header vertraut,
die in erster Linie für menschliche Augen da sind: Date, From,
Subject und To, und vermutlich möchten Sie die weniger leicht
zu entziffernden Header wie Message-ID, Content-Type oder Received
gar nicht sehen, die zusammen einen undurchdringbaren Wust ergeben.
Diese wie eine Geheimwissenschaft anmutenden Header sollen von
Mailprogrammen verstanden werden, nicht von Menschen, und deshalb
werden die Header, die auf der Kauderwelsch-Skala weiter oben
angesiedelt sind, von vielen Mailprogrammen gnädig verborgen.
Vielleicht ist Ihnen jedoch aufgefallen, dass die Mails der Listen
TidBITS und TidBITS Talk seit Anfang 1999 neue, unübliche Header
enthalten. Die meisten dieser Header - die ich als "Listenheader"
zusammenfasse - sind entweder bereits gültige oder zukünftige
Internet-Standards. Die Listenheader sind für Menschen verständlich
und geben ein paar nützliche Informationen über eine Mailingliste,
doch sie können auch von Mailprogrammen interpretiert werden und
können den Teilnehmern von Mailinglisten helfen, ihre Listenabonnements
einfacher zu verwalten.
<http://www.ietf.org/rfc2369.txt>
<http://www.ietf.org/internet-drafts/drafts-chandhok-listid-03.txt>
**Kopf hoch**-- Da die Listenheader standardisiert sind, können Mailprogramme
jetzt anfangen, von ihnen Notiz zu nehmen. Die erste Reaktion
der Entwickler könnte sein, diese Header zu verbergen, da sie
in jeder Listennachricht einige Zeilen füllen. Eine bessere Lösung
jedoch wäre ein Menübefehl "Unsubscribe", der verfügbar ist, sobald
eine Nachricht geöffnet ist, die diese Listenheader enthält. Noch
nützlicher wäre eine Programmfunktion, mit der man alle Mailinglisten
verwalten könnte, die man abonniert hat - über die man sich z.B.
mit einem Klick aus einer, mehreren oder allen Listen austragen
und alle Listenmails automatisch filtern könnte. Sobald diese
Funktionen zur Verfügung stehen, könnte das Mailprogramm die Listenheader
auch wieder verbergen, da es die Funktionen der Header ja vollständig
übernommen hätte.
Bis die Mailprogramme diese Listenheader jedoch direkt unterstützen,
machen sie es auch normalen Menschen schon einfacher, ihre abonnierten
Mailinglisten zu verwalten.
**Headerliste** -- Wir wollen nun einen Blick auf die Listenheader werfen, die
wir in den TidBITS verwenden und erklären, warum auch die Administratoren
anderer Listen diese Header vielleicht verwenden möchten - oder
auch nicht. Die Reihenfolge der Header ist dabei willkürlich gewählt
und spielt keine Rolle - die Anordnung folgt der Zeilenlänge und
dient nur der übersichtlichen Darstellung.
> List-URL: <http://www.tidbits.com/> > List-Archive: <http://www.tidbits.com/search/>
> List-Subscribe: <mailto:tidbits-on@tidbits.com> > List-Unsubscribe:
<mailto:tidbits-off@tidbits.com> > List-Help: <http://www.tidbits.com/about/list.html>
> List-Owner: <mailto:editors@tidbits.com> (TidBITS Editors) >
List-Software: "ListSTAR v1.2 by StarNine Technologies, Inc."
> List-Id: "TidBITS Setext Distribution List" <setext.tidbits.tidbits.com>
> List-Post: <mailto:tidbits-talk@tidbits.com> (Discussions on
TidBITS Talk)
Der folgende Header erscheint ausserdem auf der Liste "TidBITS
Talk":
> List-Digest: <mailto:tidbits-talk-digest@tidbits.com>
*List-URL: Der Header "List-URL:" gehört nicht zum Internet-Standard.
Wir verwenden ihn, weil wir die Header einheitlich halten möchten,
und um sicherzustellen, dass unsere Leser die Homepage unserer
Website leicht finden können, wo sie dann detailliertere Informationen
über TidBITS und unsere Mailinglisten finden sollten.
* List-Archive: Der Header "List-Archive:" verweist auf unsere
Artikeldatenbank, in der man alle TidBITS-Artikel, die jemals
veröffentlicht wurden, nach Begriffen durchsuchen kann. Viele
Listen haben kein Archiv und werden diesen Header deshalb nicht
brauchen.
* List-Subscribe: Dies ist einer der wichtigsten Header, da er
darüber Auskunft gibt, wie man die TidBITS-Liste abonnieren kann.
"List-Subscribe:" mag unnötig erscheinen - immerhin sollte jeder,
der eine Mail mit diesem Header bekommt, die Liste bereits abonniert
haben. Doch "List-Subscribe:" kann hilfreich sein, wenn Nachrichten
von Mailinglisten weitergeleitet werden und der Empfänger auch
gerne auf diese Liste möchte, oder wenn man sich aus einer Liste
ausgetragen hat und nun sie doch wieder abonnieren möchte. Wenn
ein Emailprogramm diese Header erkennen und eine komfortable Listenverwaltung
zur Verfügung stellen sollte, wäre ein "Subscribe"-Menübefehl
sehr hilfreich. Nicht alle Listen werden mit Hilfe der einfachen
-on und -off-Adressen verwaltet, die wir verwenden, doch die mailto:-Zeilen
können durchaus zusätzliche Angaben enthalten, darunter auch Subjectzeilenbefehle:
<mailto:listadmin@example.com?subject=subscribe>. "List-Subscribe:"
könnte auch auf eine Webseite verweisen, auf der es ein Formular
zur Anmeldung sowie weitere Optionen und Informationen zur Liste
gibt.
* List-Unsubscribe: Wie schon "List-Subscribe:" ist auch "List-Unsubscribe:"
der perfekte Kandidat für die Aufnahme in ein wie auch immer geartetes
Hilfsprogramm. Wenn wir bedenken, wie viele Emails wir mit der
Fehlermeldung zurückbekommen, sie seien nicht zustellbar, nur
weil es jemand unter seiner Würde fand, herauszubekommen, wie
man die TidBITS wieder abbestellt (von den vielen "unsubscribe"-Mails
an offenbar willkürlich gewählte Adressen einmal ganz abgesehen),
wären wir überglücklich, wenn jeder, der die TidBITS nicht mehr
erhalten möchte, sich verlässlich aus der Liste austragen könnte,
ohne mit uns persönlich Kontakt aufnehmen zu müssen.
* List-Help: Im RFC (Request for Comments), der die Listenheader
beschreibt, wird der Header "List-Help:" als wichtigster Header
von allen bezeichnet, da er einen Hinweis enthalten kann, wo man
die ganzen Informationen findet, die über die anderen Header verteilt
sind.
* List-Owner: Der Header "List-Owner:" verweist auf eine menschliche
Kontaktperson für die Mailingliste. Auf TidBITS ist dies unsere
allgemeine Emailadresse <editors@tidbits.com>, doch es darf ruhig
persönlicher sein. Auf TidBITS Talk z.B. gebe ich mich selbst
als "List-Owner:" an.
* List-Software: Wie "List-URL:" gehört auch "List-Software:"
nicht zum Internet Standard. Hier kann man angeben, mit welcher
Software eine Liste betrieben wird. Obwohl das nicht unbedingt
notwendig ist, kann es doch manchmal nützlich sein, zu wissen,
welches Programm denn nun genau die Liste verwaltet. Durch der
Angabe "ListSTAR v1.2 by StarNine Technologies, Inc." können Sie
aus dem Header erkennen, dass die TidBITS von ListSTAR verschickt
werden, wohingegen die TidBITS Talk von LetterRip Pro verwaltet
wird - klar ersichtlich aus dem Header "List-Software: LetterRip
Pro 3.0.4 by Fog City Software, Inc." in jeder Mail jener Liste.
List-Id: Der Header "List-Id:" kommt nicht aus dem RFC, der die
anderen Listenheader beschreibt, sondern entstammt einem anderen
Entwurf, auf den wir oben auch verwiesen haben. Sein Zweck ist
es, für jede Mailingliste ein eindeutiges Kennzeichen zur Verfügung
zustellen. Hilfsprogramme, die die automatische Mailinglistenverwaltung
in Emailprogrammen zur Verfügung stellen sollen, benötigen solche
eindeutigen Merkmale, um Listen verlässlich identifizieren zu
können. Darüber hinaus braucht jeder, der alle Mails, die zu einer
bestimmten Liste gehören, ausfiltern will, irgendeine Möglichkeit,
um zu bestimmen, ob eine Mail von einer Liste kommt oder nicht.
Andere Header sind dazu normalerweise auch geeignet (z.B.: "Reply-To:listexy@beispiel.de"),
doch wir alle kennen die Probleme, die entstehen, wenn Mailinglisten
die Angaben in den Headern wechseln, weil sie ein anderes Programm
verwenden oder auf einen anderen Server umgezogen sind. Theoretisch
bliebe der Header "List-Id:" bei all diesen Änderungen immer gleich,
und auch nach der Umstellung würden alle Filter und automatisierten
Prozesse weiterhin funktionieren. Die Administratoren der Mailinglisten
geben ihren Listen diese Namen selbst, der Entwurf empfiehlt jedoch
ein einheitliches Format anhand der Domainnamen. So bezeichnet
<setext.tidbits.tidbits.com> die Setext-Distribution der Liste
"TidBITS" von der Domain "tidbits.com". Die TidBITS Talk verwendet
eine etwas kürzere List-Id: <tbtalk.tidbits.com> - schliesslich
muss hier nicht unterschieden werden zwischen Setext und anderen
möglichen Formaten.
*List-Post: Wir verwenden den Header "List-Post:" anders als die
meisten anderen Listen, da die TidBITS selbst keine Diskussionsliste
ist. Wir möchten die Diskussion auf die TidBITS Talk umleiten,
deshalb verwenden wir diese Adresse in der mailto: URL. Der in
Klammern gesetzte Kommentar (Diskussion auf TidBITS Talk) erklärt,
warum wir die Leute auf eine andere Liste schicken. Die TidBITS
Talk verwendet natürlich dieselbe mailto: URL, jedoch mit einem
anderen Kommentar (TidBITS Talk Moderator), um darauf hinzuweisen,
dass es sich dabei um eine moderierte Mailingliste handelt. Die
Tatsache, dass wir nun schon zwei Listen mit demselben "List-Post:"
Header haben, macht deutlich, wofür wir den Header "List-Id:"
brauchen. Wenn jemand den Header "List-Post:" als Kriterium für
einen Filter verwenden würde, würde dieser Filter die Mails von
beiden Listen erwischen.
**Wer sollte diese Listenheader verwenden?** -- Ich will ehrlich sein: einer der Gründe, warum wir die Listenheader
für die TidBITS und TidBITS Talk eingeführt habe ist der, dass
wir einige der Leute kennen, die im Prozess der Standardisierung
dieser Header mitarbeiten. Diese Menschen bekehrten uns dazu,
die Listenheader zu verwenden und beantworteten geduldig meine
Fragen, als ich versuchte, das günstigste Header-Set für die Listen
TidBITS und TidBITS Talk zusammenzustellen. Doch von unserer besonderen
Situation einmal abgesehen gibt es vier Gruppen von Menschen,
die auf die Listenheader achten sollten: die Betreiber von Mailinglisten,
die Autoren von Emailprogrammen, die Entwickler von Programmen
zur Verwaltung von Mailinglisten, und Einzelpersonen, die Mailinglisten
abonnieren.
Ich möchte jeden, der eine Mailingliste betreibt, dazu ermutigen,
die entsprechenden Listenheader zu verwenden. Sie sind nicht schwer
zu erstellen, und in den meisten Mailinglistenprogrammen kann
man eigene Header definieren. Meine Hoffnung dabei ist, dass ich
die Zeit, die ich in die Erstellung dieser Header investiere,
dadurch einspare, dass ich weniger Zeit brauche, um den Abonnenten
der TidBITS und TidBITS Talk bei der Verwaltung ihrer Listenabos
zu helfen.
Wer Emailprogramme entwickelt, sollte anfangen, sich darüber Gedanken
zu machen, wie man die Listenheader intern am besten verarbeiten
kann. Ich habe eine frühe Version eines Hilfsprogrammes gesehen,
das eine Oberfläche zur Verwaltung von Listenabonnements zur Verfügung
stellt und das auf den Angaben in diesen Headern basiert, und
das ist eine Wirklich Feine Sache. Sehen Sie es so: solange noch
nicht alle Emailprogramme die Listenheader unterstützen, kann
jedes Programm mit einer solchen Funktion diese in die Liste der
besonderen Funktionen aufnehmen und damit werben!
Entwickler von Programmen zum Betreiben von Mailinglisten müssen
gar nicht unbedingt so viel tun, da zusätzliche Header von praktisch
allen Mailinglistenservern unterstützt werden. Dennoch sollten
diese Programme die Erstellung der Listenheader vereinfachen und
so zu ihrer Verwendung anregen.
Für den einzelnen Anwender empfehle ich lediglich: sehen Sie sich
die Header einmal an und merken Sie sich, dass sie existieren.
Wenn Sie irgendwann nach dem Inhalt einer Mail suchen, die Sie
bereits gelöscht haben, suchen Sie nach dem Header "List-Archive:"
- und wenn Sie sich aus einer Mailingliste austragen möchten,
die Sie abonniert haben, versuchen Sie's einfach mit der URL im
Header "List-Unsubscribe:".
Wie wir alle über die Jahre gemerkt haben, haben viele Menschen
Probleme, wenn sie mit den Servern von Mailinglisten kommunizieren
wollen oder müssen. Alles, was diesen Prozess vereinfacht, hilft
letztendlich der gesamten Internet-Gemeinde.
von Rick Holzgrafe <rick@kagi.com>
Übersetzung: Sonja Krause-Harder <translation@skh.de>
Der Cannonball Express war der legendäre Zug, der so schnell war,
dass man drei Leute brauchte, um zu rufen: "Er kommt!" - "Er ist
da!" - "Er ist weg!" Computer sind auch schnell, doch im Gegensatz
zu Zügen sind sie das nicht automatisch und immer gleich. Was
macht einen Computer schnell, und welchen Effekt hat das Softwaredesign
auf die Geschwindigkeit eines Rechners? Um wieviel sind die Rechner
von heute schneller als die von gestern? Erst kürzlich habe ich
mich mit einigen dieser Fragen wieder beschäftigt, ausgehend von
einer Reise zurück in mein Gedächtnis...
**Zurück in der Steinzeit** -- Vor zwanzig Jahren brachte ich mir selbst das Programmieren
bei. Ich hatte, abends und am Wochenende, einen DEC PDP-11/60
Minicomputer zur Verfügung. Das Biest war grösser als eine Waschmaschine,
und während der Arbeitszeit teilte ich ihn mir mit zwei Dutzend
weiterer Techniker und Ingenieure. In einer Zeitung fand ich ein
Buchstabenpuzzle, und ein Programm für den PDP zu schreiben, das
dieses Puzzle löste, schien mir spassig. Das Puzzle ging so:
Gegeben sei ein Satz und ein Blatt kariertes Papier. Der Satz
soll nach folgenden Regeln auf das Papier geschrieben werden:
1. In jedes Karofeld kommt ein Buchstabe, so wie man ein Kreuzworträtsel
ausfüllt. Gross- und Kleinschreibung sind egal, und verwendet
werden nur die 26 Buchstaben des Alphabets. Der Satz "N. 1st Street"
entspricht also der Zeichenfolge "NSTSTREET".
2. Der erste Buchstaben des Satzes kann in irgendein beliebiges
Feld geschrieben werden.
3. Wenn ein Buchstabe geschrieben wurde, muss der darauf folgende
in ein daran angrenzendes Feld geschrieben werden. "Angrenzend"
ist in diesem Fall jedes der acht benachbarten Felder - darüber,
darunter, rechts, links und diagonal. Wenn ein angrenzendes Feld
bereits den benötigten Buchstaben enthält, darf dieses Feld erneut
verwendet werden. Ist das nicht der Fall, muss der Buchstabe in
ein leeres Feld geschrieben werden. Ein Feld darf nicht zweimal
nacheinander verwendet werden - also kein "Auf der Stelle-Hüpfen"
bei Doppelbuchstaben.
Das Ziel ist es, den Satz innerhalb eines möglichst kleinen Rechteckes
auf das Papier zu schreiben. (Ein kleiner, aber feiner Unterschied:
Es geht nicht um die geringstmögliche Anzahl von Feldern!) Um
eine Lösung zu bewerten, wird ein möglichst kleines Rechteck um
die beschriebenen Felder gezogen und seine Grösse berechnet. Dieses
Rechteck kann auch leere Felder enthalten, diese werden mitgezählt.
Alles klar? Zungenbrecher machen am meisten Spass, weil sie eine
Menge Möglichkeiten bieten, ganze Buchstabenwürmer wieder und
wieder zu verwenden. Die 37 Buchstaben im Satz "Peter Piper picked
a peck of pickled peppers" können in ein Rechteck geqütscht werden,
das nur 3 auf 5 Felder gross ist: (Bitte verwenden Sie eine nichtproportionale
Schrift wie z.B. Courier, dann wird die Darstellung klarer)
> OFIPT > KCPER > LEDAS
Damals wusste ich, dass Computer "schnell" sind, doch ich hatte
keine Ahnung, wie schnell genau. Die Antwort war bald "nicht allzusehr".
Ich schrieb ein Programm, um Puzzles der oben beschriebenen Art
zu lösen und gab ihm, von dem Zungenbrecher inspiriert, den Namen
"Piper". Ich startete Piper an einem Freitag abend mit einem Satz
mittlerer Länge, und als ich am Montag zurückkam, lief es noch
immer. Es hatte viele mittelmässige Lösungen gefunden, doch es
war noch nicht fertig. Viel zu langsam - ich fand mit Papier und
Bleistift in etwa einer halben Stunde eine bessere Lösung.
Warum dauerte das so lang? Piper arbeitete nach dem "Brute Force"
Prinzip - mit roher Gewalt. Es spielte alle möglichen Lösungen
für das Puzzle durch, hübsch eine nach der anderen. Das Problem
dabei: es gibt zu viele mögliche Lösungen. Wie viele es genau
sind, hängt vom verwendeten Satz ab, doch für jeden nichttrivialen
Satz steigt ihre Anzahl in astronomische Höhen. Zum ersten Mal
wurde mir klar, dass "schnell" nicht immer "schnell genug" bedeutet.
Das mag heute selbstverständlich sein, wir alle arbeiten mit Computern,
und wir alle hassen es, auf sie warten zu müssen. Doch damals,
im Jahr 1979, war dieser PDP-11 erst der zweite Computer, den
ich bis dahin gesehen hatte!
**Schnell oder Schnell?** -- Ich wusste, dass ich das Programm schneller machen musste.
Es gibt zwei Möglichkeiten, ein Programm zu beschleunigen. Plan
A besteht darin, eine bessere Lösung für das Problem zu finden,
doch nach zwanzig Jahren ist mir immer noch kein besserer Lösungsansatz
für dieses Puzzle eingefallen als der, den ich damals entwickelte.
Übrig bleibt Plan B, die klassische Lösung zur Effizienzoptimierung:
das Vermeiden unnötiger Arbeitsschritte. Ein Beispiel: Piper rechnete
jede mögliche Lösung aus und berechnete die benötigte Fläche.
Jede mögliche Lösung wurde Buchstabe für Buchstabe berechnet.
Also veränderte ich Piper dahingehend, dass es nach jedem hinzugefügten
Buchstaben diese Fläche neu berechnete, und nicht erst, wenn eine
Lösung fertig war. Wenn das Hinzufügen eines einzelnen Buchstaben
die benötigte Fläche bereits grösser machte als die der kleinsten
bis dahin gefundenen Lösung, konnte sich Piper den Rest der gerade
entwickelten Lösung sparen (und ebenso alle anderen Lösungen,
die genauso anfingen) und gleich zur nächsten übergehen. Dies
sparte eine Menge Rechenarbeit und machte das Programm erheblich
schneller. Eine erhebliche Verbesserung war auch die Entwicklung
von Algorithmen, mit denen man die Vergrösserung der benötigten
Fläche während der Berechnung einer Lösung ableiten konnte, dies
war schneller, als die Fläche nach jedem hinzugefügten Buchstaben
von Grund auf neu zu berechnen. Auch fand ich schnell einen Weg,
die Mindestgrösse für die beste Lösung zu berechnen. Ich konnte
nicht vorhersagen, ob die beste Lösung wirklich so klein sein
würde, doch ich wusste immerhin, dass sie auf keinen Fall kleiner
werden konnte. Sollte Piper also Glück haben und eine Lösung finden,
deren benötigte Fläche so klein war wie das vorher berechnete
Minimum, konnte es sofort abbrechen. Andernfalls hätte es auch
nach der Berechnung der optimalen Lösung noch weiter rechnen müssen,
vergeblich auf der Suche nach einer noch besseren.
Piper war schliesslich schlau genug, den ursprünglichen Satz in
einigermassen kurzer Zeit zu berechnen. Doch den Heilige Gral
bekam ich immer noch nicht zu fassen: Ich wollte eine Lösung für
diesen Satz: "How much wood would a woodchuck chuck if a woodchuck
could chuck wood?" Jener PDP (und vielleicht auch meine Programmierkunst)
war dieser Aufgabe nicht gewachsen. Mir fiel nichts mehr ein,
womit man Piper noch beschleunigen könnte, und die Programmläufe
dauerten immer noch länger als ein Wochenende. Doch wenn ich auch
Piper nicht weiter verbessern konnte, blieb mir doch die Hoffnung
auf einen schnelleren Rechner.
**Schweres Geschütz** -- Die meisten Leute denken, wenn sie über die Geschwindigkeit
von Rechnern nachdenken, an Prozessorleistung und -takt, doch
es sind mehrere Faktoren, die die Gesamtleistung eines Systems
beeinflussen. Mit virtüllem Speicher kann man zwar grössere Datenmengen
bearbeiten oder mehrere Probleme gleichzeitig lösen, doch virtüller
Speicher ist langsam, deshalb hilft die Erweiterung des physikalisch
vorhandenen RAM schon viel, da dann weniger häufig auf virtüllen
Speicher zurückgegriffen werden muss. Schnellere Festplatten und
ein schnellerer I/O-Bus beschleunigen das Laden und Speichern
von Daten. RAM-Disketten und Festplatten-Cache ersetzen langsame
Plattenoperationen durch blitzschnelle RAM-Zugriffe. Spezielle,
geschwindigkeitsoptimierte Cachebausteine für Programmanweisungen
und Daten bieten extreme Verbesserungen für bestimmte Anwendungen.
Gut geschriebene Betriebsysteme und Codebibliotheken können schlecht
geschriebene weit hinter sich lassen.
Doch letztlich bedeutet dies alles für Piper nicht viel. Piper
hat immer nur mit einer kleinen Menge von Daten gearbeitet, es
greift, sobald es einmal läuft, nicht mehr auf die Festplatte
zu und hat überhaupt wenig mit Ein- und Ausgaben zu tun. Da es
nur wenig Code umfasst und die verarbeiteten Daten sehr klein
sind, profitiert es durchaus von Daten- und Anweisungscache, doch
eigentlich braucht es "schnellere Hamster" - einen schnelleren
Prozessor, um das Räderwerk zu beschleunigen.
Die Jahre vergingen, und ich liess verschiedene Versionen von
Piper auf meinen ersten Macs laufen - doch in der Mitte der 1980er
Jahre arbeitete ich für Apple Computer, Inc. und hatte Zugang
zum damaligen Traum jedes Programmierers: dem 15-Mio-Dollar Cray
Y-MP Supercomputer, im Besitz von Apple, einer von gerade mal
zwei Dutzend und wohl der schnellste Computer, der damals existierte.
Ich ging davon aus, dass die Cray mit Piper kurzen Prozess machen
würde, doch sie war für dieses Problem nicht allzu gut geeignet.
Die Cray raste wie der legendäre Cannonball Express durch parallele
Fliesskomma-Matrix-Berechnungen, doch bei Piper handelte es sich
um ein extrem lineares, nichtmathematisches Problem. Piper verwendete
nur einen der vier Prozessoren der Cray, und verwendete keine
der besonderen Rechenoperationen, für welche sie optimiert worden
war. Piper war kein fairer Test für die Rechenleistung der Cray,
doch dies war immer noch die schnellste Maschine, die ich je benutzt
hatte. Der Cray gelang, woran alle anderen Computer (jener PDP,
mein Mac Plus, mein Mac II) gescheitert waren. Sie löste "woodchuck"
in weniger als einem Tag und beendete das Programm nach etwa 20
Stunden. Ich war von Ehrfurcht erfüllt - 20 Stunden? Ich hatte
nicht gewusst, dass "woodchuck" ein _so_ grosses Problem war!
**Junge Hüpfer** -- Ich legte Piper für viele Jahre zur Seite. Erst kürzlich begann
ich darüber nachzudenken, wie wohl die modernen Desktop-Maschinen
im Vergleich mit diesen alten Minicomputern und Mainframes abschneiden
würden. Ich schrieb Piper aus dem Gedächtnis erneut und liess
es auf meinem neuen, eisblauen 400 MHz Power Macintosh G3 laufen
- mit "woodchuck". Die Ergebnisse finden Sie weiter unten. Zunächst
wiederholt Piper den Ausgangssatz und gibt dann gefundene Lösungen
sowie die dazu benötigte Zeit aus, sobald es sie findet. Die Zeiten
sind in Sekunden seit dem Programmstart angegeben, die letzte
Zeitangabe steht für die gesamte Laufzeit des Programms. (Leider
ist die beste Lösung für "woodchuck" grösser als das von Piper
berechnete Minimum, deshalb läuft das Programm noch eine Weile
weiter, obwohl die Lösung bereits gefunden wurde.)
Dies sind die Ergebnisse. Ich habe einige Zwischenlösungen der
Kürze halber weggelassen, doch es ist klar erkennbar, dass Piper
immer kleinere Lösungen findet. Am Ende sind die 57 Buchstaben
von "woodchuck" in ein 4 auf 4 Felder grosses Rechteck gepackt.
Beachten Sie die Zeit, die Piper insgesamt lief und die Zeit,
die es brauchte, um die beste Lösung zu finden.
> How much wood would a woodchuck chuck if a woodchuck could chuck
wood? >
>0 seconds:
>ULD ADLU
>HDOAIUCOHWUHOD
>UCOWFKHDOMCWOW
>K WO
>1 seconds:
>DLIFADLU
>UCKOHWUHOD
>OHDWOMCWOW
>2 seconds:
>ULCHC
>HWUHODKUK
>OMCWOWAFI
>7 seconds:
>HWUHOW
>OMCWOD
>IKAUCW
>FLDHK
>9 seconds:
>HWUH
>OMCW
>LUOK
>HDOI
>CWAF
>65 seconds:
>HWM
>OUC
>IKH
>FWC
>ADO
>LUO
>67 seconds:
>HWMU
>OOCH
>UDWK
>LAFI
>Total run time: 107 seconds
Sie sehen selbst: kaum mehr als eine Minute, um die beste Lösung
zu finden, weniger als zwei Minuten gesamte Programmlaufzeit.
Zwei Minuten! Soviel also zu den schweren Geschützen der 1980er
Jahre... Mein neuer G3 Mac war mit "woodchuck" um den Faktor 600
schneller (und dabei um den Faktor 5000 billiger) als diese 15-Millionen-Dollar-Cray.
(Einen realistischeren Vergleich finden Sie in einer Beschreibung
des Project Appleseed der University of California, Los Angeles.)
<http://www.apple.com/education/hed/aua0101/appleseed/>
Wenn Sie ausprobieren möchten, wie schnell Piper auf Ihrem Mac läuft - das Programm ist frei verfügbar; der Download beträgt etwa 40K.
<ftp://ftp.tidbits.com/pub/tidbits/misc/piper.hqx>
*Die Zukunft** -- Wie geht es weiter? 400 MHz klingen schon etwas müde. Das
ist das Beste, was Apple im Moment zu bieten hat, doch ich habe
schon 550 MHz im Angebot von Drittherstellern von Beschleunigerkarten
und Übertaktungslösungen gesehen. Man sagt voraus, dass in naher
Zukunft 1 GHz-Chips (1000 MHz) herauskommen werden. Die Bustechnologie
wird verbessert, moderne Caches können immer mehr Daten auf weniger
Raum speichern und wandern auf den Prozessor selbst, um die Geschwindigkeit
weiter zu erhöhen. (Klein ist schnell. Wussten Sie, dass die Lichtgeschwindigkeit
einen erstzunehmenden begrenzenden Faktor für modernes Computerdesign
darstellt? Je näher die Komponenten beieinander liegen, desto
schneller können sie sich gegenseitig Signale übertragen.)
Und nach und nach erscheinen Multiprozessorsysteme wie die alte
Cray auf der Bildfläche - für den Desktop. Dabei rotten sich mehrere
Prozessoren für die Lösung eines Problems zusammen, indem verschiedene
Prozessoren auf verschiedene Teile des Problems angesetzt werden.
Obwohl ich die zusätzlichen Prozessoren der Cray damals nicht
ausgenutzt habe, habe ich letztens ein wenig darüber nachgedacht.
Piper muss nicht vollständig linear sein. Ich bin sicher, dass
ich Piper auf einem System mit acht Prozessoren in einem Achtel
der Zeit ablaufen lassen kann, die es auf einem einzigen Prozessor
benötigt.
Sind Sie bereit?
Da kommt er -
- da ist er -
- und ab geht er!
Übertragung dieser Ausgabe:
Sonja Krause-Harder <translation@skh.de>
Redaktion: Hartmut Greiser Home: www.linarte.com
Copyright and address info
TidBITS Home Page
Vorhergehende Ausgabe
Nächste Ausgabe
Frühere Ausgaben der TidBITS können unter folgendem Web-URL durchsucht
werden:
<http://www.tidbits.com/search/>