Wenn das so weitergeht, werde ich in diesem Sommer keine Sandalen ohne Socken tragen können: Bei jeder Installation unsinniger und übelst zusammen gestückelter Software (Teil meines Jobs), kräuseln sich meine Fußnägel. Irgendwann wird es zu viel sein. Bei dieser Arbeit mache ich mir manchmal schon Gedanken, wie viel Energie als Resultat der Anwendung solcher Software verschwendet wird. Meine Vermutung ist: Sehr viel im globalen Maßstab. Da kommt mir ein Artikel, wie der, den ich heute mal beschreiben mag, gerade recht. Aber Vorsicht, bei Messungen, die zeigen, was man sehen möchte!

Ganz zu Anfang dieses Blogs gab es einen – zugegeben eher oberflächlichen – Vergleich von Programmiersprachen. Das geht auch sehr viel fokussierter und eine Gruppe aus Portugal hat sich angeschaut, wie es um den Energieverbrauch bei Ausführung einer Reihe von Standardalgorithmen der Informatik bestellt ist[Pereira et al., 2021]. Hierzu wurden 10 gute Implementierungen verschiedener Algorithmen des Computer Language Benchmarks Games – eines Dauerwettbewerbs zum Vergleich von Programmiersprachen “laufen gelassen”, die Laufzeit und der Energieverbrauch gemessen. Die Autoren merken zurecht an, dass die Annahme der Energieverbrauch von Software wäre

Energy(J) = Power(W) \cdot Time(s)

, also das ein schneller laufender Code auch weniger Energie verbraucht, etwas naiv ist. Also haben sie direkt gemessen und das finde ich gut. Ein Problem der Autoren war, dass für einige Algorithmen noch nicht genügend viele Einsendungen gab, die den Qualitätskriterien entsprechen, weshalb beispielsweise Julia, eine Programmiersprache, die im wissenschaftlichen Programmieren immer mehr Boden gewinnt, nicht aufgezählt ist. Weniger gut finde ich für eine Publikation, die im Mai 2021 (also gewissermaßen jetzt) erschienen ist, dass nicht auf einem aktuellen System gemessen wurde:

All studies were conducted on a desktop with the following specifications: Linux Ubuntu Server 16.10 operating system, kernel version 4.8.0-22-generic,with 16GB of RAM, a Haswell Intel(R) Core(TM) i5-4460 CPU @ 3.20GHz.

Der fragliche Prozessor wird nicht mehr vertrieben, sein Befehlssatz ist nicht auf dem aktuellen Stand (was vielleicht daran liegt, dass die Ergebnisse älter sind als die Veröffentlichung). Damit werden sich die Energiewerte zu aktuellen Systemen unterscheiden, aber dies tut unter dem Strich den Aussagen der Veröffentlichung keinen Abbruch. Ich erspare hier die technischen Details und zeige mal das Gesamtergebnis:

Eigene Darstellung der normalisieren Resultate (mit “C” wurden die niedrigsten Verbrauchswerte gemessen (der Wert für C ist 1), alle anderen Resultate beziehen sich darauf und benötigen n-mal mehr als C) aus der oben genannten Veröffentlichung. Bitte beachtet die logarithmische Auftragung (Implementierungen mit Java benötigen im Mittel doppelt soviel Engergie wie solche, die in C geschrieben wurden. Lösungen mit Python oder Perl etwa 80 mal mehr.). Lizenz: CC-BY SA 4.0

Deutlich zu erkennen ist, dass Lösungen welche C, eine sehr systemnahe Sprache in der beispielsweise das Linux-Betriebssystem geschrieben ist, verwenden im Mittel die besten, also niedrigsten Energieverbrauchswerte aufweisen.

Wer schon mal etwas von Programmiersprachen gehört, dem fällt noch Etwas auf: Diese Liste führt einige auf, die man vielleicht gar nicht auf dem Schirm hatte. Andere fehlen vielleicht. Und in der Tat: Sie deckt sich nur teilweise mit den populärsten Sprachen (wie beispielsweise durch den Tiobe-Index ermittelt). Die wesentlichere Fragestellung sollte sein: Wie unterscheiden sich die Sprachen bezüglich ihres Energieverbrauchs bei den Aufgaben, zu denen tatsächlich eingesetzt werden? Gibt es in den Aufgabengruppen Alternativen, die man gut vergleichen kann? Denn klar: Man kann mit PHP, einer Skriptsprache für dynamische Webseiten, dazu nutzen randomisierte genetische Sequenzen auszuschreiben (einer der Tests) – in der Praxis wird das keine Aufgabe sein, der sich PHP-EntwicklerInnen gegenüber sehen. Und auch die “algorithmischen” Details der Aufgaben sind nicht, was üblicherweise die Laufzeit von PHP-Umgebungen dominiert. Ähnliches ließe sich über manch andere Kombination von Sprache und Testalgorithmus sagen.

Wir wissen, dass unsere Mobiltelefone eine gigantische Menge Strom verbrauchen und das Internet sowieso. Und so können wir zu der Frage kommen: Können wir substantiell Strom sparen, in dem wir bessere Software Software einsetzen, effizientere Bibliotheken, ggf. sogar in anderen Sprachen neu geschrieben? Mein Verdacht ist: Ja. Aber solch eine Arbeit ist allenfalls ein mittelgutes Indiz, da die ausgewählten Test wenig praxisrelevant sind – es ist ein Vergleich von Äpfeln und Birnen. Insofern verstehe ich den Mini-Hype, der sich u. a. auf jene Veröffentlichung beruft nicht.

Blick zu Scientific Computing

Nun, dies ist ein Wissenschaftsblog und der Energieverbrauch beim wissenschaftlichen Rechnen ist global schwer zu beziffern. Aber vielleicht können wir dennoch was aus der Veröffentlichung lernen. Denn eine große Universität kann hierzulande schon mal 1 Millionen Euro für Strom im Jahr allein für das wissenschaftliche Rechnen ausgeben – natürlich nicht bezogen von einem Ökostromanbieter zur Förderung der Energiewende. Hierbei könnte viel durch Einsatz wissenschaftlicher Großrechner gespart werden – anstelle der immer noch vorherrschenden arbeitsgruppeneigenen Server.

Nun gut, schauen wir uns die Sprachen an, die im wissenschaftlichen Rechnen verwendet werden (nein, liebe Computer-WissenschaftlerInnen, hier sind nicht die Sprachen gemeint, die ihr wissenschaftlich interessant findet, sondern die Sprachen, die – ohne das an dieser Stelle näher quantifizieren zu können – die meisten CPU-Stunden fressen im Einsatz bei den Naturwissenschaften):

 

