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

Wenn die CPUs mal nicht mehr schneller werden ...

  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. Zum Login

Stellenmarkt
  1. BWI GmbH, Meckenheim
  2. ID Logistics über IBS GmbH, Dortmund, Weilbach, Hammersbach
  3. MVZ Labor Ludwigsburg GbR, Ludwigsburg
  4. EDAG Engineering GmbH, Wolfsburg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 469€ (Bestpreis!)
  2. (u. a. Wreckfest für 16,99€)
  3. 99€
  4. 99,90€ + Versand (Vergleichspreis 127,32€ + Versand)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Samsung CRG9 im Test: Das Raumschiffcockpit für den Schreibtisch
Samsung CRG9 im Test
Das Raumschiffcockpit für den Schreibtisch

Keine Frage: An das Curved Panel und das 32:9-Format des Samsung CRG9 müssen wir uns erst gewöhnen. Dann aber wollen wir es fast nicht mehr hergeben. Dank der hohen Bildfrequenz und guten Auflösung vermittelt der Monitor ein immersives Gaming-Erlebnis - als wären wir mittendrin.
Ein Test von Oliver Nickel

  1. Speichertechnik Samsung will als Erster HBM2 in 12 Ebenen und 24 GByte bauen
  2. Samsung Fehler am Display des Galaxy Fold aufgetreten
  3. Samsung Displaywechsel beim Galaxy Fold einmalig vergünstigt möglich

IT-Sicherheit: Auch kleine Netze brauchen eine Firewall
IT-Sicherheit
Auch kleine Netze brauchen eine Firewall

Unternehmen mit kleinem Geldbeutel verzichten häufig auf eine Firewall. Das sollten sie aber nicht tun, wenn ihnen die Sicherheit ihres Netzwerks wichtig ist.
Von Götz Güttich

  1. Anzeige Wo Daten wirklich sicher liegen
  2. Erasure Coding Das Ende von Raid kommt durch Mathematik
  3. Endpoint Security IT-Sicherheit ist ein Cocktail mit vielen Zutaten

Mädchen und IT: Fehler im System
Mädchen und IT
Fehler im System

Bis zu einem gewissen Alter sind Jungen und Mädchen gleichermaßen an Technik interessiert. Wenn es dann aber um die Berufswahl geht, entscheiden sich immer noch viel mehr junge Männer als Frauen für die IT. Ein wichtiger Grund dafür ist in der Schule zu suchen.
Von Valerie Lux

  1. IT an Schulen Intelligenter Stift zeichnet Handschrift von Schülern auf
  2. 5G Milliardenlücke beim Digitalpakt Schule droht
  3. Medienkompetenz Was, Ihr Kind kann nicht programmieren?

  1. Softbank: Wework fällt von 47 auf 8 Milliarden US-Dollar
    Softbank
    Wework fällt von 47 auf 8 Milliarden US-Dollar

    In einer neuen Vereinbarung erlangt die japanische Softbank die Kontrolle über das Co-Working-Startup Wework. Es fällt dabei erheblich im Wert und entgeht dem drohenden Bankrott.

  2. The Outer Worlds im Test: Feuergefechte und Fiesheiten am Rande des Universums
    The Outer Worlds im Test
    Feuergefechte und Fiesheiten am Rande des Universums

    Ballern in der Ego-Perspektive plus klassisches Rollenspiel: Darum geht es in The Outer Worlds von Obsidian Entertainment (Fallout New Vegas). Beim Test hat sich das Abenteuer als schön kranker Spaß mit B-Movie-Charme entpuppt.

  3. Microsoft: Windows überprüft Firmware und Boot auf Manipulationen
    Microsoft
    Windows überprüft Firmware und Boot auf Manipulationen

    Gemeinsam mit seinen Hardware-Partnern startet Microsoft die Initiative Secured-core-PC. Diese Windows-Rechner sollen Manipulation der Firmware und des Bootprozesses erkennen. Die Idee und Technik dafür ist längst bekannt.


  1. 16:00

  2. 15:01

  3. 14:55

  4. 14:53

  5. 14:30

  6. 13:35

  7. 12:37

  8. 12:08