Home Computer Software Site Map counter

Warum wird Software schneller langsamer als Computer schneller werden?

Von Niklaus Wirth, der Schöpfer der Programmiersprachen Pascal, Modula und Oberon stammt das nach ihm benannte Wirthsche Gesetz: „Die Software wird schneller langsamer, als die Hardware schneller wird.“. Das ist nicht neu. Er fasste dabei zwei Beobachtungen zusammen die schon vorher gemacht wurden:

“Software expands to fill the available memory.” (Cyril Northcote Parkinson)

“Software is getting slower more rapidly than hardware becomes faster.” (Martin Reiser)

Er drückt damit aus, dass viele Benutzer das Gefühl haben, ihr Computer wäre langsamer als ein älteres Modell, obwohl er absolut gesehen schneller ist.

Nun ist unbestritten, dass Computer durch die fortschreitende Miniaturisierung und höhere Taktfrequenzen immer schneller werden. Der erste Rechner, den der Autor hatte, war ein Ti 99/4A, ein Rechner mit einem relativ langsamen 16-Bit-Prozessor (nicht schneller als ein damaliger 8 Bit Prozessor) und 3 MHz Takt. In der Programmiersprache BASIC schaffte er rund 100 Rechnungen pro Sekunde. Mein aktueller Rechner vom Baujahr 2009 und schon damals im Low-Cost Segment angesiedelt, schafft nach einem Benchmark 800 Millionen Fließkommarechnungen pro Sekunde. Er ist also rein rechnerisch 8 Millionen mal schneller. Nur scheint dieser Geschwindigkeitsgewinn nicht anzukommen.

Besonders auffällig ist dies, wenn man mehrere Computer mit demselben System hat, nur unterschiedlichen Versionen. Als Beispiel kann hier ein Windows XP System dienen. Windows XP erschien Ende 2001 und lief flüssig bei 256 Megabyte RAM und einem 500-MHz-Prozessor. Da der Nachfolger Windows Vista zu einem Flop geriet, war Windows XP ein längeres Leben vergönnt und 2010 wurden immer noch viele Computer mit Windows XP ausgeliefert. Mitte 2013 lag er Marktanteil (bzeogen auf die Installationen) immer noch bei 38%. Rein theoretisch waren Rechner im Jahr 2010 aber um ein vielfaches schneller als ein Computer aus dem Jahre 2001. Wer allerdings die offiziellen Bug-Fixes und Services Packs einspielte und andere Software aktualisierte wie Browser oder Office, bemerkte, dass er mit der 2001 noch völlig ausreichenden Konfiguration ein sehr zähes und langsames System hatte. Am Schluss war eine lauffähige Windows XP Konfiguration eine mit 1 GByte RAM und einem 2-GHz-Prozessor. Dasselbe System hatte durch Updates also um den Faktor 4 an Geschwindigkeit eingebüßt und auch viermal mehr Speicher benötigt. Mit den 2001 ausreichenden 256 MByte Speicher lief Windows XP, wenn alle Service Packs installiert wurden, schließlich gar nicht mehr.

Andere Beispiele, die für das Phänomen angeführt werden ist, das aktuelle PC‘s länger zum Booten brauchen als Rechner aus den frühen Achtzigern oder das es heute „normal“ ist das eine Anwendung per Sanduhr signalisiert, dass sie keine Eingaben entgegennimmt – vor zwanzig Jahren hätte man bei diesem Verhalten noch vermutet, dass das Programm abgestürzt ist und den Rechner neu gestartet.

Warum ist dem so?

Nun es gibt viele Ursachen. Eine Wesentliche ist, das in vielen Bereichen Benutzerfreundlichkeit mit erheblich höheren Anforderungen hinsichtlich Speicherbedarf und Geschwindigkeit einher geht. Nehmen wir zwei Beispiele. Das eine ist die Ausgabe von Text, z.B. durch eine Textverarbeitung.

Bei originalen IBM-PC (erschienen 1981) geschah dies durch eine Textgrafikkarte. Diese hatte einen Speicherbereich, der den 80 Spalten x 25 Zeilen des Monitors entsprach. Schrieb man in die erste Speicherzelle den Wert 65, das ist der Code des Buchstaben „A“, so erschien oben links auf dem Monitor das „A“. Die Darstellung selbst führte die Grafikkarte durch, die nachschaute, welches Pixelmuster sie für jeden der 256 Codes ausgeben musste, und die auch die Erzeugung des Videosignals durchführte.

