Software wird schneller langsam, als Hardware schneller wird

Dieses von Nikolaus Wirth beschriebenen Phänomen wird inzwischen auch als „Wirthsches Gesetz“ bezeichnet. Demnach wird der Fortschritt bei der Hardwareentwicklung durch immer ineffizienter programmierte Software ausgeglichen. Nun ganz so schlimm würde ich es nicht sehen. Aber ich will mal dieses Thema aus einer anderen Perspektive aufgreifen. Und zwar will ich die Stationen der Benutzerfreundlichkeit von Anwendungen bei PC’s Revue passieren lassen.

Als die 8-Bit-Rechner einen Hauptspeicherausbau von annähernd dem Maximum was adressiert werden konnte, so 48 bis 64 Kbyte hatten, konnte man mit CP/M die ersten Anwendungsprogramme betreiben. Wer mal mit Wordstar, DBASE oder Multiplan gearbeitet hat, weiß aber auch von den Einschränkungen. Wordstar hatte kryptische Tastenkombinationen. Formatierungen gab es als Steuerzeichen auf dem Bildschirm und genauso wie bei Multiplan konnte man beim Scrollen sehen wie sich jede Zeile neu aufbaute. Dbase lieferte Datensätze langsam zurück, 1-2 pro Sekunde.

Unter MS-DOS und 16-Bit Rechnern wurde die Software schneller, konnte größere Datenmengen bearbeiten und zum Ende hin gab es sogar eine Andeutung des Ausdrucks durch fett, Unterstreichen oder Kursiv auf dem Bildschirm, wenn allerdings nicht im richtigen Font.

Die nächste Stufe war die grafische Oberfläche. Erstmals war es möglich die reale Welt irgendwie auf dem Computer abzubilden, wenn auch mit Krücken wie Icons für Dateien. Aber immerhin musste man sie nicht mit Befehlen kopieren, sondern konnte sie mit der Maus verschieben, wie im richtigen Leben. Für die Anwendungen bedeutete dies auch, dass nun der Bildschirm den Ausdruck wiedergeben konnte, angefangen von Texten über Bildschirmmasken.

Wie bei der Textoberfläche dauerte es dann Jahre bis Jahrzehnte bis diese Oberfläche perfektioniert wurde. Wenn ich zum Beispiel die Grundfunktionalität von Winword 2 nehme und sie mit Openoffice heute vergleiche, so ist letzteres natürlich schicker, es geht heute Online-Rechtschreibprüfung und Grammatikprüfung, aber die Grundfunktionen haben sich kaum geändert. Dabei ist heute ein Rechner 100-1000 mal schneller als der, auf dem WinWord 2 lief.

Nun scheint es den nächsten Schritt zu geben, nicht auf dem PC sondern einem Smartphone. Es wird mit Gesten gesteuert, erkennt Sprache und antwortet mit Sprache, was dazu geführt hat dass nun nach den zahllosen Leuten die bisher schon alleine redend durch die Gegend gelaufen sind, weil sie mit jemanden anderen telefonieret haben noch viel mehr dazu kommen werden, die bald mit niemanden mehr telefonieren, sondern ihrem Smartphone reden. Aber es ist eine weitere Stufe der Benutzerfreundlichkeit, denn nun muss ich keine Menüpunkte mehr lernen, nicht mehr selbst suchen, sondern ich kann eine umgangssprachliche Frage stellen.

Betrachtet man sich diese Entwicklung, so ist sicher der Computer seitdem um den Faktor 10.000 schneller geworden. Wenn man nur die Anzahl der Transistorfunktionen nimmt, dann liegen zwischen einem Z80 und dem schnellsten Intel Prozessor heute rund der Faktor 200.000. Ist die Software um so viel leistungsfähiger geworden? Oder ist sie viel langsamer geworden? Ich denke man kann es nicht allgemein beantworten. Nehmen wir nur mal den Desktop von Windows. Er war unter Windows 3 einfarbig, heute ist er  transparent, Fenster scheinen durch, es gibt Verläufe. Wer sich technisch auskennt weiß, das es viel einfacher ist eine Fläche monochrom auszufüllen, als jedes Pixel transparent in Abhängigkeit vom Hintergrund zu setzen. Dafür geht sicher viel der Mehrrechenleistung drauf. Das nächste ist die Perfektionierung von Anwendungen. Bei Textverarbeitung erkennbar in Hintergrundformatierung, Grammatikprüfung und Assistenten die Hilfestellung geben und den Anwender überwachen. Auch dafür braucht man mehr Rechenleistung. Irgendwann ist dann ein Stadium der „Vervollkommnung“ erreicht und mehr Leistung bringt nicht mehr Nutzen, dann denke ich, ist der Schritt reif für ein völlig neues Bedienkonzept wie eb4m heute die Sprachsteuerung und das Parsen umgangssprachlicher Ausdrücke.

