Software ist überall: als Betriebssystem auf unserem PC, als Rückgrat der Warenwirtschaft in Unternehmen und inzwischen sogar in Autos und als „App“ auf dem iPhone. Und sie unterliegt – ebenso wie vieles andere – inzwischen Moden. Aber Moden sind kurzlebig. Also muss auch Software schnell und äußerlich ansprechend entwickelt werden. „Innere Werte“ zählen dabei immer weniger.
Aber Software trägt durch die Art ihrer Programmierung wesentlich zum Energieverbrauch der Rechner bei, die mit ihr arbeiten müssen. Und Software führt zu ärgerlichen Verzögerungen beim Aufrufen von Programmen – das ist nicht die Schuld der Entwickler, müsste aber auch nicht sein. Neue Paradigmen auch beim Rechnerbau könnten die Effizienz von Software um ein vielfaches steigern, meint Gunter Dueck, IBM Distinguished Engineer. Im ZDNet-Interview erklärt er, wie er zu dieser Ansicht kommt und warum es trotz immer noch rasch wachsender Rechen- und Speicherkapazitäten ein erstrebenswertes Ziel ist, Software ressourcenschonend zu programmieren.
Gunter Dueck, Mathematikprofessor und IBM Distinguished Engineer (Bild: Gunter Dueck/omnisophie.de).
ZDNet: Herr Dueck, Sie glauben, Software könnte um ein Mehrfaches effizienter arbeiten. Wieso?
Dueck: In den Anfängen der Programmierung kam es auf jedes Bit und jedes Byte an. Denn die Interpretation einer Zeile Programmcode verursachte eine Verzögerung von einer Millisekunde. Man hat als Programmierer versucht, diese Verzögerung zu vermeiden, indem man den Code in möglichst wenige Programmzeilen steckte, die aber sehr durchdacht waren. Ein guter Programmierer konnte zum Beispiel bei Vektoroperationen Vektoren mit einem einzigen Befehl komplett umdrehen, während man heute jede Zahl im Vektor einzeln verschiebt.
Zum Beispiel konnten bestimmte Spiele auf Atari oder Commodore nur laufen, wenn man jedes überflüssige Bit in den oberen Speicherbereich verschob, denn es gab einfach nur sehr begrenzte Kapazitäten. So zu programmieren, war natürlich sehr aufwändig und teuer. Deshalb sind diese Programmierkünste heute verloren gegangen.
ZDNet: Warum hat man damit aufgehört?
Dueck: Das hat mit einer an sich positiven Entwicklung zu tun, nämlich mit der Verbilligung und Verkleinerung der Hardwareressourcen, letztlich also mit dem Mooreschen Gesetz. Wenn ich Gigabytes an Speicher und superschnelle Prozessoren zur Verfügung habe, dann ist es eben nicht mehr nötig, solche Programmierakrobatik zu betreiben. Infolgedessen – und davon haben alle, auch die Anwender, lange profitiert – wurde die Programmierung darauf optimiert, möglichst schnell und möglichst günstig neue Software zu entwickeln. Ob die sparsam mit Speicher- oder Prozessorressourcen umgeht, war lange kein Thema.
Neueste Kommentare
9 Kommentare zu Experteninterview: „Software könnte fünfmal schneller sein“
Kommentar hinzufügenVielen Dank für Ihren Kommentar.
Ihr Kommentar wurde gespeichert und wartet auf Moderation.
Oberer Speicherberich?
Ich dachte, dass Problem mit dem oberen Speicherbereich gab es beim 68000er nicht???
AW: Oberer Speicherberich?
>Zum Beispiel konnten bestimmte Spiele auf Atari oder Commodore nur laufen, wenn man jedes überflüssige Bit in den oberen Speicherbereich verschob, denn es gab einfach nur sehr begrenzte Kapazitäten.
LOL. Diese Geräte hatten nie einen „oberen Speicherbereich“. Was für ein Schwachsinn!
Aber zum Thema Performance: Ein AMIGA 2000 ist ohne weiteres in unter 10 Sekunden hochgefahren. Manche „irren“ Programmierer ersetzen dann Systemprogramme durch eigene, die nochmal ein klein wenig schneller waren, so dass am Ende manche Amigas in 4 Sekunden oben waren.
Die Systemoptimierung im Amiga OS stellte sich damals so dar, dass ein Entwickler jubelte, wenn er beim Aufruf der CLI-Shell wieder 2k RAM eingespart hatte und dabei noch die Geschwindigkeit erhöhte. Programme starteten innerhalb von 2 Sekunden und alles zusammen kam mit 4MB RAM aus.
Man kann sehr RAM-sparend programmieren, wenn man großteils auf System-DLLs zurückgreift, statt massenweise eigene Grafiken und eigenen Code zu verwenden.
Dieses Denken traf auf Windows-Entwickler allerdings nie zu. Sie nahmen sich schon immer alles an Resourcen, was sie bekommen konnten, so dass seit meinem ersten 286er mit 1MB RAM die Anwendungen gefühlt immer langsamer wurden.
Ich werde nie den Dialog vergessen, den ich einmal in einem Markt gehört habe:
KUNDE: Ich brauche einen Computer.
VERKÄUFER: Was wollen Sie denn damit machen?
KUNDE: Email, Surfen und so…
VERKÄUFER: Da brauchen Sie mindestens einen 2GHz-PC, denn das sind sehr rechenintensive Anwendungen.
Binsenweisheiten
Das sind ja mehr oder weniger alles Binsenweisheiten von Herrn Dueck. Klar könnte Software deutlich schneller sein, wenn man nur hin auf Performance entwickeln würde. Aber man hat eben gemerkt, dass Performance nicht alles ist, sondern Stabilität, Sicherheit, Erweiterbarkeit und Effizienz wichtiger sind.
Herr Dueck wüde wohl auch gerne auf Speicherschutz und preemtives Multitasking verzichten, zum Glück sieht die Realität anders aus. Es ist auch nicht ohne Grund, dass heutige Programmierparadigmen auf VMs setzen, die sich automatisch um Speicherallokation und Deallokation und noch vielen anderen Dingen kümmern. Mit C/C++ könnte man zwar je nach Fall schnelleren/optimierteren Code produzieren, aber dafür auch schnell mal instabile Anwendungen produzieren. Wobei die VMs eigentlich heute schon sehr gut optimieren und je nach Anwendungsfalls sogar schneller (oder mal langsamer) sein können als nativer Code. Und selbst bei nativen Code prüfen eigentlich heutige APIs z.B. auf Bufferoverruns. Der Overhead ist einfach erwünschenswert.
Objekt-Orientierung
Was denn OOP mit Modularisierung zu tun? Mann kann auch strukturierte Programme „zerlegen“. OOP wurde – wie vom Professor und einem Kommentierenden erwählt – gar nie aus Performanzgründen „erfunden“, sondern um die Programmierung zu vereinfachen.
Die Sache mit den vielen Prozessoren muss ich mir aber erst noch genau überlegen, ob das wirklich die Lösung sein kann (wenn er schon von GreenIT spricht). Das könnte vielleicht zur Ausfallssicherheit beitragen. Allerdings habe ich die Aussage auch so verstanden, dass er Prozessoren (ausschliesslich) für bestimmte Zwecke (Textverarbeitung) möchte. Aber ich glaube, das beisst sich mit der Wirtschaftlichkeit.
dueck
Herr Dueck hat im Prinzip Recht.
Als früherer Operator / Programmierer / Sytembetreuer auf Großrechnern und PCs kann ich bestätigen, dass früher wesentlich effektiver programmiert wurde und werden mußte. (mangelnde Prozessor- und Speicherkapazität)
Man wundert sich heute immer wieder, wie komplexe Programme bereits auf damaligen Großrechnern (z. B. 1972) mit 64 oder 150 KB Hauptspeicher laufen konnten.
Damals war die Bit-Sparerei sehr ausgeprägt und effizient.
Es wurde in Assembler programmiert, also Maschinensprache. Schon COBOL war zwar komfortabler, aber der Compiler wandelte die Befehle wiederum in Maschinensprache um, wobei oft eine Vielzahl von Befehlen entstand. Bei den modernen Programmiersprachen, die auch wesentlich komfortabler sind, ist dieser Overhang oft noch wesentlich höher.
Weiterhin wurden bei Korrekturen alte Elemente, die nicht mehr benötigt werden, entfernt und nicht als „Programmleichen“ belassen.
Im Endeffekt geht die einfachere Programmierweise zu Lasten der Effektivität.
– aber man hat jetzt ja Prozessor- und Speicherkapazität genug ….
Wenn man es sich antun würde so effizient wie in den Anfangsjahren der EDV zu programmieren, wäre der Faktor 5 nicht utopisch.
Starker Tobak!
Dueck: „Ein guter Programmierer konnte zum Beispiel bei Vektoroperationen Vektoren mit einem einzigen Befehl komplett umdrehen, während man heute jede Zahl im Vektor einzeln verschiebt.“
* Also, wenn ich einen Vektor komplett umdrehen will, dann multipliziere ich ihn einfach mit -1 und verschiebe nicht jede ‚Zahl‘ einzeln! ;)
Um Software wirklich effizient zu gestalten, kommt nur Assembler-Programmierung in Frage – und da braucht man für diese Aufgabe auf jeden Fall ein paar Befehle mehr…
Dueck: „Zum Beispiel konnten bestimmte Spiele auf Atari oder Commodore nur laufen, wenn man jedes überflüssige Bit in den oberen Speicherbereich verschob, denn es gab einfach nur sehr begrenzte Kapazitäten. So zu programmieren, war natürlich sehr aufwändig und teuer. Deshalb sind diese Programmierkünste heute verloren gegangen.“
* Na und? – Es gibt schließlich auch keinen oberen Speicherbereich mehr. – Diese Fertigkeit wäre also brotlose wirklich Kunst!
Dueck: „Das hat mit einer an sich positiven Entwicklung zu tun, nämlich mit der Verbilligung und Verkleinerung der Hardwareressourcen, letztlich also mit dem Mooreschen Gesetz.“
* Mooresches Gesetz und Verkleinerung der Hardwareressourcen???
Wohl eher Verkleinerung der Chip-Strukturen, aber Vergrößerung der Ressourcen!
Dueck: „Richtig, und zwar aus zwei Gründen. Einmal, weil unsere Rechner in der Regel viel zu lange brauchen, um hochzufahren. Das ärgert viele Anwender, und es sollte nicht so sein.“
* Und was ist daran jetzt anders als früher? – Das war doch schon immer so!
Dueck: „Zum anderen baut die Debatte um Green-IT- und den Umgang mit Ressourcen Druck auf. Inzwischen fragen sich auch die Spezialisten, ob es wirklich nötig ist, dass die Software ständig alle Prozessorbestandteile am Laufen hält. Langsam verschiebt sich der Fokus der Optimierung: weg von den immer schnelleren Prozessoren, hin zu neuen Konzepten.“
* Das passiert aber eher bei den Chipherstellern, als bei den Programmierern!
Die Software, welche Multithreading mit entsprechender Effizienzsteigerung unterstützt, kann man doch ein einer Hand abzählen!
Wenn es hier ein Umdenken bei den Entwicklern gibt, dann nur, weil ihre Anwendungen auch auf sogenannten Smartphones und Netbooks anständig laufen sollen.
Dueck: „Objektorientierung diente in erster Linie der Beschleunigung und Verbilligung der Programmerstellung: Man baut Module, die anschließend mehrfach verwendet werden sollen.“
* Das ist nur ein Grund. Wichtiger ist aber, dass man durch die Modularisierung erst die Möglichkeit erhält, durch die heutzutage sehr viel komplexeren Programme, überhaupt noch durchzusehen. Gerade, wenn mehrere Entwickler zusammen arbeiten sollen, ist es wichtig, dass jeder seinen eigenen Bereich hat.
Außerdem ist es gut alten Code zu verwenden, schließlich ist dieser schon ausgiebig getestet und enthält daher viel weniger Fehler als neuer Code.
Dueck: „Man kann sich zum Beispiel Systeme vorstellen, die aus vielen, aber billigeren Prozessoren bestehen. Diese Prozessoren wären dann jeweils nur für eine ganz bestimmte Anwendung oder Aufgabe zuständig.“
* Man kann sich ja vieles vorstellen, aber der Rechner wurde deswegen erfolgreich, weil er so universell ist. Wenn er aus vielen kleinen Prozessoren aufgebaut ist, dann wäre er zwar schnell und effizient für die speziellen Aufgaben, für die er entwickelt wurde, aber langsam für sonstige Aufgaben. -> Wird sich niemals durchsetzen!
Außerdem gibt es mit DSPs ähnliches bereits schon. – Und wer hat da einen? ;)
AW: Starker Tobak!
Hallo,
„Verkleinerung der Hardwareressourcen“ ist wohl etwas missverständlich: Gemeint ist hier sicherlich nicht die Reduzierung der Leistungsfähigkeit, sondern die Miniaturisierung der Komponenten.
Peter Marwan
ZDNet-Redaktion
AW: Starker Tobak!
Teilweise hast du recht, teilweise hast du allerdings nicht lesen wollen, was der kerl meinte. Mit den Strukturgrößen hat ja schon jemand geschrieben. Der nächste punkt wäre der „Multicore“ Ansatz. Im Interview war gemeint: Ich habe 20 Prozessoren, auf jedem läuft ein Programm und nur die Prozessoren, die wirklich was machen werden mit Strom versorgt. Er meinte aber auch das diese Prozessoren universell einsetzbar bleiben. Und nicht wie du sagst spezialisiert werden.
Sich darüber Gedanken zu machen ist aber Schnee vom letzten Jahrtausend. Prozessoren schalten schon ganze Regionen aus, wenn sie nicht gebraucht werden.
Wenn er wirklich schnellere Software haben möchte, sollte er sich nochmal den Objekt Orientierten Part anschauen. Der ist nett zum entwickeln, mittelmäßig um große Strukturen zu handhaben und da hier meistens 20 Abstraktionsschichten eingebaut werden, geht hier eine Menge Performance verloren. Wenn ich beschleunigen will, muss ich schauen, wie viele Abstraktionsschichten ich wirklich in meiner Anwendung brauche. Und muss da optimieren. Dann muss ich noch meine Datenstrukturen dem Gebrauch anpassen (und nicht einfach ein paar Tabellen/Dateien erstellen) und schon hab ich die meisten Anwendungen um Faktor 2 beschleunigt. Gehe ich dann noch hin und überlege mir, WO ich Daten ablege und wie ich den Kram zwischenspeichere, dann bin ich schon bei 3-10 mal schnelleren Anwendungen.
Und Bit-Schieberei bringt heute kaum noch jemanden weiter. Prozessoren arbeiten heute einfach nicht mehr wie damals.
BTW: Es gibt noch einen High-Memory. Man nennt ihn RAM. Stell dir mal vor, man würde das OS + Programme soweit optimieren, das sie zu 100% in den bis zu 4 MB Prozessor Cache laufen könnten?! Früher gings mit 640 kb ;)
Prozessor-Cache = RAM?!
Da wird aber einiges durcheinander geworfen. Natürlich könnte man das einfach mal eben umdefinieren, damit es passt. :-) Aber das gewöhnliche RAM befand sich noch nie in einem Prozessor.
Beim 80x86er war es wohl eher ein Adressierungsproblem damals. Ich weiß noch, dass ich unter TurboPascal nicht mehr als 64kb Daten am Stück adressieren konnte. Programme konnten auch nicht größer werden, dann müssten sie mit „Overlays“ realisiert werden.
Es ist alles eine Frage des Designs. Wenn man anfangs halt denkt, dass 640KB direkt adressierbarer RAM für Jahrzehnte ausreichen werden, dann passiert so etwas.