Die Verbesserung war eine Grafikkarte, damit war es schon unter DOS möglich, das Aussehen der Buchstaben nachzuahmen, auch wenn das noch nur den Schriftschnitt (fett, kursiv, unterstrichen) imitierte, nicht aber das Aussehen der Schrift. Anstatt nun einen Wert in den Speicher zu schreiben, musste die Software die Bits bestimmen, die für die jeweilige Schrift notwendig waren, sie verändern (Bei Fettschrift z.B. jedes auf „1“ gesetzte Pixel rechts noch mal schreiben) und dann die 8x8 Matrix der Buchstaben in den Grafikspeicher schreiben, also 64-mal mehr Daten bewegen. Auf diesem Mechanismus beruhte auch die Darstellung der Systemschriftarten mit fester Größe in den frühen Windows Versionen.

Mit Windows 3.1 kamen TrueType Schriftarten hinzu. Sie waren Vektorschriftarten, das heißt es wurde nicht das Muster gespeichert, sondern wie man, wenn man die Zeichen auf Papier malen würde, den Stift bewegen muss. Für das kleine „l“ könnte eine sehr einfache Darstellung so aussehen:

Da nur die Proportionen angegeben werden, kann man diese Schriftarten beliebig vergrößern oder verkleinern. Das war bei den bisherigen Schriftarten nicht möglich, da wurde ein Pixelmuster in einer bestimmten Größe gespeichert, das wenn man es vergrößerte nicht feiner wurde, sondern „pixelig“ aussah. Abe nun muss der Prozessor die ganzen Pixelmuster berechnen, was erheblich länger als das Auslesen der Bitmaps dauert.

Gerade die grafischen Benutzeroberflächen verbrauchen enorm viel Rechenleistung. Als sie eingeführt wurden, war es schon problematisch sie mit der verfügbaren Rechenleistung überhaupt darzustellen. Als man sie im XEROX PARC erfunden hatte, entwickelte man einen Rechner mit einer grafischen Benutzeroberfläche und Mausbedienung. Doch da man alleine einen Minicomputer für die Ausgabe der Grafik brauchte, war der Xerox Alto nicht erfolgreich. Er war zu teuer in der Herstellung. Dasselbe Problem hatte Apple mit ihrem ersten grafischen Rechner, der LISA. Er setzte den schnellsten damals verfügbaren Prozessor den Motorola 68000 ein, war aber damit auch fünfmal teurer als ein normaler PC. Erst als man das Gerät radikal verschlankte und den Macintosh erschuf, gelang es geschäftlich erfolgreich zu sein.

Dabei waren diese Oberflächen, wie auch die ersten Windows Versionen primitiv im Vergleich zu heute. Es gab einfarbige Flächen, keine Farbverläufe, keine farblich abgestimmten Kanten oder gar Reflexe. Beim Macintosh war zudem alles nur Schwarz/Weiss. Von der Animation von Fenstern beim Taksswitchen mal ganz zu schweigen. Wie viel Rechenleistung alleine die grafische Oberfläche kostet, zeigte sich auch, als Microsoft Windows 8 für Smartphone, Tablets und PC herausbrachte und wegen der langsameren Hardware der ersten Gerätegruppe wieder im Design einen Schritt zurückging, um weniger Prozessorlast zu erzeugen, Dabei ist ein Smartphone mit leistungsfähiger Hardware ausgestattet als vor zehn Jahren ein PC, der flott mit Windows XP lief.

Auch bei der Texteingabe kann man den Fortschritt erkennen. Früher wurde der Text nur dargestellt, Fehler inklusive. Mitte der achtziger Jahre gab es die Offline Rechtschreibkorrektur als eigenes Programm. Das bedeutete ein Menüpunkt machte eine Rechtschreibkorrektur, während der man am Text nicht weiter arbeiten konnte. Doch dieses verglich nur jedes Wort mit einer Wortliste. Schon die im Deutschen so üblichen zusammengesetzten Worte wie „Baumschule“ zusammengesetzt aus „Baum“ und „Schule“, bereiteten Probleme, ebenso wie Ableitungen eines Basisbegriffes wie von „bescheiden“ die abgeleiteten Worte „bescheidener“, „bescheidenes“.

