Experteninterview: "Software könnte fünfmal schneller sein"
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.
Inhalt
16 von 29 Lesern fanden diesen Artikel nützlich.
* 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? ;)
"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
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 ;)
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.
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.
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.