Eigene Darstellung der aus der oben genannten Veröffentlichung. Herausgegriffen sind diejenigen Sprachen, welche am häufigsten verwendet dazu werden (natur-)wissenschaftliche Softwareprojekte zu realisieren – nach Einschätzung des Blogautors (hierbei ist Rust noch eher selten anzutreffen, gewinnt aber in den letzten Jahren an Boden). Lizenz: CC-BY SA 4.0

 

So, und jetzt sollen alle umweltbewussten WissenschaftlerInnen bitteschön nur noch C schreiben? Natürlich nicht! Die Forderung wäre naiv. Einige der Tests besitzen, wie gesagt, keinerlei praktische Relevanz und die aktuellen Entwicklungen bei Sprachen wie C++, Rust oder Julia sind performancemäßig atemberaubend. Vor allem aber:  Wenn man das Paper aufmerksam liest, stellt mach auch fest, dass es für einige der Algorithmen keine Implementierung in C gibt. Das hat seinen Grund: C ist vielleicht eine Sprache, die verspricht sehr effiziente Programme schreiben zu können – potentiell … möglicherweise. Aber auch eine Sprache in der die Umsetzung mancher Vorhaben einfach aufwendiger ist als bei anderen Sprachen. Außerdem kann man mit jeder Sprache auch langsamen Code schreiben. Hier, liebe mitlesenden InformatikerInnen geht es um ein Erwartungsmittel und da zeigt sich, dass die gewählten Sprachen bzgl. ihrer Geschwindigkeit in erster Näherung doch zu verhalten wie bzgl. ihrer hier gezeigten Effizienz[Prechelt, 2020]. Jede Programmiersprache hat bevorzugte Einsatzgebiete.

Andererseits hilft Nachdenken vor Beginn eines wissenschaftlichen Softwareprojektes weiter und dazu zählen auch Überlegungen wie die Folgende: Mit vielen Programmiersprachen kann man Numerik betreiben, aber Python ist beliebt und zugleich ist die Gefahr groß lahme Skripte zu schreiben, beispielsweise wird

for i in range(zillion):
    result = pi/2 * ... 

von Python auch eine “zillion”-Mal pi/2 berechnet (so gesehen mehrere Male, wobei die “Zillionen” irgendwo zwischen einer Millionen und Milliarden von Schleifendurchgängen ist). Besser wäre bei allen Skalaren, nicht nur Vielfachen von Pi, diese Division aus der Schleife heraus zu ziehen:

pi_2 = pi * 0.5

for i in range(zillion):
    result = pi_2 * ... 

. Dieser “Trick” wird ganz zu Anfang gelehrt, wenn man sich je mit Programmierung beschäftigt, ist völlig trivial und der Fehler wird doch immer wieder gemacht. Wir können uns also gut vorstellen, dass man langsame und ineffiziente Lösungen entwickeln kann. Bei anderen Sprachen sorgt möglicherweise der Compiler für Effizienz, weil er bemerkt, dass es sich da um eine quasi-Konstante handelt (obwohl der kleine Trick der Auslagerung auch bei anderen Sprachen gewiss nicht schadet). Und ja, man kann mit Cython von Python zu C übersetzen. Damit ist oft viel gewonnen, ohne großen Aufwand. Das übrige Buzzwordbingo rund um Bibliotheken, die das Eisen aus dem Feuer holen, sparen wir uns mal … Punkt ist: Augen auf bei der Sprachwahl, sonst ist die Wahrscheinlichkeit für die große und vergessliche Wissenschaftsmüllhalde zu schreiben sehr groß.

Mancher Mensch fühlt sich nach Kauf eines SUV gut. Andere überzeugen eine Arbeitsgruppe für ein zusammengepatchtes, überfrachtetes, speicherhungriges Java-Programm einen Serverboliden anzuschaffen – beides sind in gewissen Kreisen bedeutende Statussymbole. Man kann aber auch Freude daran finden, kleine schlanke Programme zu schreiben, die überall und ohne großen Aufwand zu installieren sind und ihre Arbeit zuverlässig erledigen.

Deshalb finde ich das zweite zitierte Paper wesentlich aussagekräftiger: Hier wurden insg. 80 Implentierungen für zwei Probleme verglichen für die Sprachen C, C++, Java, Python, Perl, Rexx (was nun wirklich kein Schwein mehr nutzt, oder?) und Tcl. Und wenn auch hier die Zahlenwerte durch alte Compiler, Pythonversionen etc. bereits Makulatur sind, obwohl die Veröffentlichung im letzten Jahr erschien, gibt es durch die Erfassung von Programm- bzw. Scriptlänge und Aufwand einige weitergehende Schlussfolgerungen:

  • Ein Programm in Perl, Python, Rexx oder Tcl zu schreiben braucht nicht halb soviel Zeit wie für die Alternative in C, C++ oder auch Java – und diese Programme sind auch nur halb so lang.
  • Ein typisches Scriptprogramm braucht etwa doppelt so viel Speicher wie ein C oder C++-Programm und mit Java sind es gleich 3-4 mal mehr Speicherbedarf.
  • Bei allen getesteten Programmen ist die Variabilität innerhalb der Lösungen mit einer Sprache größer als die Variabilität zwischen den Sprachen.

Also: Würde mehr Zeit in gute Programme investiert, könnten vielfach bessere, schnellere und sparsame wissenschaftliche Programme vorliegen – klingt trivial, aber ob das Bewusstsein dafür vorhanden ist? Davon abgesehen überlasse ich Lutz Prechelt, Autor des zweiten hier zitierten Papers das letzte Wort (Hervorhebung durch mich):

I advocate that more and larger studies are conducted along the lines of the one described here. Such work is necessary if we are to disperse the fog of vendor hype and programmers advocacy so that we can see each language’s strenghts, weaknesses, and pecularities more clearly. Acquiring such knowledge will help advance the state of software development overall.

flattr this!