Mit mehr Computerleistung wurde aus dem Wort-Nachschlagen eine lexikalische Analyse. Damit waren obige Probleme zu lösen. Man versuchte also Basisbegriffe zu identifizieren und durch Regeln festzustellen, ob ein abgeleitetes Wort korrekt ist oder es ein Schreibfehler ist (wie z.B. „bescheidenet“). Mit noch mehr Leistung geht dies während des Schreibens, anstatt ein eigenes Programm zu starten. wird der Begriff gleich korrigiert (Kleinschreibung am Satzanfang) oder als fehlerhaft markiert. Noch mehr Leistung erfordert die Grammatikkorrektur, da dann auch der Text verstanden werden muss.

Ähnliches kann man bei der Prüfung von Eingabedaten erkennen, z.B. einer Adresse. Anstatt sie einfach zu akzeptieren, kann man in einem ersten Schritt die Gültigkeit von Angaben prüfen die offensichtlich sind, z.B. ob Postzahlen fünfstellig sind oder Hausnummern aus den Zeichen 0 bis 9,- und / bestehen. Ein weiterer Schritt wäre der Abgleich der Postleitzahl mit einer Datenbank aller Postleitzahlen, wofür man dann schon zusätzlich ein Datenbanksystem installieren muss, was die Software deutlich größer macht. (Bei aktuellen Datenbanken dürfte diese sogar erheblich größer als die Adressverwaltung selbst sein). Als bisher letzten Schritt kann man im Internet bei den Adressdatenbanken von Dienstleistern und Gemeinden die Adresse auf Existenz überprüfen. Dann muss man noch die gesamten Komponenten um ins Internet zu gehen verfügbar haben, dazu noch ein System um die Abfragen im richtigen Format abzusetzen und zu interpretieren. Verglichen mit diesem Softwareumfang war die komplette Adressverwaltungssoftware mit der einfachen Prüfung wohl kleiner, als nun nur noch das Modul, das die Adresse überprüft.

Die Geschwindigkeit korrespondiert auch mit dem Speicherplatzverbrauch, sowohl was den belegten Platz auf dem Massenspeicher angeht, wie auch den genutzten Arbeitsspeicher. Windows belegte einmal wenige Megabyte auf der Platte und kam mit 640 KByte Arbeitsspeicher aus. Diese Zahl kann man für die aktuelle Version 8 ohne Problem mit dem Faktor 5000 multiplizieren. Routinen die im Arbeitsspeicher liegen (es werden nur die Routinen im Speicher gelassen, die man braucht, ansonsten der Bereich freigegeben) werden auch aufgerufen und je mehr Routinen aufgerufen werden, um so langsamer ist der Rechner in der Regel, da jede Routine Prozessorlast erzeugt.

Die Programmierung als Ursache

Ein zweiter Punkt der Rechner verlangsamt, ist, wie programmiert wird. Bis in die achtziger Jahre war es üblich, sowohl Betriebssystem wie Anwendungsprogramme in Assembler zu erstellen, das waren Abkürzungen für die Befehle des Prozessors. So konnte man dessen Fähigkeiten optimal ausnutzen. Danach setzte es sich durch, Programme in einer Hochsprache zu schreiben und durch einen Compiler diese in die Maschinensprache zu übersetzen. Das war bequemer, denn die Hochsprachen haben eine Syntax, die viel näher an der menschlichen ist. Sie sind auch leistungsfähiger. Ein Befehl kann zahlreiche Maschinenbefehle oder ganze Routinen ersetzen. Dadurch können Programme schneller entwickelt werden.

Allerdings ist der Compiler nie so effektiv wie ein Mensch. So ergab eine Untersuchung, das Compiler im Allgemeinen nur 20% der Befehle eines Prozessors nutzen und einen Bogen um Spezialbefehle machen, die nur in bestimmten Situationen Sinn machen. Weiterhin bindet der Compiler komplette Module mit vorgefertigten Routinen ein, wenn sie benötigt werden und nicht nur den Teil, der für die Fragestellung benötigt wird. So könnte eine Ausgabe eines Textes auf dem Bildschirm z.B. eine Routine einbinden die eine Textzeile ausgeben kann, aber auch eine Zahl (sie muss erst von der internen Darstellung in Text umgewandelt werden), und die in der Textzeile nach Platzhaltern für die Zahlenausgabe sucht, obwohl diese Funktionen zur reinen Textausgabe gar nicht benötigt werden. Auch dadurch wird Software langsamer und umfangreicher.