Das zweite ist natürlich auch, dass die Softwareentwicklung sich ändert. Früher wurde sie in Assembler programmiert, dann in C. Heute dominieren interpretierte Sprachen wie Java, C# oder es wird gar der Code vom Anwendungsprogramm interpretiert wie bei Javascript oder Flash. Bibliotheken wachsen an und damit auch der Overhead. Man muss sich nur ansehen wie groß ein „Hello World“ mal war und wie groß es heute ist.

Zuletzt entwickeln sich Systeme historisch. Altlasten werden weiter geschleppt, es wird nur erweitert und selten neu begonnen. Alleine dadurch werden sie langsam. Es ist kein Zufall, das die Sprachsteuerung bei Smartphones eingeführt wurde und funktioniert, während man auf dem PC seit 20 Jahren erst mal das Sprachsystem trainieren muss und wenn dann kann der PC Text erkennen und abtippen, aber er kann nicht den Inhalt verstehen und dann mir eine Auskunft erteilen. Es ist viel einfacher ein Gerät vom Tabula Rasa aus zu entwickeln das genau dies kann, als das alte System Windows um diese Funktionen zu erweitern. Dabei ist der Prozessor in einem IPhone um ein vielfaches leistungsschwacher als ein aktueller Prozessor von AMD oder Intel.

Ich denke die letzten beiden Punkte, die Altlasten und die immer stärkerer Programmierung in interpretierenden Sprachen sind die Hauptgründe für das Wirtsche Gesetz.