Kommentare (48)

  1. #1 hwied
    3. Mai 2021

    C, Java und Pascal stammen noch aus einer Zeit, wo man den Speicherbedarf in kB gemessen hat. Der Programmierer hat auch darauf geachtet, unnötige Schleifendurchläufe zu vermeiden, if- Abfragen zu vermeiden, kurz, die Computer hatten noch wenig Speicher, das Programm wurde optimiert.
    Heute, wo man schon TB zur Verfügung hat ist das alles nicht mehr notwendig.
    Also, nicht nur das Programm bestimmt die Effezienz, auch der Programmierstil spielt eine Rolle

    • #2 Christian Meesters
      3. Mai 2021

      Heute, wo man schon TB zur Verfügung hat ist das alles nicht mehr notwendig.

      Wirklich? Genau diese Einstellung produziert speichergierige, langsame wissenschaftliche Software (und unwissenschaftliche auch).

  2. #3 Jens
    3. Mai 2021

    Was auch in diesen verteilten Zeiten immer noch extrem viel hilft – gerade auch wenn man es ggfs. mit einem Haufen Quelltext zu tun hat, den man vlt gar nicht so genau kennt – ist ein Profiler.

  3. #4 echt?
    3. Mai 2021

    Einfach mal die Energiesparoptionen am Rechner vernünftig einstellen. Die meiste Zeit laufen die Kisten doch im Leerlauf.

    • #5 Christian Meesters
      3. Mai 2021

      von den ~1500 Rechnern, die wir öffentlich betreiben (unter 1TB), warten gerade(zum Zeitpunkt des Schreibens) 3 auf Jobs, der kleine Rest ist stark beschäftigt (die mit >500GB sind alle beschäftigt). Das Problem unbeschäftigter Rechner kenne ich nur von AG-Rechnern, die angeschafft werden, dann starken Bedarf abfangen, aber für den Rest ihres Lebens Transistor-Däumchen drehen.

      Wissenschaftliches Rechnen im Hochleistungsrechnen != Wissenschaftliches Rechnen “in der Cloud” != Desktops != Server für wissenschaftliches Rechnen != Web-/DB-Server != etc.

      Das sind alles verschiedene Kapitel, sollte man nicht in einen Topf werfen.

  4. #6 Haju Reck
    Nürnberg
    3. Mai 2021

    Auch innerhalb C(++) liegen je nach Programmierer Welten. Ein Kollege (von Server/Datenbanken kommend) mußte lernen, auf einem Mikroprozessor ‘new’ oder ‘&member->Metode()’ zu vermeiden. Verbesserung um Faktor 14!

    • #7 Christian Meesters
      3. Mai 2021

      jau, das ist das problematische an solchen Benchmarks und um etwas zu paraphrasieren:

      “C/Python/Java make it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off.”

      Ursprünglich hat Stroustrup das ja nur zu C gesagt.

  5. #8 Spritkopf
    3. Mai 2021

    Früher (d. h. gaaanz früher in den 90ern, ohje, was bin ich schon alt) habe ich auch in C programmiert. Aber ganz ehrlich – zu diesen Zeiten möchte ich nicht zurück. Die Möglichkeiten objektorientierter Programmierung möchte ich nicht mehr missen. Die Programme sind strukturierter, einfacher zu verstehen und nach meinem Dafürhalten auch weniger buggy. C-Programme mögen weniger Energie verbrauchen, aber sie kosten deutlich mehr meiner Nerven, meiner Lebenszeit und natürlich damit auch mehr beim Kunden.

    Ich bin eher mit kommerzieller technischer Software in C++ unterwegs, nicht mit wissenschaftlicher Software, insofern weiß ich nicht, inwieweit meine Ansichten für diesen Artikel maßgeblich sind. Aber ich bin sicher, die “Lebenszeitabschätzung” wird auch im Wissenschaftsbetrieb vorgenommen.

  6. #9 cero
    3. Mai 2021

    Gibt es denn Untersuchungen zu der Aussage, dass es wirklich länger dauert in C++ ein Programm zu schreiben als in Python? Oder ist es nur schwieriger und es können weniger Menschen?

    Die meisten Unterschiede sind doch etwas das ein erfahrener C++-Programmierer im Vorbeigehen einfach mitschreibt, oder?

    • #10 Christian Meesters
      3. Mai 2021

      ja, siehe z. B. zweiter Paper-link. Aber ja, meine Erfahrung ist auch die (Achtung: vollkommen subjektiv), dass wenn man mal ‘ne Weile in einer komplexen Sprache wie C++ unterwegs ist, zügig Resultate erzielt werden können. Insofern @Spritkopf sehe ich das eben kritisch, dass so viel in der Wissenschaft auf Python und Perl gesetzt wird, bis es kracht: “Oh, unser Prototyp kann nicht mit 10G Input umgehen? Mal schnell Cython drüberbügeln. Dauer mit 100G zu lang? Mal schnell auf multiprocessing (Python) draufsetzen. Wie jetzt werden 100T gefordert? Oh, sorry …” (klingt übertrieben? Nee, ist aus dem Leben.)

      Die Lebenszeitabschätzung oder wissenschaftlich gesagt “time-to-paper” ist absolut gerechtfertigt. Nur beherrscht den Abwägungsprozess leider nicht Kenntnis, sondern Marketing und Hörensagen.

  7. #11 Joachim
    3. Mai 2021

    #4 und #6 haben absolut Recht (meiner Meinung nach).

    Klar ist auch das eine Scriptsprache / Interpreter deutlich mehr Energie brauchen. (weil der Interpreter viel mehr CPU-Befehle pro Rechnung durchführt)

    Octave z.B. kann trotzdem effizient sein, wenn man die internen Rechnungen z.B. zur Matrizenrechnung nutzt. Das kann schon mal fast an C ran kommen. Mit z.B. Schleifen aber wird Octave unterirdisch.

    Daraus folgt: große Berechnungen sollte ein guter Programmierer in C/C++, u.U Java, Julia usw programmieren. Kleine Dinge, die nicht oft laufen oder lang laufen, kann man scripten.

  8. #12 cero
    3. Mai 2021

    Ah, danke, ich habe nicht gesehen, dass in dem Paper auch Programmierzeit untersucht wurde. Der angegebene Task ist natürlich Stringverarbeitung, also genau das, wofür z.B. Python designt wurde. Da sehe ich auch ein, dass man dabei schneller ist. 🙂

  9. #13 strahlenbiologe
    3. Mai 2021

    Bei dem Thema fällt mir spontan eine sehr alte Geschichte ein. Du kennst ja wahrscheinlich BOINC und Distributed Computing. Ich war damals in einem solchen “Crunch-team” dass seine Rechner für wissenschaftliche Berechnungen bereitstellte. Eines der Projekte war Milkyway@home. Man lud sich kleine Dateien runter, sogenannte WorkUnits (WUs) die dann vom eigenen PC durchgerechnet wurden mit einem Programm dass von dem Projekt selbst geschrieben und bereitgestellt wurde. Eine solche WU brauchte zwischen 15h und 20h um auf einem damals aktuellen PC berechnet zu werden. Ein ein paar Teamkollegen schauten sich den Code des Programms an und fanden sehr schnell “Optimierungsmöglichkeiten”. Nach ein/zwei Tagen war die App um den Faktor 100 schneller, bei gleicher genauigkeit/ergebnissen. Statt 20h nur noch wenige Minuten Rechenzeit. Aus Jux haben die Jungs dass ganze dann noch auf die Grafikkarte ausgelagert ( war im jahr 2007-2008) und schon dauerte die Berechnung nur noch 1min oder weniger. Der damalige Teamleiter bei Milkyway@home lies aber auch noch den Rechencluster seiner Uni darauf los 😉 , die originalversion mit etlichen “Unsinnigkeiten” im Code.
    Ich will gar nicht wissen wie viel Energie durch den schlechten Code “verbrannt” wurde. ich muss mal schauen ob ich noch die alten Threats finde, ist vielleicht als abschreckendes beispiel ganz gut

    P.s.
    https://forum.planet3dnow.de/index.php?threads/soll-die-milkyway-app-ver%C3%B6ffentlicht-werden.350148/

  10. #14 Joachim
    3. Mai 2021

    “wirklich länger dauert in C++ ein Programm zu schreiben als in Python?”

    Die Vermutung, C++ zu programmieren würde länger dauern als Python, die ist in dieser Allgemeinheit Unsinn. Ich verwende 3-5 Sprachen dauernd und kenne wesentlich mehr.

    Ich wähle die Sprache nach den Anforderungen aus. Prototyp, GUI oder Shell, langlebiges Produkt usw. Für einen Script werfe ich nicht den Compiler an und nehme lieber Perl oder Python. Dieser Code darf “dreckig” sein. Build-Tools in Compilersprachen sind overhead, der lohnen muss.

    Je komplexer und größer es wird um so mehr tendiere ich zu C++ oder Java aus den selben Gründen wie Spritkopf #8 beschreibt.

    • #15 Christian Meesters
      3. Mai 2021

      Die Vermutung, C++ zu programmieren würde länger dauern als Python, die ist in dieser Allgemeinheit Unsinn.

      Nun, ich unterrichte beide Sprachen (für Nicht-Informatiker, wobei manchmal auch Leute aus den Computerwissenschaften im Kurs sitzen) und kann ebenso anekdotisch dagegen halten: Da ist was dran. – Das verlinkte Paper ist eines der besten aus diesem Bereich. Allerdings ist die Stichprobe klein. – Einige Themen in der Didaktik des Software-Engineering stehen nicht im Fokus der Wissenschaft. Da kann man sich lange streiten – oder versuchen hier und da Evidenz zusammen zu kratzen.

      Die Schlussfolgerungen in Ehren, der Beitrag widerspricht dem nicht nur nicht, er haut in dieselbe Kerbe. Das Python und R für eine kleine Auswertung mit ein paar Plots besser zu verwenden sind, als eine Java-Applikation, die es von Scratch zu schreiben gälte, hinterfragt hier niemand. Auch nicht, dass es für Interpretersprachen optimierte Bibliotheken gibt, die optimierten C/C++-Code nutzen.

  11. #16 Kurt
    3. Mai 2021

    Ich schätze die teuerste Sprache in jeglicher Hinsicht ist wohl JavaScript.
    Was da an Aufwand in Browser-Kompatibilität, Html- und CSS-Versionsünterstützung und Geräte(un)abhängigkeit gesteckt wird, habe ich noch in keiner anderen Umgebung gesehen. Nicht weniger schlecht steht es um die Tools rundherum. Und das alles nur um eigentlich zu 99% überflüssigen Code durchs Netz zu jagen.

  12. #17 Volker Birk
    https://blog.fdik.org
    3. Mai 2021

    Was mir bei Rust auffällt: wir haben die Erfahrung gemacht, dass der Compiler sehr viel Energie benötigt. Vielleicht sollte man noch Entwicklungszyklen und Compiler-Läufe mit beachten, um der Realität etwas näher zu kommen.

    Es liegt übrigens auch sehr am Programmierstil, und an der Fähigkeit der Entwickler, Probleme mit Algorithmen möglichst niedriger Komplexität zu lösen, was in der Praxis passiert.

    Was an Python interessant ist, wenn man es richtig anwendet: dann läuft der Code, der viele Zyklen und damit auch Energie verbraucht, in C.

    • #18 Christian Meesters
      4. Mai 2021

      Idealerweise (!) wird ein Programm ja entwickelt und dann einmal pro Release und System compiliert (zumindest in der HPC-Welt, anderswo werden andere Installer ausgerollt oder Pakete geschoben, die Binaries verteilen – aber egal) und damit ist dieser energetische Aufwand vernachlässigbar – oder auch nicht. Worauf ich hinaus will: Das Argument ist gut – aber die Größe ist quasi unmöglich zu bestimmen.

      Bzgl. Python und andere Interpreter: Das diese in C implementiert sind und wie, macht sie effizienter als ihre Vorgänger. Aber in Python ist alles ein (C-)Pythonobjekt. Fundamentale Typen? Fehlanzeige. Das ändert sich erst, wenn man mittels Cython compiliert und den Code anpasst (oder seine Numerik in Bibliotheken auslagert oder … oder … oder).

  13. #19 Volker Birk
    https://blog.fdik.org
    3. Mai 2021

    cero: bin beruflich Softwareentwickler. Aus der Praxis kann ich sagen: ja, in C++ dauert die Umsetzung eines Projektes um einiges länger als in Python. Allerdings gibt es Projekte, die eignen sich für Python nicht gut (Systemprogrammierung z.B.).

  14. #20 Dr. Webbaer
    4. Mai 2021

    Es ist halt so, dass IT-Anwendungen das leisten sollen, was angefordert war, insofern werden oft wie gemeint wenig (energie-)effiziente Sprachen genutzt, um i.p. Entwicklerarbeitszeit, die teuer ist, zu sparen.
    In einigen Grenzbereichen wird angeblich heute noch mit Assembler gearbeitet, in anderen noch mit altem und extrem wenig effizienten COBOL.

    Frage :
    Ist es so, dass wenig belastete CPUs heutzutage gezielt abschalten oder ihren Energiebedarf zurückfahren, nicht in Leerlaufprozessen verharren sozusagen, wenn es wenig zu tun gibt?

    • #21 Christian Meesters
      4. Mai 2021

      Es ist bis zu einem gewissen Grad möglich das zu tun.

  15. #22 Dr. Webbaer
    4. Mai 2021

    Auf die Schnelle konnte sich hier noch an “Energy Star” erinnert werden, vergleiche :

    -> https://en.wikipedia.org/wiki/Energy_Star#Specifications

    Dr. Webbaer selbst hat u.a. mit Java, Pascal, PHP und Perl (hüstel, auch einstmals mit COBOL) hantiert, war sicherlich nicht nur i.p. Energieverbrauch, sondern auch i.p. Laufzeit oft sehr ineffizient.

    Mit freundlichen Grüßen und Danke für die Freischaltung des kleinen Kommentars!
    Dr. Webbaer

  16. #23 Dr. Webbaer
    4. Mai 2021

    @ Kommentatorenfreund ‘cero’ :

    Einige verbocken es direkt so :

    -> https://de.wikipedia.org/wiki/Laufzeit_(Informatik)#Asymptotische_Laufzeit_von_Algorithmen

    Ausgebildete Mathematiker / Informatiker können hier idR zu Sparsamkeit anleiten.
    Derjenige, der Geschäftslogik oder wissenschaftliche Logik “eingießt”, will idR “nur”, dass korrekt gerechnet wird – wobei ausgelagerte sog, Läufe auch mehrere Stunden, auf dedizierten Rechnern, die zuvor Daten aus der Stammhaltung kopiert haben, auszuhalten sind.
    Nicht den gemeinen Geschäftsbetrieb aufhalten, sondern eben ausgelagert bearbeitet werden.

    An sich scheint es mir so, solange es nicht wie oben beschrieben verbockt wird, nicht so-o wichtig zu sein, in welcher Programmiersprache etwas formuliert ist.
    Kommentatorenfreund ‘Spritkopf’ konnte bspw. mit dieser Einschätzung hervorlugen :

    Aber ich bin sicher, die “Lebenszeitabschätzung” wird auch im Wissenschaftsbetrieb vorgenommen.

    MFG
    Wb (der sich nun langsam ausklinkt)

  17. #24 Joachim
    4. Mai 2021

    @Christian Meesters #18
    So ganz verstehe ich die Argumentation (rein technisch) nicht.

    “Idealerweise (!) wird ein Programm ja entwickelt und dann einmal pro Release und System compiliert”

    Bitte nicht Ci, große IDEs, tausende Debug/Tests-Sessions usw. vergessen. Für Ci z.B. wird bei jedem commit in den Masterbranch ein Docker-Container mit der Testumgebung geladen/generiert und ausgeführt. Der Overhead ist massiv. Das gilt besonders, wenn der Kram in der Cloud geschieht.

    “Bzgl. Python und andere Interpreter: Das diese in C implementiert sind und wie, macht sie effizienter als ihre Vorgänger.”

    Ich kenne nur wenige Sprachen, die nicht in C/C++ implementiert sind. Und davor wurde in Assember oder Fortran programmiert. Wieso macht C Python effizienter? Und was ist der Vorgänger, der nicht in C programmiert war?

    Nebenbei, heute ist die Implementierung-Sprache sekundär. Viel wichtiger sind JIT, ggF. die VM, die Algorithmen der Sprache selbst, die der Sprachumgebung und die der “Libs”.

    Noch eine Anmerkung: es gibt keinen Grund, warum ein moderner Cobol-Compiler nicht effizient sein sollte.

    • #25 Christian Meesters
      4. Mai 2021

      Bitte nicht Ci, …

      Ja, absolut. Das ist mit einer der Gründe, warum das Paper zu kurz zielt. Kennt jemand umfassendere Arbeiten? Mit Wichtung aktueller CI-Setups, Laufzeit- und Projektlaufzeit-Wichtung? Ich nicht. Bin aber interessiert an Mosaiksteinen. Mehr ist das zitierte Paper eben auch nicht.

      Ich kenne nur wenige Sprachen, die nicht in C/C++ implementiert sind. …

      Jau, ich dachte eher an Pythons Anfänge – da war Python rel. flott und schlank im Layout – im Vergleich zu den damaligen Alternativen(, weil einige der Designentscheidungen anderen Sprachen nicht wiederholt wurden (das ist das “wie) und da war nicht alles mit C-Hintergrund – aber das führt zu nichts, mein Kommentar ist missverständlich: Punkt ist “ist in C implementiert” bedeutet nicht, der der Interpreteroverhead verschwindet). Glaube, da sind wir – Missverständnisse durch kurze und stumpfe Formulierung nicht wegreden wollend – gar nicht so verschieden von der Betrachtung.

  18. #26 UMa
    4. Mai 2021

    Ich vermute die Rechenzeit rechenintensiver Probleme ist nahezu unabhängig von der Geschwindigkeit des verwendeten Computers, von der verwendeten Programmiersprache und vielleicht sogar von der Effizienz des Codes. Es wird immer so lange gerechnet, wie zeitlich gerade noch verkraftbar ist.

    Als ich einen rechenintensiven Code von einer Scriptsprache in C++ umgesetzt hatte, lief das 100 mal schneller.
    Ergebnis: Nun löse ich 100 mal so große Probleme in etwa der gleichen Zeit.

  19. #27 Christian Berger
    4. Mai 2021

    Das ist irgendwie nicht wirklich überraschend. Übrigens sollte man C und C++ unterscheiden. C++ ist sehr überkomplex und hat einige halbgare Abstraktionsfeatures welche nur so halb funktionieren.

    C ist hingegen eher eine Art “portabler Makroassembler”. Man hat eine minimale Menge an Abstraktion welche meistens nicht stört und besonders nicht die Sicherheitsprobleme verdeckt.

    Was ich mich aber eigentlich frage, wo sind da die typischen “Numbercruncher” wie FORTRAN?

    • #28 Christian Meesters
      4. Mai 2021

      Wie bitte? (WordPress braucht eine Ironie-Auto-Detection!11!!)

  20. #29 Joachim
    4. Mai 2021

    @Christian Berger #26
    Das ist nicht korrekt. Es ist möglich C Programme mit C++ Compilern zu übersetzen. Und wenn man dann noch C++ Features (OO, STL) einsetzt, dann sind die (mathematisch beweisbar und genau quantifizierbar!) effizient, in der Regel weniger aufwändig und besser als “selbstgebastelt” in C.

    Wer aber falsche Abstraktionen (z.B. map statt array) verwendet, muss sich nicht wundern, wenn sein Programm langsam wird.

    In der Hand eines Fachmanns ist C++ eine der effektivsten Sprachen die existieren. OO ist definitiv nicht langsamer, als Fortran. Auch das ist beweisbar.

    IRONIE jetzt:
    Ein anständiger Programmierer programmiert in jeder Sprache Fortran.

  21. #30 Christian Berger
    4. Mai 2021

    @Joachim #29
    Die Compiler mögen kompatibel sein, aber es ist ein Unterschied ob man C oder C++ programmiert. Wobei wenn man sich mal den Stroustrup zynisch durchließt könnte man meinen, die “richtige” Art C++ zu programmieren wäre alle C++ Features zu vergessen und einfach C zu schreiben. 🙂

    Das Problem an C++ ist auch, dass es sehr wenig Leute gibt die die Sprache vollständig beherrschen, dafür ist sie einfach viel zu komplex. Meistens kann in einem Team jeder nur ein kleines Subset davon. Nicht immer ist die Überlappung der Subsets groß genug um noch irgendwelche große Vorteile gegenüber C zu bringen.

    Viele Features sind kein Zeichen für eine besonders “gute” Sprache. Meistens ist da weniger mehr. Auch Objektorientierung im C++-Stil ist zwar für einige Dinge ganz nützlich (z.Bsp. GUIs), kann aber auch einfache Probleme unnötig kompliziert machen.

    • #31 Christian Meesters
      4. Mai 2021

      ok, mal ernsthaft: Die C++-STL kann man in einem Einführungskurs (1 Woche Vollzeit) vermitteln, inkl. der wichtigsten Sprachfeatures (auch der aktuellen). Danach muss man am Ball bleiben (eine Empfehlung: intermediate & advanced).

      Ist das bei anderen Sprachen anders? Ok, vielleicht fallen mir ein paar ein (D z. B. – aber das ist keine attraktive Sprache für mich).

      C++ ist sehr überkomplex und hat einige halbgare Abstraktionsfeatures welche nur so halb funktionieren.

      Das finde ich die steilste Behauptung. Vielleicht hat mal der eine oder andere Compiler mit einem Standardupdate ein Bug produziert? Das kam vor, das sind aber Compilerbugs bei noch experimentellen Features gewesen. Aktuelle “Standardcompiler” (gcc|Intel|clang – PGI weiß ich nicht) kommen mit aktuellem C++ gut zurecht.

      Es ist möglich C Programme mit C++ Compilern zu übersetzen. Und wenn man dann noch C++ Features (OO, STL) einsetzt, dann sind die (mathematisch beweisbar und genau quantifizierbar!) effizient, in der Regel weniger aufwändig und besser als “selbstgebastelt” in C.

      von @Joachim sehe ich ganz genau so und könnte man auch mit Quellen versehen. Die Gegenbehauptung auch?

      Wir hatten auch das Stichwort “Profiling” zur Performanceoptimierung. (Ja, auch das kostet Energie.) Lohnt sich ggf. auch – wenn manche Software (denke immer eher im wissenschaftlichen Bereich) viele Millionen CPUh im produktiven Einsatz akkumuliert, ist Profiling und Optimierung wohl investierte Zeit.

  22. #32 Joachim
    4. Mai 2021

    Vorweg, es ist mir ein wenig peinlich hier C++ verteidigen zu müssen. Gerade ich! Ich sehe die “Probleme” solcher Sprachen ganz irgendwo anders, so das dies ein “Streit um Kaisers Bart” ist. Aber was über c++ falsch ist, das wird auch durch Wiederholung nicht richtig. Deshalb die zu viel lange Begründung jetzt um dies mal klarzustellen:

    Die C++ Nutzung “krankt” daran, das Leute Coroutinen, Lambda-Ausdrücke, Templates, Semaphoren und generell die Konzepte und Garantien der Algorithmen der STL nicht kennen. Hat hier die Sprache das Problem? Oder der unbedarfte Programmierer?

    Einige Dinge halte ich auch für diskussionswürdig (was die “Macher” ausgiebig getan haben!). Attribute z.B. (sowas wie [[nodiscard]]), die nichts zum Code beitragen und teilw. mit Sicherheit begründet werden. Ich brauche auch mal nicht. Denn es gibt vorher ein Konzept, einen Prototypen und kleinteilige Tests. Wenn ich (stark vereinfacht) eine Lib machen würde, dann sähe das aber ganz anders aus.

    Ja, man braucht nicht alle Sprachfeatures von C++. Jedenfalls nicht immer. Aber immer öfter. Ja, manchmal geht das auch in anderen Sprachen “einfacher”. Closures z.B sind in andern Sprachen schon uralt, vollkommen normal, unbemerkt automatisch da wenn man sie braucht.

    Doch ohne die ganzen Bimmels und Glöcken wäre die Sprache (aus praktischer Sicht erfahrener Entwickler) nicht vollständig. Und es ist alles noch gerade so im Sinn von C++.

    Und der ist: erlaube dem Compiler möglichst alles zu entfernen. Erzeuge den effektivsten Code, der möglich ist, bei maximaler Ausdrucksstärke und Logik. Darüber ist massiv gestritten und nachgedacht worden! C++ ist ein absolutes Profi-Tool, ein Formel 1 Rennwagen mit Werkzeugflansch. Wer damit aus der Kurve fliegt, der hat sich überschätzt. Wie gesagt, C++ kann auch C. Das muss also nicht sein. Nur warum entscheiden das die Meckerer für mich? Warum sollte ich mich beschränken, nur weil die nicht klar kommen?

    Wer Smalltalk will, der soll eben Smalltalk nehmen. Oder Clos oder funktional Haskell. Nicht? Dann Ruby, Lua, Julia, Java, im Notfall C# mit .NET? Auch nicht? Okay, go ist überflüssig (aber warum nicht?), Rust nicht schlecht aber (egal, vieles ist sehr gut, wird vielleicht mal die sichere(?) Alternative zu c++), dann eben Python oder VB. Oh, VB war jetzt fast zu böse. Selbst dafür gibt es einen Platz irgendwo. Warum habe ich diese Liste wohl so lang gemacht? Und warum ist die zu kurz?

    Wo ordnest du dich denn ein? Und was verlangt dein Projekt? Oder gar dein Chef, auch wenn das nun schon mal gar kein Argument ist.

    Sprachenstreit ist Unsinn! Es braucht objektive Begründung und ein wenig Erfahrung um die richtige Sprache für ein Projekt auszuwählen. “Ich kann nicht” ist im Profibereich ein sehr schwaches Argument, sagt aber auch gar nichts über die Sprache aus. Wenn man nur einen Hammer hat, dann sieht eben alles wie ein Nagel aus. Aber dann mecker niemand über Effektivität!

    (Ironie: und morgen schreibe ich ein Buch. Will dann auch niemand lesen)

    • #33 Christian Meesters
      5. Mai 2021

      Sprachenstreit ist Unsinn! Es braucht objektive Begründung und ein wenig Erfahrung um die richtige Sprache für ein Projekt auszuwählen. “Ich kann nicht” ist im Profibereich ein sehr schwaches Argument, sagt aber auch gar nichts über die Sprache aus. Wenn man nur einen Hammer hat, dann sieht eben alles wie ein Nagel aus. Aber dann mecker niemand über Effektivität!

      Sehe ich auch so – mein Ziel war eher den Stand der Information darzustellen und eine Überlegung zu triggern. Leider spielt “Ich-kann-nicht” meiner Erfahrung nach (hier im Blog schon mehrfach belegt) im Abwägungsprozess bei wissenschaftlichen(!) Projekten durchaus eine Rolle.

  23. #34 The One
    5. Mai 2021

    @ Christian Meesters & all
    Die Fragestellung lautet “Die Energie-Effizienz von Programmiersprachen”. Es geht also um den Energieverbrauch. Damit wird ein Zusammenhang mit dem Themenbereich Energieeinsparung hergestellt und damit wiederum zum Thema Energiewende und natürlich auch Klimaerwärumung und seine Bekämpfung.
    Hr. Meesters spielt damit auf das generellere Thema IT und Energieverbrauch an. Was kann damit gemeint sein. Das auf einem offline laufende Computer Programm oder genereller das global vernetzte und verfügbare Programm und seine Dienste?
    Tatsache ist, daß das globale Netz erheblich zum Energieverbrauch beiträgt. Treiber hierfür sind jedoch vorallem Streamingdienste und nicht ineffiziente Programme. Streamingdienste bedienen sich Rechenzentren. Es wäre wohl besser Rechenzentren und deren Energieverbrauch oder gleich die Streamingdienste ins Visier zu nehmen.
    Die ganze Diskussion hier mutet etwas seltsam an. Die Energie-Effizienz von Programmiersprachen liegt da bestenfalls am vorletzten Platz. Wenn es schon sein muß, egal wie sinnfrei es ist, C++ auf Meisterlevel (den Master spare ich mir wegen dem impliziten Slave) ist die erste Wahl.

  24. #35 echt?
    5. Mai 2021

    Vielleicht könnte man ja auch eine Sprache kontinuierlich weiter entwickeln, anstatt so oft eine neue Sau durchs Dorf zu jagen. Energie ist ja relativ billig, Arbeitszeit nicht so.

    Man muss sich ja nicht nur in eine neue Sprache einarbeiten, was Zeit erfordert, sondern auch der Entwicklungsaufwand steigt wegen der produzierten Fehler. Dazu steigt auch noch das Risiko an, Bugs in der Software zu haben und uraltes Templerwissen aus Libraries geht auch verloren.

    • #36 Christian Meesters
      5. Mai 2021

      Vielleicht könnte man ja auch eine Sprache kontinuierlich weiter entwickeln, anstatt so oft eine neue Sau durchs Dorf zu jagen. Energie ist ja relativ billig, Arbeitszeit nicht so.

      So was findet ja auch statt, klang hier auch auch an und im Blogartikel ist ja auch kritisiert, dass man schlechterdings nicht hingehen kann und veraltete Compiler, Sprachversionen und Rechner ergebnisweise auf den Ist-Zustand extrapoliert. Manchmal ist Wissenschaft langsam …

  25. #37 hwied
    5. Mai 2021

    Effezienz ist gut, Für den Programmierer sind andere Argumente wichtiger.
    Kann man mit dem Befehlssatz eine Aufgabe schnell und elegant lösen. Brauche ich eine Compilersprache oder reicht eine Scriptsprache.
    Javascript rechnet intern bis 10 hoch minus 15. Wenn das nicht ausreicht, dann muss ich zu Java greifen oder VB.
    Welcher Programmierer wird eine neue Sprache lernen, weil sie effektiver ist ? Hat er die Zeit dazu?

  26. #38 Joachim
    5. Mai 2021

    @hwied: ich sehe ja deinen Punkt. Aber hier mal was aus dem Nähkästchen:

    Das wichtigste Argument für Programmierer ist, es nicht zu verkacken. Wenn das gelingt ist der zweite Punkt Pseudo-Effizienz wegen der “Benutzererfahrung”. Selbst wenn die Funktionalität leidet muss alles Blitzartig wirken und fancy sein. Weil das ist, was der Benutzer sieht. Und dann kauft der.

    Der Zahlenbereich ist überhaupt kein Argument (JS hat sowieso mit Number 64Bit double float). Jede Krücke im Programm, jede Codereplizierung, jeder dreckige Trick wird gemacht, auch wenn mit nur minimaler Überlegung alles sauber wäre. Ich habe noch nie jemanden überzeugen können, warum seine Lieblingssprache in diesem Fall vielleicht nicht die beste Wahl ist. Im Gegenteil. Was habe ich mir schon anhören müssen, wenn ich in einem größeren verteiltem Projekt vier Sprachen (oh falsch 5 und die fünfte habe ich selbst implementiert) verwendet habe. “Das könne doch niemand nachvollziehen”.

    Ist das so? Ich habe schon mehr als 1000 Zeilen Code eben von diesen Leuten auf 10 und ein paar Zeilen geschrumpft. Nicht aus Spaß oder um die zu ärgern. Der Grund war, dass es nicht funktionierte… Und das ist ganz sicher kein Einzelfall.

    • #39 Christian Meesters
      5. Mai 2021

      Ich wollte mich fragen, soll ich das überhaupt noch kommentieren? Und dann war der erste Impuls: Aber es geht um wissenschaftliches Programmieren (wg. “kaufen”) und dann dachte ich bei

      Was habe ich mir schon anhören müssen, wenn ich in einem größeren verteiltem Projekt vier Sprachen (oh falsch 5 und die fünfte habe ich selbst implementiert) verwendet habe. “Das könne doch niemand nachvollziehen”.

      Ist das so? Ich habe schon mehr als 1000 Zeilen Code eben von diesen Leuten auf 10 und ein paar Zeilen geschrumpft. Nicht aus Spaß oder um die zu ärgern. Der Grund war, dass es nicht funktionierte… Und das ist ganz sicher kein Einzelfall.

      : So isses. So isses.

  27. #40 Joachim
    5. Mai 2021

    @hwied und Andere: ich wollte dich ganz sicher nicht angreifen! Ich gehe davon aus, dass hier Niemand dümmer ist als ich. Nur jünger vielleicht 😉

    @Christian Meesters: Nach diesem Rant, den ich schon löschen wollte kommt das unerwartet. Dankeschön, nicht nur dafür!

    Immerhin, so ganz off topic war das nicht, wenn es um Ursachen für Energieverbrauch geht.

    Und UNI’s (Physik/E-Technik, Mathematik, Informatik) sind mir nicht fremd. Deshalb mein Interesse für diesem Blog.

    (Und jetzt halte ich mal den Mund)

  28. #41 Dr. Webbaer
    6. Mai 2021

    Nur am Rande i.p. Energieverbrauch webverwiesen :

    -> https://www.pcwelt.de/news/Porno-Seiten_machen_30_Prozent_des_gesamten_Internet-Traffics_aus_-Studie-7893410.html (2013, es gab auch Schätzungen, die in den 70%-Bereich gingen, audiovisuelles Material benötigt für seine Verbreitung im Web offensichtlich viel Energie)

    Im Internet ist es zudem so, dass auf den Webservern (fortlaufend und sehr viele) Prozesse laufen, die nutzerspezifischen Inhalt generieren, dabei auf große Datenbasen, auf RDBMSe zurückgreifen, auf Dateisysteme mit vi-ielen Dateien, die sehr gerne besonders effizient sein dürfen, wenn die Ausführungsgeschwindigkeit (vs. Energieverbrauch, das eine hängt aber irgendwie mit dem anderen zusammen) gemeint ist.

    Es überrascht insofern womöglich ein wenig, wenn im Web Programmiersprachen genutzt werden, die wenig energieeffizient sind, was wohl daran liegt, dass genau diese Sprachen mit (den benötigten) Frameworks für den Webgebrauch kommen.

  29. #42 Volker Birk
    https://blog.fdik.org
    6. Mai 2021

    Ich finde die Diskussion noch etwas zu abstrakt. Hat jemand mal Implementierungen von echten Anwendungen verglichen, sagen wir mal, einmal mit SciPy/Python, einmal mit gängigen C++-Implementierungen?

    Dabei wären sowohl der Energieverbrauch als auch der Aufwand und vor allem auch der Pflegeaufwand interessant zu wissen.

    “Ich hab hier eine gute C-Implementierung eines Algos, das kriegst Du in Python nicht gleich schnell hin” ist ja immer noch wenig praxisrelevant.

    • #43 Christian Meesters
      6. Mai 2021

      Eine wissenschaftliche Veröffentlichung zu der Frage ist mir nicht bekannt. Aber ich sehe jeden Tag, dass Projekte deren Algebrabibliotheken unmittelbar auf Metis/(Open)Blas/ScaLapack setzen, die hochskalierbaren, lang gewarteten und viel zitierten Anwendungen. Während Projekte, die auf numpy/scipy-setzen (die ihrerseits teils auf blas/mkl/(Sca)Lapack setzen) z. T. gar keine Veröffentlichungen ihrer Software hervorbringen, oft schlecht gewartet sind oder – am häufigsten – nach dem x-sten Flansch auf ihre Software unglaublich umständlich zu installieren sind und irgendwann im Orkus der Wissenschaft verschwinden.

      “Ich hab hier eine gute C-Implementierung eines Algos, das kriegst Du in Python nicht gleich schnell hin” ist ja immer noch wenig praxisrelevant.

      Das genau ist die Mähr – schreibt jemand der auf den ersten EuroScipy-Konferenzen war, Python unterrichtet und gerne wieder zur nächsten EuroScipy fahren möchte. Die Einfachkeit führt nicht selten zu schlechter Architektur und wird von Projekten gewählt, die ein proof-of-concept programmieren und gar nicht auf langlebige performante Software ausgerichtet sind.

      Ist das alles belegbar? Ja. Habe ich das mal erfasst und in Zahlen gegossen oder sonst jemand? Nein – obschon ein paar der Blogartikel Material enthält, dass diese Aussagen stützt.

  30. #44 Dr. Webbaer
    6. Mai 2021

    @ “The One” :

    Tatsache ist, daß das globale Netz erheblich zum Energieverbrauch beiträgt. Treiber hierfür sind jedoch vorallem Streamingdienste und nicht ineffiziente Programme. Streamingdienste bedienen sich Rechenzentren. Es wäre wohl besser Rechenzentren und deren Energieverbrauch oder gleich die Streamingdienste ins Visier zu nehmen.
    Die ganze Diskussion hier mutet etwas seltsam an. Die Energie-Effizienz von Programmiersprachen liegt da bestenfalls am vorletzten Platz.

    Aja, wer ist auf dem letzten Platz?

    Ansonsten darf sich womöglich hier durchgearbeitet, druch-gequält werden :

    -> https://en.wikipedia.org/wiki/List_of_CPU_power_dissipation_figures

    -> https://de.wikipedia.org/wiki/Thermal_Design_Power

    -> https://www.quarks.de/technik/energie/so-viel-energie-verbraucht-das-internet/ (2014, ergo ‘Eine Studie aus 2014 hat errechnet, dass das Internet 2012 4,6 Prozent des weltweiten Stromverbrauchs ausgemacht hat.’)

    Mit freundlichen Grüßen
    Dr. Webbaer

  31. #45 Dr. Webbaer
    6. Mai 2021

    Es geht bei der Software-Entwicklung idR um Einfachheit, um gut pflegbaren und weiterentwicklungsfähigen, auch so : dokumentierten Code, und um Schnittstellen zum Abnehmer, der rollenverteilt letztlich der Sponsor, der Geldgeber so gemeinter Entwicklung ist, insofern i.p. Rolle auch eine bestimmte Kraft benötigt, um ihn zu befriedigen zu suchen.

    Was hier hilft, auf Entwicklerseite, sind solide mathematische Kenntnisse und Kenntnisse im Ingenieurswesen.
    Dr. W hat schon gute Studenten des Ingenieurswesen, abär auch gute Geisteswissenschaftler, nicht selten Philosophen, kennengelernt, die i.p. SW-Entwicklung leisten konnten, bei der Dokumentation, bei der Bearbeitung der Anforderungslage wie auch im Sozialen (siehe oben und Abnehmerzufriedenheit meinend).

    (Tatsächlich leisten IT-Teams i.p. SW-Entwicklung und auch ein wenig i.p. Sozialarbeit sozusagen.)

    Zudem geht alles schief, was schief gehen kann, Murphy’s Law, insofern sind auch robuste, defensive (vs. offensive) Personen gefragt, wie gemeint.

    Aber die effing Energieeffizienz spielte hier nie hinein, sondern nur wirtschaftliche, wie auch system-philosophische Überlegung.

    Zudem ja auch, gerade i.p. Rechenleistung, sozusagen alles billiger wird.

    • #46 Christian Meesters
      6. Mai 2021

      Zudem ja auch, gerade i.p. Rechenleistung, sozusagen alles billiger wird.

      Also Verschwendung als inverser Rebound-Effekt? Das Effizienzgedanken nur in kleinen Entwickler-Communities überhaupt eine Rolle spielen ist absolut unbestritten.

  32. #47 Dr. Webbaer
    6. Mai 2021

    Wird die Nutzung eines Produkts kostenschonender, auf Käuferseite, wird es mehr genutzt und insofern wird so ein sog. ‘Rebound-Effect’ möglich.
    Der aber abgemildert werden kann dadurch, dass die Gesamtkosten dennoch unter den zuvor üblichen liegen können. (Dr. Webbaer hat auch insofern weiter oben “Watt-Zahlen” von CPUs webverwiesen.)

    Insgesamt ist es aus diesseitiger Sicht aber so, dass das Web zunehmenden Energieverbrauch bedingt und aus dieser Spirale sozusagen, trotz bekannter die Energie meinendem Leistungsanspruch nicht heraus gekommen werden kann.
    Wenn erst mal “alle mit allen” verbunden sind.

    Es schert sich auch niemand in den sog. Developing Countries um Energieverbrauch, dort liegen andere Herausforderugen vor.

    MFG
    Wb

  33. #48 hwied
    6. Mai 2021

    Wenn man nur auf die Programmiersprache schaut , dann vergisst man schnell, dass aller Strom durch die Steckdose kommt und zwar mit 230 V. Und die computer arbeiten mit 20 V. Also braucht man Netzteile.
    Und bei denen gibt es riesige Unterschiede. Ein sehr gutes Netzteil hat einen Wirkungsgrad von bis zu 90 %. Gute Netzteile erreichen 80 %, Billignetzteile liegen bei 60 % und darunter.
    Wer also einen low budget Computer kauft, der kann gut 30 % mehr Strom verbrauchen, bei gleicher Auslastung der CPU.