Das typische Erstlingsprogramm in jeder Programmiersprache, die Ausgabe des Textes „Hello World“ auf den Bildschirm belegt in Maschinensprache z.B. etwa 100 Bytes, in Pascal bei einer Textoberfläche sind es schon 8 KBytes und bei einer grafischen Oberfläche, je nachdem wie schön gezeichnet diese ist zwischen 200 und 1500 KBytes. (200 bei Windows 3.1, 1500 bei Windows 7).

Immerhin übersetzen diese klassischen Programmiersprachen wie Pascal oder C noch den Code in die Maschinensprache, einen Vorgang, den man "Compilieren" nennt. Heute verbreiteter sind interpretierte Programmiersprachen, wie Java, C#, Ruby oder Phyton. Sie übersetzen erst den Quellcode, wenn er ausgeführt wird, manche erzeugen auch einen Zwischencode, der bei der Ausführung interpretiert wird, daher nennt man sie interpretierte Sprachen. Das ist natürlich langsamer, hat aber einige Vorteile. So ist es einfacher das Programm auf Fehler zu untersuchen, es läuft nicht nur auf dem Rechnertyp und dem Betriebssystem, mit dem es erstellt wurde und es sind Dinge einfach möglich die mit compilierten Programmen sehr umständlich sind, z.B. eine Formel in Textform einzulesen und die Werte als Grafik auszugeben. Das geht, wenn die Formel die Syntax der Programmiersprache hat und dann wird, diese Zeile einfach wie jede andere ausgeführt.

Als Preis für diesen Komfort kommt zu der Ausführung der Software auch noch die Übersetzung in den Maschinencode als zusätzliche Aufgabe hinzu, was die Ausführung verlangsamt.

Weitere Geschwindigkeit geht verloren wenn, wie heute üblich, Software modular erstellt wird. Das ist nötig, weil sie zu groß wird, schon bei Programmen die eine Person erstellt kann dies so sein, spätestens aber wenn mehrere Programmierer oder im Falle von großer Software, wie Betriebssystemen, Hunderte von Programmierern an einem Programm arbeiten. Damit man sich koordinieren kann, zerlegt man die Aufgabe in viele kleine Unteraufgaben und einigt sich über die Schnittstelle, also was übergeben wird und was als Ergebnis ermittelt und wie es zurückgegeben wird. Jeder Aufruf einer solchen Unterroutine kostet Zeit, dazu kommt, dass diese in der Regel auch alle Parameter auf korrekte Werte überprüft, auch wenn diese Arbeit schon von der aufgerufenen Routine schon mal erledigt wurde.

Es gibt sehr viele Beispiele, wo die ersten Versionen einer Software, die von einer Person alleine programmiert wurde, recht schnell waren. Als der Programmierer erfolgreich war und eine Firma gründete und mehr und mehr Leute an den nächsten Versionen arbeiteten, diese sukzessive langsamer wurden. Ein populäres Beispiel ist Lotos 1-2-3 dass durch seine Geschwindigkeit in der ersten Version, die ein Programmierer alleine erstellte, marktbeherrschend wurde und in späteren Versionen sukzessive träger wurde und die neuste Hardware erforderte.

Auch Altlasten, vor allem Programme, die über Jahre bis Jahrzehnte weiter entwickelt werden mit sich führen, können unnötig Geschwindigkeit kosten. Um kompatibel mit früheren Dateien oder bei Betriebssystemen sogar früheren Prozessoren (bei Apple Umstieg beim Macintosh von der MC68000 Serie auf PowerPC und später Intel Prozessoren) muss alter Code weiterhin enthalten sein, auch wenn er für neue Dateien oder den aktuellen Prozessor nicht nötig ist.

Andere Ursachen können in der Hardware selbst liegen. So hat Intel seit der Erfindung des 8086 Prozessors die Befehle stark erweitert. Man kann neben großen Architekturerweiterungen wie die Einführung eines „flachen“ Adressraumes beim 80286 Prozessor und Befehlen mit 32 und später 64 Bit Breite aber auch zahlreiche kleine Optimierungen ausmachen. Die großen Änderungen erfordern meist ein komplettes Neuschreiben der Programme, weil die neue Architektur andere Befehle hat. Dazu braucht man dann auch ein neues Betriebssystem. Es gibt aber auch einfach neue Befehle, die zusätzlich eingeführt werden und die man nutzen kann – oder auch nicht. Befehle die z.B. die gesetzten Bits in einem Wort zählen. Das kann sehr nützlich sein, wenn man ein Paritätsbit für die Verifikation das alle Bits korrekt übertragen wurden, anhängen muss, oder es gab die Erweiterung bestehender Strukturen, sodass sie mehr Daten verarbeiten konnten und neue Befehle die diese nutzen. So wurden die Fließkommaregister auf 128, später 256 Bit erweitert und es war mit neuen Befehlen möglich dann zwei oder vier Zahlen gleichzeitig zu bearbeiten anstatt nur eine. Die alten Fließkommabefehle nutzten aber weiterhin nur die ersten 64 Bit und konnten nur eine Zahl verarbeiten. Ohne neue Software konnte man diese Erweiterung also nicht nutzen.