24 thoughts on “Software wird schneller langsam, als Hardware schneller wird

  1. Das mit dem Ausbremsen durch interpretierende Sprachen kann ich nur bestätigen. dBase war saulahm, aber es gab Clipper, einen dBase-Compiler. Damit wurde es richtig schnell. Der Nachteil dabei: Selbst bei der geringsten Änderung mußte man das Programm neu compilieren und linken – 10 Minuten Wartezeit. Zu DOS-Zeiten gab es übrigens auch mal einen Basic-Compiler. Aber wer weiß heutzutge noch, daß sowas überhaupt möglich ist?

    Aber auch die objektorientierte Programmierung macht das Programm langsam. Bequem für den Programmierer, schlecht für das Programm. Und wer kennt heutzutage überhaupt noch die Tricks, ein Programm schneller zu machen? Eigentlich nur noch die alten Assembler-Programmierer, und die sterben langsam aus.

    Kleines Beispiel: Multiplikation ist langsamer als Adition, und Division noch langsamer. Statt 2*A sollte man also lieber A A rechnen, das ist schneller und spart auch noch den Speicherplatz für eine Konstante. Oder statt A/2 lieber A*0,5 rechnen. Aber in welchen Programmcode sieht man das? Ganz zu schweigen vom Programmieren zeitkritischer Stellen in Assembler. Die Compiler bieten ja seit Jahrzehnten die Möglichkeit, mit Inline-Assembler zu arbeiten. Aber wer nutzt das noch?

    Und noch einen Grund gibt es: Die Hardwerhersteller rufen immer mal wieder die Software-Industrie auf, ihre Programme so zu schreiben, daß man sich neue Hardware dafür kaufen muß. Solange die Programme auch noch auf dem alten Rechner schnell genug laufen, wird ja selten neue Hardware gekauft. Früher reichten mal 64 KB RAM für Betriebssystem, Anwenderprogramm und Bildschirmspeicher aus. Heute braucht man schon einige hundert MB, damit das System überhaupt bootet. Und das auch noch langsamer, als früher von Diskette.

  2. Ein paar Anmerkungen:

    – Die CPU’s sind massiv schneller geworden aber die Latenzzeit des RAM’s ist recht konstant im Bereich von 100ns geblieben. D.h. ein Prozessor wartet locker mal 1000 takte bis eine Anfrage auf einen Wert im RAM beantwortet werden kann! Noch viel schlimmer ist ein Zugriff auf die Harddisk. Die hat Zugriffszeiten im Bereich von ms. Es dauert also einige 1000000 takte bis die CPU mal irgendwas von der Harddisk bekommt.

    – @Elendsoft Diese „Tricks“ die du da gennant hast (2*x => x x, x/2 => x >> 2 etc.) kann der Compiler viel besser als ein Mensch. Da kann man eigentlich überhaupt nichts herausholen. Der Compiler kan dir auch eine Optimierung für 15*x machen (16*x – x, 16*x ist eine sehr schnelle operation weil sie mit 4 bitshifts nach links erledigt werden kann).

    – Um mit Assembler schnelleren Code zu erzeugen als mit einem Compiler musst du unterdessen sehr gut sein und sehr viel Zeit investieren. Es gibt immer ein paar Speziallfälle wo das Sinn macht. (Evtl. bei der Videocompression wo sehr viel Zeit in sehr wenig Code verwendet wird)

  3. Zu nennen wäre unter Windows noch die Laufzeitumgebung .NET Framework. Auch immer mehr Freeware von Hobbyprogrammierern setzt diese oder jene .NET Variante voraus.

    @Fabian: Die Latenzzeit von Festplatten läßt sich seit einigen Jahren um den Faktor 1000 steigern durch die Verwendung von SSDs, und die kann sich mittlerweise durchaus jeder leisten. Ich benutze ausschließlich nur noch das Konzept „OS auf SSD, Datenarchiv auf einer Terabyte-HDD“.
    Austausch der System-HDD durch eine SSD ist mittlerweile mit Abstand die auffälligste Aufrüstmaßnahme für einen PC mit einem wirklichen AHA-Effekt, insbesondere bei einem Notebook, wo auch noch der Vorteil der Erschütterungsfestigkeit zusätzlich greift.

  4. Naja ich glaube nicht so ganz an dieses Gesetz. Es mag eine Zeitlang gestimmt haben aber irgendwie glaube ich auch das man früher eben auch noch mehr ein Gefühl dafür hatte das der Computer gerade Arbeit verrichtet. Ich habe vor ein paar Monaten meinen alten Rechner von ich glaube 2003 mal wieder in Betrieb gesetzt und obwohl ich nichts an der Softwarekonfiguration geändert hatte kam mir das Ding auf einmal unglaublich lahm vor. Man musste ewig warten bis eine Anwendung offen war, man durfte nicht zuviele Anwendungen gleichzeitig offen haben und ähnliches. Dabei war mir das früher mit dieser Maschine nicht so gegangen, als ich sie kaufte empfand ich sie sagar als relativ flott. Klar gibt es immer dieses Geheule wenn z.B. ein neues Windows erscheint (Ok 7 ging sogar da es im Vergleich zu Vista sogar schneller oder zumindest gleich schnell war) aber man sollte vielleich mal über folgendes nachdenken: Klar ist auf einem für Vista gerade geeigneten Rechner (also 1GB RAM etc.) ein XP schneller als ein Vista (auch wenn Vista bei viel RAM XP irgendwann abhängt weil die Optimierungen anders sind) aber man sollte mal diesen Vista-Rechner mit einem XP-Rechner der XP-Anfangszeit vergleichen. Dann bekommt man eben einen Vergleich von für einander gebauter Hard- und Software und da glaube ich nicht das der Vista-Rechner so schlecht abschneiden würde.

    Mit DOS will ich nicht anfangen, dieses Teil verstößt ja schon fast gegen die Definition eines Betriebssystems (je nachdem wie man die setzt ist es eins oder nicht).

    Zu diesem modernen Programmiersprachen-Bashing: Man will einfach keine moderne Anwendung in Assembler schreiben (Früher genügte vielleicht ein Textmodus …). Zum anderen sind die Compiler heute extrem hochoptimiert und auch für die Interpreterspachen gibt es ziemlich gute Just-in-Time-Compiler. Es gibt da ab und an so Tests und wenn man sich ansieht das Java vielleicht um den Faktor 3 langsamer ist als C (Ok Javas Grafik ist langsamer) und Javascript lediglich um einen Faktor 8 oder so dann ist das gar nicht mehr so viel bei teilweise deutlichem Komfortgewinn für den Programmierer und teilweise auch den Anwender. Und anstatt A A würde ich einen shift machen, das aber nur so nebenbei.

  5. Das mit der langsamer werdenden Software kann ich nur bestätigen!
    Da ich seit etwa 12 Jahren fast die gleiche Hardware nutze, auf der ich nur alle paar Jahre mal das BS und die Grafikkarte ausgetauscht habe, konnte ich das gut beobachten. So hab ich z.B. Ende der 90er Anfang der 2000er Jahre einige umfangreiche Bilder mit Star Office‘ Draw, also dem Zeichenprogramm erstellt. Das war damals die Version 5.1, und lief unter OS/2 Warp 3 hervorragend flott. Wenn ich das heute unter Windows 2000 (was zwar nicht viel neuer ist, aber) mit OpenOffice 3.1 mache, dann geht es teilweise nur mit einigem Ruckeln und Wartezeiten im Bereich um ein oder zwei Sekunden. Das nervt langfristig.
    Noch schlimmer manchmal der WebBrowser. Ende der 90er Jahre hab ich mich über Intelwerbung geärgert, die suggerieren wollte, das die Datenübertragung des Internets von der Arbeitsgeschwindigkeit des Prozessors abhängt, der im PC werkelt. Mittlerweile scheint es wirklich so zu sein, weil immer mehr Skripte in den Webseiten integriert sind, die erst mal interpretiert werden müssen, und die u.U. auch Seiteninhalte nachladen. Das führt dazu, das eine Seite nicht gleich vollständig angezeigt werden kann. Stattdessen ruckelt der Seitenaufbau, und was die Sache noch schlimmer macht, da der Rechner nicht mit genügend RAM Speicher ausgestattet ist, lagert er ständig irgendwas auf die Festplatte aus, was alles noch mal zusätzlich ausbremst. Wenn man den Speicherhunger mancher Anwendung reduzieren würde, wäre da sicher schon einiges erreicht. Und Natürlich den Programmcode hinsichtlich der grösse optimieren. Geht alles, kostet aber wahrscheinlich zuviel Zeit…
    Ach ja, fällt mir gerade auch noch ein: Bei der NASA hab ich neulich ein Bild entdeckt, das meinen Rechner wahrscheinlich in die Knie zwingt: ein rund 25 MB grosses Jpg! – Ich weis nicht, wie viel Platz das Teil im entpackten Zustand einnimmt, aber ich denke, selbst IrfanView wird da 2 bis 3 Minuten rechnen, bis er es anzeigt.

  6. Zu den Programmiertricks:
    Dass man so Optimierungen wie Bitshift anstelle von Multiplikation heutzutage dem Compiler überlassen sollte, hab ich auch schon in einem Programmiererforum gelesen. Viel trauriger finde ich allerdings die Tatsache, das manche Leute, die sich Programmierer nennen, solche Tricks nicht mal verstehen. Denn zumindest der Bitshift gehört ja zu den „Kindergartentricks“, wenn man Code optimieren will.
    Schwierig wird es dann, wenn erweiterte Mathekenntnisse erforderlich sind, weil die Tücken schon im Algorithmus stecken…

  7. Moin,

    zum einen ist es bei Windows Absicht, dass das System langsamer wird, weil M$ ja einen Großteil seine Produkte im Bundle mit Neucomputern verkauft.

    Die Masche dabei die Kopie von Word und Excel. Angenommen Bernd und ich wollen einen Text bearbeiten. Bernd schickt mir den Text, aber mein Rechner ist älter, hat ein älteres Windows XP und Word. Ich kann diesen Text nicht öffnen, aber Bernd ist ja ein guter Kumpel, und gibt mir seine CDs.

    Ich installiere also das neue, doch mein Rechner ist jetzt viel zu langsam, also kaufe ich mir einen neuen, bei dem natürlich ein neues Windows 7 und Word dabei ist. Jetzt hat Bernd das Problem, dass er meinen Text unter Vista nicht lesen kann, aber ich bin ja ein guter Kumpel, und leih ihm meine CDs.

    Durch die (Raub)Kopie hat also Microsoft zwei mal Windows verkauft.

    Ähnlich hat auch damals IBM 24bit Mainframes verkauft. MVS, VM und DOS waren ja licensed without Charge, without Warranty, in Source and Objekt. Freie Software gab es Monatlich auf den CB Tapes. Und so musste ständig der Mainframe erweitert werden. IBM hat sich dann selber mit den 31bit Betriebssystemen ein Eigentor geschossen, als dieses nur noch im Objekt Code zu mieten war, und die Systemprogrammierer wie ich zu so genannten offenen Systemen umgestiegen sind.

    Aber auch Linux ist vom Bloat nicht verschont geblieben. Ein gutes Video zur Frage, warum Unix look likes größer geworden sind ist:

    http://www.youtube.com/watch?v=Nbv9L-WIu0s – Bloat: How and Why UNIX Grew Up

    ciao,Michael

    PS: Das DOS hat nichts mit M$DOS gemein. Und ist wohl eines der wenigen Systeme die vom Bloat verschont wurden, weil es seit 30 Jahren nichts mehr neues gibt. Heute läuft dann meinst unter 62bit z/OS ein 31bit VM/ESA in dem ein 24bit DOS/VS läuft. Mit uralt Software, und extrem schnell.

  8. Also Bernd würde nie eine CD verleihen.
    Bernd hat nämlich was gegen Raubkopierer und konnte schon im Studium nicht verstehen, warum angehende Softwaretechniker fleissig raubkopierten – so macht man sich die eigene Berufsgrundlage kaputt. Ich gebe aber gerne zu dass ich wenig gekaufte Software habe, weil ich gerne viel freie Software einsetze. Mir fallen neben einigen Spielen nur Duden-Korrektor, Steuerprogramm und Delphi ein. Allerdings profitiere ich (noch) von dem Tatbestand, dass ich bis 2009 als Angestellter einer Hochschule an etliche MS-Software umsonst und legal herankam.

    Aber zurück zum Thema. Dass alles langsamer wird hat nichts mit MS zu tun, auch Linux wird immer langsamer, freie Software wie openoffice oder verschiedene Browser oder Thunderbird auch. Weiterhin muss man sich mal ansehen war in Smartphones oder Webpads für Hardware steckt und was man damit anfangen kann….

  9. Nun, ich kenne mich mit Programmieren nicht aus, aber ist es nicht so, das die Leistung der Hardware sich linear entwickelt (Moore’sches Gesetz) während die Softwareevolutionschritte vielfach exponeniell sind?
    D.h um aus der Software die doppelte Leistung raus zu bekommen benötigt man zb. eine vierfache Steigerung der Hardwareleistung.

    Zumindest bei Videospielen ist das so!

  10. Also ich arbeite viel mit Video und 3D Software. Grundsätzlich kann ich sagen, dass die Software nicht durch nicht langsamer wurden. Zwar ist die durchschnittliche Renderzeit über die Jahre konstant geblieben, aber die Qualität der Effekte hat sicher entsprechende gesteigert. Gewisse Sachen, die ich heute mache, wäre vor ein paar Jahren nicht möglich gewesen, oder es hätte so lange gedauert, dass man heute noch dabei wäre.
    Jedes Mal als einen Computer bei mir gab nahm die Komplexität meiner Effekte schlagartig zu.

  11. @Atanjeo: Nein, gerade umgekehrt. Die Leistung der Hardware wird exponentiell hoeher.

    @Bernd: Und bei den Webpads/Handys gibt es dann noch den Unterschied zwischen Apple (iOS) und „den anderen“ (Android). Bei Apple merkt man ganz besonders (auch, wenn die „Androidler“ dann beleidigt sind), dass dort vernuenftige Software entwickelt wird, denn iPhone-Apps sind z.B. bei langsamerer Hardware meistens um ein vielfaches fluessiger und schneller.

    Das liegt daran, dass iOS Apps fast immer in einer sehr maschinennahen Sprache (Obj-C) programmiert sind, waehrend auf Android ein 10-fach verschachtelter Interpreter- und Zwischenlayer-Stack (Java etc.) laeuft.

  12. „Denn zumindest der Bitshift gehört ja zu den “Kindergartentricks”, wenn man Code optimieren will.“ => Nein gehört er nicht. Allerhöchstwahrscheinlich bringt der Trick überhaupt nichts, aber dafür ist der Code schlechter zu lesen und zu warten.
    Um zu optimieren muss zuerst gemessen werden in welchem Teil am meisten Zeit verwendet wird. Im Normalfall ist das überhaupt nicht dort wo man es gefühlsmässig erwarten würde. Dann kann diese Stelle genauer angeschaut werden.

  13. Zwei Märchen halten sich recht hartnäckig: Bei den heutigen Compilern ist Programmoptimierung nicht mehr nötig, weil das der Compiler macht.
    Und C ist eine hardwarenahe Sprache.

    Es gibt ja Freaks, die compilierte Programme noch nachoptimieren. Eben weil der Compiler keine wirklich optimierten Programme erzeugt.

    Was ist denn an C so hardwarenah? Höchstens die Registervariablen. Und die sind praktisch nicht verwendbar, weil die in PCs verbauten Prozessoren zu wenig Register haben. Die paar vorhandenen sind schon vom System belegt, also nicht wirklich nutzbar. Damit bleibt von der Hardwarenähe nicht mehr als heiße Luft übrig.

  14. Moin,

    > Bei den heutigen Compilern ist Programmoptimierung nicht mehr nötig, weil das der Compiler macht.

    zumindest die Microoptimierung kann ein Compiler billiger. Insbesondere Fortran ist sehr gut im optimieren. Aber ein schlechter Algorithmus z.b Bubblesort wird damit nicht automatisch zu Quicksort.

    > Und C ist eine hardwarenahe Sprache.

    das ist wohl relativ zu sehen. C ist recht nahe an der PDP-11 Hardware, aber z.b. nicht so nah wie PL/360 am Mainframe. Pascal mit P-Code, Lisp oder Smalltalk sind recht weit von der Hardware entfernt, so lange ich keine speziellen CPUs dafür einsetze.

    > Dass alles langsamer wird hat nichts mit MS zu tun, auch Linux wird immer langsamer

    Warum Unix look likes langsamer werden ist recht gut in der Youtube Lecture zu sehen. Selbst wenn ich jetzt mal Bloatware wie Firefox oder OpenOffice aussen vor lasse, und Basics wie cat(1) und ls(1) vergleiche. Aber bei Firmen wie M$ oder damals IBM, die ein vitales Interesse am Verkauf neuer Hardware haben, unterstelle ich mal dass das Absicht ist.

    Bei Android finde ich interessant, dass Java mal als kleine Sprache zum erstellen portabler Benutzeroberflächen angefangen hat, um dann im Enterprise Server Bloat zu ersticken. Android macht einige Tricks die ermöglichen die selbe App, auf verschiedenen CPUs, in akzeptabler Zeit auszuführen.

    Aus der Sicht des ehemaligen Mainframe Programmierers kann ich nur sagen: Es macht nichts das Windows am Desktop die Marktdominanz hat. Der Desktop wird irgendwann genauso irrelevant wie heute die Lochkarte.

    ciao,Michael

  15. @Elendsoft: An C ist hauptsaechlich hardwarenah, dass man unter anderem direkten und linearen Zugriff auf grosse Speicherbereiche hat, und dieser auch fuer praktisch alle Operationen eingesetzt wird, ohne „Wrapper“ dazwischen (z.B. String-Operationen, Arrays, Linked Lists). Das ist natuerlich viel schneller, als wenn ich irgendwelche Abstrakten Objekte benutze wie z.B. Javascript Arrays/Objekte.

    Und natuerlich ueberhaupt die Tatsache, dass (praktisch?) alle C-Implementierungen Compiler sind. Was ist heute an Mainstream-Programmiersprachen noch wirklich kompiliert?

  16. Diesen direkten Zugriff auf Speicherbereiche hat jede vernünftige Programmiersprache, selbst Basic. Trotzdem würde niemand Basic als hardwarenah bezeichnen. Mit anderen Worten: C ist hardwarenah, weil es das hat, was andere Sprechen auch haben. Und die sind aus genau dem gleichen Grund nicht hardwarenah.

    Das ist ungefähr so wie mit der Toleranz in der Politik: Die anderen sind nicht tolerant, weil sie nur ihre eigene Meinung gelten lassen. Man selbst ist selbstverständlich tolerant, obwohl man auch nur seine eigene Meinung gelten läßt.

  17. @Elendsoft: Der Vergleich hinkt so, dass er praktisch schon umkippt. Ja, andere Programmiersprachen moegen auch direkten Speicherzugriff haben, aber in C *muss* man praktisch *alles* so machen, weil es keine anderen Moeglichkeiten gibt, und *deshalb* sind C-Programme in der Regel wesentlich (um Groessenordnungen) schneller als andere.

    z.B. gibt es fuer fast alle String-Funktionen (str*) ein Hardware-Aequivalent *direkt in der CPU*. Also braucht man wahrscheinlich nur ein paar Taktzyklen pro Stringoperation.

    In Hochsprachen wird der String erstmal 10 mal durch die Gegend kopiert, mit 20 Speicherzugriffen an unterschiedlichen Stellen, etc…

    OK, vielleicht habe ich mich falsch ausgedrueckt: Das ganze *Konzept* von C macht C schnell und hardwarenah.

  18. Bezüglich C und Hardwarenähe fallen mir noch die volatile-Variablen ein, die sich ändern können, ohne das der Prozessor das tut, weil sie die Steuer- /Statusregister von irgendwelcher Hardware abbilden. Die wird man hauptsächlich zur Entwicklung von Treibern brauchen, weil alles andere durch das BS blockiert wird, wenn sie tatsächlich Hardwareregister abbilden. Aber ich kenne keine andere Sprache ein, wo es so ein Konzept noch gibt.

    @Fabian: Das mit dem Codeprofiling ist natürlich richtig, aber wenn man die Stelle identifiziert hat, kann das was bringen. Ob es das tut, wird sich dann zeigen. Und natürlich bringt es wirklich nix, wenn der Algorithmus an sich lahm ist. Dennoch meine ich, dass man solche Tricks kennen sollte. Man muss es ja nicht übertreiben, wie im International Obfuscated C Code Contest.

  19. Was ich sagen will ist das der Compiler diese „Tricks“ massiv besser kann als ein Mensch. Microoptimierung ist etwas was ein Compiler viel einfacher/besser machen kann als ein Mensch.

    Viel wichtiger ist es zu wissen was ein Compiler nicht kann und dort (wenn nötig) zu optimieren. Z.B. ein Algorithmus mit Quadratischer Laufzeit mit einem mit Linearer Laufzeit zu ersetzten, die Daten so anordnen das häufiger die benötigten Daten schon im Cache sind und nicht langsam vom RAM nachgeladen werden müssen, Intrinsics einbauen damit der Compiler MMX, SSE, SSE2 verwendet etc. und so weiter. Das sind Änderungen die evtl. was bringen.

  20. > Ja, andere Programmiersprachen moegen auch direkten Speicherzugriff haben, aber in C *muss* man praktisch *alles* so machen, weil es keine anderen Moeglichkeiten gibt, und *deshalb* sind C-Programme in der Regel wesentlich (um Groessenordnungen) schneller als andere.

    Wenn die vorhandenen Möglichkeiten nicht genutzt werden, liegt das aber nicht an der Sprache, sondern am Programmierer.

    Wir haben mal einen kleinen Test gemacht: Ein kleines Programm zur Berechnung von Primzahlen in C , Delphi und Assembler. Ergebnis: C 9 ms, Delphi 8 und Assembler 0,3. Also was ist da um Größenordnungen schneller?

    > z.B. gibt es fuer fast alle String-Funktionen (str*) ein Hardware-Aequivalent *direkt in der CPU*. Also braucht man wahrscheinlich nur ein paar Taktzyklen pro Stringoperation.

    Du meinst DMA. Damit sind allerdings nur Stringtransporte möglich, keine Vergleiche oder Zeichensuche. Außerdem muß man dafür vorher wissen, wie lang der String ist. Um die Stringlänge zu ermitteln, muß bei C-Strings aber erst der gesamte String bis zum letzten Zeichen abgeklappert werden. Noch ineffizienter geht es wohl kaum.

    Die C-Strings sind also ein Musterbeispiel dafür, wie man es nicht machen sollte. Delphi macht es vor, wie es deutlich besser, schneller und sicherer geht. Und auch dort werden diese Hardware-Funktionen genutzt. Man sollte solche Behauptungen lieber erst überprüfen, statt immer der Werbung zu glauben.

    Und was die Code-Optimierung betrifft: Am besten ist es natürlich, wenn Mensch und Compiler optimieren. Das eine schließt ja das andere nicht aus.

  21. Da rächt es sich, wenn man am Wochenende nicht reinschaut. Ich weiß gar nicht, wo ich da anfangen soll. Also gut, zuerst Bernd: sehr guter Artikel, finde ich. Allerdings ist C#, soweit ich weiß, keine interpretierende Sprache.
    @alle anderen: was für Systeme programmiert ihr denn, dass C überhaupt noch ein Thema ist? Heutzutage kann man doch fast überall C plusplus einsetzen (die Kommentarfunktion verschluckt leider das doppelte Pluszeichen), das übrigens nicht generell langsamer als C ist. Ein leider immer noch verbreiteter Irrglaube. Dann muss man sich auch nicht mehr mit den C-Strings herumschlagen, sondern kann die Stringobjekte der Standarbibliothek nutzen.
    Welche Optimierungen Sinn machen, hängt immer vom System ab. Auf einem PC/Mac mit x86 würde ich kein inline-Assembler mehr nutzen. Das habe ich jahrelang getan, der Vorsprung gegenüber dem Compiler ist aber immer geringer geworden und lohnt sich heute nur noch in wenigen Ausnahmefällen. Dann muss ich aktuell einen Prozessor mit uraltem ARM-Core programmieren. Der hat noch nicht mal einen Maschinenbefehl für Division, und deshalb hat z.B. eine Division durch 3 durch Bitschiebereien zu ersetzen eine Verbesserung um Größenordnungen gebracht. Andererseits machen Bitshifts nicht die Spur Sinn, wenn man einen Prozessor hat, der eine kombinierte Multiplikation/Addition in einem Taktzyklus sogar mit Fließkomma schafft.
    @elendsoft: das C-Programm zur Primzahlenberechnung würde mich mal interessieren. Pragmatiker meinte übrigens nicht die DMA. Der x86 Befehlssatz enthält Befehle wie LODS, SCAS oder CMPS (Load String, Scan String, Compare String), die das sehr effizient erledigen.

  22. @Arne ich entwickle seit gut einem Jahr Software für einen uralt 16Bitter von Renesas (mit einem uralt Compiler von Tasking) Völlige Katastrophe… Zum Glück steigen wir bald auf ein ARM Cortex-R Derivat um.

    Java, C# etc. sind im ersten Durchgang meistens „interpretiert“. Der just-in-time compiler läuft häufig erst nach einer gewissen Anzahl von Wiederholungen an.

  23. Also ich melde mich auch mal. Ich finde in einem ist die Diskussion hier etwas abgeglitten. Es geht nicht um die Compiler und ihre Optimierungen und es geht auch nicht um C oder Assembler oder andere (compilierte) Programmiersprachen. Unbestreitbar gibt es da Unterschiede. Aber sie sind nicht die Welt. Mal ein extremes Beispiel: Delphi erzeugt bis zur Version 2010 nur 386 Code, die neue Version unterstützt nun auch die neuen Befehle die seitdem dazukamen. Ich habe mal nach einem Benschmark gesucht und das gefunden.
    http://delphitools.info/2011/09/02/first-look-at-xe2-floating-point-performance/
    Das Ergebnis: Assembler ist etwa 50% schneller als der neue Compiler und der alte (also noch 386 er Code, ohne SSE, MMX ….) auch nur 50% langsamer. Dieser Unterschied um den Faktor 2 ist wenn man dran denkt, dass sich die Rechengeschwindigkeit alle 2 Jahre verdoppelt vernachlässigbar und nicht für die Langsamheit die ich im Artikel angesprochen habe verantwortlich. Denn hier reden wir z.B. zwischen Windows 3 und 8 um einen Anstieg der Rechenleistung um den faktor 200-1000 und Windows 8 ist nicht so viel schneller….

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.