1. Foren
  2. Kommentare
  3. Wissenschaft
  4. Alle Kommentare zum Artikel
  5. › Moore's Law: Totgesagte…

Wenn die CPUs mal nicht mehr schneller werden ...

Über PC-Games lässt sich am besten ohne nerviges Gedöns oder Flamewar labern! Dafür gibt's den Freiraum!
  1. Thema

Neues Thema Ansicht wechseln


  1. Wenn die CPUs mal nicht mehr schneller werden ...

    Autor: Bonita.M 24.10.14 - 17:01

    ... dann lernen die meisten Entwickler wie man effizient programmiert.

  2. Re: Wenn die CPUs mal nicht mehr schneller werden ...

    Autor: Quantium40 24.10.14 - 23:32

    Bonita.M schrieb:
    --------------------------------------------------------------------------------
    > ... dann lernen die meisten Entwickler wie man effizient programmiert.

    Nein. Dann nimmt man einfach wieder mehr CPUs oder hofft darauf, dass der Compiler das erledigt (wie gut das heutzutage schon geht kann man beispielhaft in der c't 12/2014 im Artikel "Matrix reloaded" von Andreas Stiller nachlesen).

    Effizient programmiert wird in der Regel nur im Sinne der Effizienz aus Sicht des Softwareherstellers. Ausnahmen finden sich praktisch nur dann, wenn bessere Programmeffizienz durch den Wettbewerb erzwungen wird.

  3. Re: Wenn die CPUs mal nicht mehr schneller werden ...

    Autor: Anonymer Nutzer 25.10.14 - 05:49

    Bonita.M schrieb:
    --------------------------------------------------------------------------------
    > ... dann lernen die meisten Entwickler wie man effizient programmiert.


    Dafür gibts den Raspbeπy und Millionen andere Entwickler Boards.
    Die"Schnell & einfach/C & UNIX Coding Philosophie" hatte nach Heartbleed nochmal einen ziemlichen Shellshock.
    Wenn die Leistung da ist,dann sollte man versuchen Effizienz durch Stabilität zu erreichen.
    Ansonsten hat man irgendwann vielleicht das Problem, dass einem die ganze Suppe effizient um die Ohren fliegt.

  4. Re: Wenn die CPUs mal nicht mehr schneller werden ...

    Autor: Bonita.M 25.10.14 - 13:47

    > Nein. Dann nimmt man einfach wieder mehr CPUs ...

    "Einfach" - glaubst Du das parallele Programmierung immer "einfach" ist?

    > ... oder hofft darauf, dass der Compiler das erledigt (wie gut das heutzutage
    > schon geht kann man beispielhaft in der c't 12/2014 im Artikel "Matrix
    > reloaded" von Andreas Stiller nachlesen).

    Das geht überhauptnicht gut. Die Compiler können nur Lowlevel-Optimierungen.

  5. Re: Wenn die CPUs mal nicht mehr schneller werden ...

    Autor: Bonita.M 25.10.14 - 13:50

    > Die"Schnell & einfach/C & UNIX Coding Philosophie" hatte nach Heartbleed
    > nochmal einen ziemlichen Shellshock.

    C ist eben nicht schnell und einfach, sondern detailreich und aufwändig.
    Schnell und einfach ist eher Java.

    > Wenn die Leistung da ist,dann sollte man versuchen Effizienz durch
    > Stabilität zu erreichen.

    Was für ein Blödsinn. Das eine hat mit dem anderen nichts zu tun.

  6. Re: Wenn die CPUs mal nicht mehr schneller werden ...

    Autor: plutoniumsulfat 25.10.14 - 15:51

    Java war jetzt nicht das beste Beispiel :D

  7. Re: Wenn die CPUs mal nicht mehr schneller werden ...

    Autor: The_Soap92 25.10.14 - 19:16

    Bonita.M schrieb:
    --------------------------------------------------------------------------------

    > Schnell und einfach ist eher Java.

    Hast du noch mehr Witze auf Lager?

  8. Re: Wenn die CPUs mal nicht mehr schneller werden ...

    Autor: Bonita.M 25.10.14 - 20:17

    > > Schnell und einfach ist eher Java.
    >
    > Hast du noch mehr Witze auf Lager?

    Ich meine nicht schnell im Sinne von performant, sondern im Sinne des Entwicklungs-Turnarounds. Mit Java entwickelt es sich aufrgrund der leistungsfähigen Standardlibrary viel schneller.

  9. Re: Wenn die CPUs mal nicht mehr schneller werden ...

    Autor: RaZZE 26.10.14 - 01:08

    Bonita.M schrieb:
    --------------------------------------------------------------------------------
    > > > Schnell und einfach ist eher Java.
    > >
    > > Hast du noch mehr Witze auf Lager?
    >
    > Ich meine nicht schnell im Sinne von performant, sondern im Sinne des
    > Entwicklungs-Turnarounds. Mit Java entwickelt es sich aufrgrund der
    > leistungsfähigen Standardlibrary viel schneller.

    Jaja lasse labern. ^^

  10. Re: Wenn die CPUs mal nicht mehr schneller werden ...

    Autor: Bonita.M 26.10.14 - 02:03

    > > Ich meine nicht schnell im Sinne von performant, sondern im Sinne des
    > > Entwicklungs-Turnarounds. Mit Java entwickelt es sich aufrgrund der
    > > leistungsfähigen Standardlibrary viel schneller.
    >
    > Jaja lasse labern. ^^

    Ne, is wirklich so, Was glaubst Du wieso Java und C# C und C++ in manchen Bereichen, zB bei Business-Software, abgelöst haben.

  11. Re: Wenn die CPUs mal nicht mehr schneller werden ...

    Autor: Cerdo 26.10.14 - 21:18

    Bonita.M schrieb:
    --------------------------------------------------------------------------------
    > glaubst Du das parallele Programmierung immer "einfach" ist?


    Mit C, C++ und Java ist das (zu) kompliziert. Da müssen andere Programmiersprachen her. Mein aktueller lieblings-Ansatz ist Scala: eine objektorientierte, funktionale Programmiersprache (also grob: Java+Haskell).
    Die Seiteneffekt-freien und Werttreuen funktionen kann man (weil sie eben dies sind) quasi trivial parallelisieren.



    1 mal bearbeitet, zuletzt am 26.10.14 21:18 durch Cerdo.

  12. Re: Wenn die CPUs mal nicht mehr schneller werden ...

    Autor: Bonita.M 26.10.14 - 22:00

    > Mit C, C++ und Java ist das (zu) kompliziert. Da müssen andere
    > Programmiersprachen her. Mein aktueller lieblings-Ansatz ist
    > Scala: eine objektorientierte, funktionale Programmiersprache
    > (also grob: Java+Haskell).

    Vergiss es; automatische Parallelisierung hat noch nie performant funktioniert. Da ist immer Handarbeit nötig.

  13. Re: Wenn die CPUs mal nicht mehr schneller werden ...

    Autor: Cerdo 26.10.14 - 22:23

    Bonita.M schrieb:
    --------------------------------------------------------------------------------
    > Vergiss es; automatische Parallelisierung hat noch nie performant
    > funktioniert. Da ist immer Handarbeit nötig.
    Das ist bei der funktionalen Programmierung anders. Da ist jede Funktion wie eine mathematische Funktion so gestaltet, dass sie (wie gesagt) komplett unabhängig von den anderen ist. Das parallelisieren ist dann einfach nur ein "Flag", der dem Compiler erlaubt, die Funktionen parallel abzuarbeiten.
    Das funktioniert jetzt schon extrem gut.
    Siehe:
    http://docs.scala-lang.org/overviews/parallel-collections/overview.html
    http://docs.scala-lang.org/overviews/core/futures.html

  14. Re: Wenn die CPUs mal nicht mehr schneller werden ...

    Autor: thesmann 20.04.15 - 23:26

    Das automatische parallelisieren mit funktionaler programmierung is zwar schon recht nett, aber man erkauft es sich teilweise doch recht teuer indem man eine Menge von Daten unnoetig dupliziert, d.h. einfuegen in eine Map ist nicht mehr O(1) (HashMap, Annahme keine Kollisionen), Sondern O(log N) (immutable Treemap,Kopieren aller Parents).

  15. Re: Wenn die CPUs mal nicht mehr schneller werden ...

    Autor: DerVorhangZuUndAlleFragenOffen 21.04.15 - 09:54

    Bonita.M schrieb:
    --------------------------------------------------------------------------------
    > > Nein. Dann nimmt man einfach wieder mehr CPUs ...
    >
    > "Einfach" - glaubst Du das parallele Programmierung immer "einfach" ist?
    >
    > > ... oder hofft darauf, dass der Compiler das erledigt (wie gut das
    > heutzutage
    > > schon geht kann man beispielhaft in der c't 12/2014 im Artikel "Matrix
    > > reloaded" von Andreas Stiller nachlesen).
    >
    > Das geht überhauptnicht gut. Die Compiler können nur
    > Lowlevel-Optimierungen.

    Naja.. Kommt drauf an... Wenn er ein MapReduce-Programm (also massiv parallel abarbeitbar) schreibt, helfen mehr CPUs vielleicht. Aber dann ist es nicht der Compiler sondern das Programm selber und der Job-Scheduler die entscheiden ob die zusätzliche Hardware nutzbar ist.

    "Entwickeln Sie ein positives Verhältnis zu Daten und freuen sie sich wenn wir mehr wissen!" ~Angela Merkel (12.06.2015)

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. SPIER GmbH & Co. Fahrzeugwerk KG, Steinheim (Westfalen)
  2. Heraeus infosystems GmbH, Hanau
  3. Anstalt für Kommunale Datenverarbeitung in Bayern (AKDB), verschiedene Standorte
  4. Deutsche Bundesbank, Frankfurt am Main, Düsseldorf

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (reduzierte Überstände, Restposten & Co.)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Programm für IT-Jobeinstieg: Hoffen auf den Klebeeffekt
Programm für IT-Jobeinstieg
Hoffen auf den Klebeeffekt

Aktuell ist der Jobeinstieg für junge Ingenieure und Informatiker schwer. Um ihnen zu helfen, hat das Land Baden-Württemberg eine interessante Idee: Es macht sich selbst zur Zeitarbeitsfirma.
Ein Bericht von Peter Ilg

  1. Arbeitszeit Das Sechs-Stunden-Experiment bei Sipgate
  2. Neuorientierung im IT-Job Endlich mal machen!
  3. IT-Unternehmen Die richtige Software für ein Projekt finden

Weclapp-CTO Ertan Özdil: Wir dürfen nicht in Schönheit und Perfektion untergehen!
Weclapp-CTO Ertan Özdil
"Wir dürfen nicht in Schönheit und Perfektion untergehen!"

Der CTO von Weclapp träumt von smarter Software, die menschliches Eingreifen in der nächsten ERP-Generation reduziert. Deutschen Perfektionismus hält Ertan Özdil aber für gefährlich.
Ein Interview von Maja Hoock


    Fiat 500 als E-Auto im Test: Kleinstwagen mit großem Potenzial
    Fiat 500 als E-Auto im Test
    Kleinstwagen mit großem Potenzial

    Fiat hat einen neuen 500er entwickelt. Der Kleine fährt elektrisch - und zwar richtig gut.
    Ein Test von Peter Ilg

    1. Vierradlenkung Elektrischer GMC Hummer SUV fährt im Krabbengang seitwärts
    2. MG Cyberster MG B Roadster mit Lasergürtel und Union Jack
    3. Elektroauto E-Auto-Prämie übersteigt in 2021 schon Vorjahressumme