Da maschinell übersetzte Software aber zum einen oft solche Spezialbefehle ignoriert (siehe oben) und zum andern dann die Programme nur laufen, wenn diese Erweiterung im Prozessor auch vorhanden ist, (also z.B. nicht auf älteren Rechnern), werden viele dieser Erweiterungen nicht genutzt, das heißt man verschenkt bewusst Geschwindigkeit.

Das gilt auch für die heute vorherrschende Mehrkernarchitektur. Damit mehrere Kerne genutzt werden, muss der Programmierer seine Software so erstellen, dass sie dies auch tut, sonst wird sie nur auf einem Kern ablaufen. Da dies nicht trivial ist (man kann sich z.B. nicht darauf verlassen, das Operationen sequenziell ablaufen, da der Codeteil auf einem anderen Kern vielleicht noch gar nicht fertig ist), wird sehr oft nur ein Kern genutzt, außer die Aufgabe lässt sich leicht aufteilen (beim Browser z.B. im Hintergrund das laden weiterer Seiten – pro Seite ein Kern oder bei dem Rendern von Video kann man pro Bild oder Bildausschnitt jeweils einen Kern mit der Arbeit beauftragen). Intel prognostizierte, als die Mehrkernprozessoren 2005/6 eingeführt wurden, dass sich alle 18 Monate bis zwei Jahre die Kernzahl verdoppeln würde. Damit wäre man heute bei mindestens 16 Kernen. In der Realität werden die meisten Rechner noch mit zwei Kernen verkauft, eben weil obiges Phänomen auftritt. Ein Kern wird dann von einer Anwendung exklusiv benutzt, der zweite steht für aufgaben im Hintergrund bereit oder zum starten einer weiteren Anwendung – das reicht für die meisten Anwender auch aus.

Physiologische Effekte

Was sich über Jahrzehnte nicht geändert hat, ist, was wir als „schnell“ empfinden. Es gibt eine Wahrnehmungsschwelle, die bei etwa einer Zehntelsekunde liegt. Als was schneller passiert ist, ist für uns sofort da, egal ob es eine Zehntel oder Hundertstel Sekunde dauerte, wir empfinden das als sofort. Weiterhin werden wir auch ungeduldig, wenn wir warten müssen und das fängt schon bei einer Sekunde an. Wenn wir warten müssen, empfinden wir ein System als langsam. Auch vergeht für uns die Zeit dann scheinbar langsamer, das zeigten Versuche an Personen, die warten mussten und danach die Zeit abschätzen mussten. Sie alle schätzten die Zeitdauer zu hoch ein. Suchmaschinen liefern daher schon die ersten Ergebnisse aus, wenn sie noch gar nicht alle haben, damit die ersten sicher innerhalb er ersten Sekunde auf dem Bildschirm erscheinen. Sobald wir dann etwas zu tun haben (hier lesen) gilt dem unsere Aufmerksamkeit und wir sind erheblich toleranter hinsichtlich der gefühlten Langsamkeit eines Systems.

Auch die Darstellung auf dem Bildschirm ist wichtig. In Spielfilmen (und in Realität war es auch so), sieht man oft alte Computer, die zeilenweise Ergebnisse einer Abfrage ausgeben und einige Sekunden brauchen, bis sie den Bildschirm vollgeschrieben haben, während das heute sofort geschieht. So erkennen wir auch die Langsamkeit eines Computers. Nerven tut sie uns aber erst, wenn die Darstellungsgeschwindigkeit kleiner ist, als wir die Informationen ablesen können. Das gilt auch für ausgedruckte Informationen über den Drucker. Ein Drucker der langsamer druckt als wir lesen können ist für uns langsam, auch wenn er in absoluter Geschwindigkeit schneller ist als der schnellste Tipper auf einer Schreibmaschine. Ich empfand dies vor allem bei meinem ersten Drucker im „Schönschriftmodus“, in dem er etwa 20 Zeichen pro Sekunde druckte – eine Zeile in 4 Sekunden, das lag weit unter meinem Lesetempo.

Wenn man diese physiologischen Zusammenhänge kennt, so kann man die Langsamkeit eines Systems kaschieren, indem man relativ bald eine Teilmenge an Informationen anzeigt, während man die komplette Informationsmenge noch gar nicht ermittelt hat. So arbeiten Suchmaschinen aber auch Webshops, die nicht nur den Artikel selbst anzeigen (den aber sofort) sondern auch Bewertungen, Kommentare, andere Artikel, die zusammen mit diesem gekauft wurden etc. Um diese Informationen durch Datenbankabfragen zu gewinnen, dauert es, doch wenn der potenzielle Käufer erstmal den Artikel selbst ansehen kann, ist er beschäftigt.

Gibt es einen Ausweg aus dem Dilemma: ja den gibt es. Wenn ein System geschlossen ist, also nicht erweitert werden kann oder Erweiterungen nur einen kleinen Kundenkreis finden, dann wird Software über die Jahre nicht langsamer, sondern leistungsfähiger.

Gute Beispiele dafür sind die Heimcomputer, die Anfang der achtziger Jahre auf dem Markt waren. Sie hatten einen festen Arbeitsspeicher, den man nicht erweitern konnte, das gleiche galt für den Prozessor und als Peripherie gab es meist nur ein Floppydisklaufwerk oder einen Drucker. Da die Hardware feststeht und sich nicht ändert, bekommen Programmierer mit der Zeit immer mehr Erfahrung im Umgang mit ihr. Einer entdeckt eine Möglichkeit, setzt sie ein und andere übernehmen dies. Wer such Spiele für solche Rechner ansieht der ist erstaunt, wie die Qualität der Darstellung oder die Musik im Laufe der Jahre zunahm. Bis heute wird der C64, ein populärer Rechner von 1982 für Demos eingesetzt, die man in der grafischen Qualität nie von einem so leistungsschwachen Rechner erwartet.

Heute ist oft das Gegenteil der Fall. Man erwartet, dass in dem Entwicklungszeitraum der Software von 1 bis 2 Jahren, dass die Rechner in der Leistung stärker werden, sodass wenn sie bei Entwicklungsstart langsam war, sie später auf einem aktuellen Rechner in ausreichender Geschwindigkeit läuft.

Veröffentlichungsdatum des Artikels: 5.10.2013

Zum Thema Computer ist auch von mir ein Buch erschienen. "Computergeschichte(n)" beinhaltet, das was der Titel aussagt: einzelne Episoden aus der Frühzeit des PC. Es sind Episoden aus den Lebensläufen von Ed Roberts, Bill Gates, Steve Jobs, Stephen Wozniak, Gary Kildall, Adam Osborne, Jack Tramiel und Chuck Peddle und wie sie den PC schufen.

Das Buch wird abgerundet durch eine kurze Erklärung der Computertechnik vor dem PC, sowie einer Zusammenfassung was danach geschah, als die Claims abgesteckt waren. Ich habe versucht ein Buch zu schreiben, dass sie dahingehend von anderen Büchern abhebt, dass es nicht nur Geschichte erzählt sondern auch erklärt warum bestimmte Produkte erfolgreich waren, also auf die Technik eingeht.

Die 2014 erschienene zweite Auflage wurde aktualisiert und leicht erweitert. Die umfangreichste Änderung ist ein 60 Seiten starkes Kapitel über Seymour Cray und die von ihm entworfenen Supercomputer. Bedingt durch Preissenkungen bei Neuauflagen ist es mit 19,90 Euro trotz gestiegenem Umfang um 5 Euro billiger als die erste Auflage. Es ist auch als e-Book für 10,99 Euro erschienen.

Mehr über das Buch auf dieser eigenen Seite.

Hier geht's zur Gesamtübersicht meiner Bücher mit direkten Links zum BOD-Buchshop. Die Bücher sind aber auch direkt im Buchhandel bestellbar (da ich über sehr spezielle Themen schreibe, wird man sie wohl kaum in der Auslage finden) und sie sind natürlich in den gängigen Online-Plattformen wie Amazon, Libri, Buecher.de erhältlich.

© des Textes: Bernd Leitenberger. Jede Veröffentlichung dieses Textes im Ganzen oder in Auszügen darf nur mit Zustimmung des Urhebers erfolgen.
Sitemap Kontakt Impressum / Datenschutz Neues Hier werben / advertisment here Buchshop Bücher vom Autor Top 99