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

Schöner Artikel

Für Konsolen-Talk gibt es natürlich auch einen Raum ohne nerviges Gedöns oder Flamewar im Freiraum!
  1. Thema

Neues Thema Ansicht wechseln


  1. Schöner Artikel

    Autor: teenriot* 24.10.14 - 12:17

    Hat mir Spaß gemacht zu lesen.

  2. Re: Schöner Artikel

    Autor: Dendamin 24.10.14 - 13:09

    teenriot* schrieb:
    --------------------------------------------------------------------------------
    > Hat mir Spaß gemacht zu lesen.

    Dem schliesse ich mich an. Vielen Dank!

  3. Re: Schöner Artikel

    Autor: Rainer Tsuphal 24.10.14 - 13:58

    Dendamin schrieb:
    --------------------------------------------------------------------------------
    > teenriot* schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Hat mir Spaß gemacht zu lesen.
    >
    > Dem schliesse ich mich an. Vielen Dank!
    Ich auch. Selten, dass ich einen fünfseitigen Artikel ganz lese, aber hier hat es sich gelohnt.

  4. Re: Schöner Artikel

    Autor: Boandlgramer 24.10.14 - 14:25

    Mich auch...

    Ich würd' aber einen Gedanken beisteuern wollen, der mir zu kurz kam. Es geht ja im Ergebnis um Rechenleistung; in den 80ern und 90ern gab's da als öffentliche Diskussion den Gegensatz CISC/RISC - und wenn ich das richtig interpretiere, ist das im Wesentlichen für CISC ausgegangen. Das bedeutet ja, ein Teil der Rechenleistung ist deswegen besser, weil sie nicht von einem Compiler organisiert wird, sondern on Chip "erzeugt" wird. Weil der Compiler nicht gut genug war...

    Um die Kurve zu kriegen: Hardware und Software lassen sich im Detail dann gar nicht gut trennen. Und was die Software - im ersten Durchgang natürlich Compiler und Interpreter - angeht, stecken wir imho noch in den 70ern oder 80ern fest.

    Die Themen Multiprocessing/-threading, Optimierung und sogar OOP kreisen immer noch ziellos. OOP hat sich als Dogma (unter der Voraussetzung industrieller Erzeugung von Software) durchgesetzt, ist aber bezogen auf die erzielbare Rechenleistung ein Hindernis. Bei Optimierungen würd' ich als Beispiel den sagenhaften Boost der JVM von Android zwischen der Version 2.2 und 2.3 (ich hoffe, ich erinnere mich richtig) anführen, das zeigt, wie viel Luft da nach oben ist. Beim Multithreading sind keine einheitlichen, vorteilhaften Konzepte sichtbar; das ist anwendungsspezifisches Gebastel - zum Teil getrieben durch das Gebastel in den Betriebssystemen. Am Ende wird's als Teufelszeug doch einfach ignoriert. Kann mdraid mittlerweile mehr als einen Kern belasten?

    Als provokanter Einschub: Warum haben mein Tablet, mein Telefon, mein Desktop, mein Auto, meine Uhr, meine Waschmaschine jeweils ein eigenes Leistungslimit; obwohl die (teiweise) heute schon miteinander vernetzt sind und also sehr wohl bestimmte Aufgaben gemeinschaftlich lösen könnten?

    Deswegen glaube ich, dass die Software in den nächsten Jahrzehnten Moores Law weiter tragen wird, auch wenn die Hardware nicht mehr dieses Tempo alleine vorlegen kann.

    Und dann wäre die Erkenntnis vielleicht einfach nur, dass Moore und Co die Begrifflichkeiten zu Eng gesetzt haben.

  5. Re: Schöner Artikel

    Autor: Quantium40 24.10.14 - 16:10

    Boandlgramer schrieb:
    --------------------------------------------------------------------------------
    > Deswegen glaube ich, dass die Software in den nächsten Jahrzehnten Moores
    > Law weiter tragen wird, auch wenn die Hardware nicht mehr dieses Tempo
    > alleine vorlegen kann.
    > Und dann wäre die Erkenntnis vielleicht einfach nur, dass Moore und Co die
    > Begrifflichkeiten zu Eng gesetzt haben.

    Einfach mal Moores Law im Originalwortlaut lesen. Software oder auch Tempo haben nicht wirklich etwas damit zu tun:
    > The complexity for minimum component costs has increased at a rate of roughly a
    > factor of two per year. Certainly over the short term this rate can be expected to
    > continue, if not to increase. Over the longer term, the rate of increase is a bit more
    > uncertain, although there is no reason to believe it will remain nearly constant for at
    > least 10 years.

  6. Re: Schöner Artikel

    Autor: unknown75 24.10.14 - 16:23

    Boandlgramer schrieb:
    --------------------------------------------------------------------------------

    > Als provokanter Einschub: Warum haben mein Tablet, mein Telefon, mein
    > Desktop, mein Auto, meine Uhr, meine Waschmaschine jeweils ein eigenes
    > Leistungslimit; obwohl die (teiweise) heute schon miteinander vernetzt sind
    > und also sehr wohl bestimmte Aufgaben gemeinschaftlich lösen könnten?

    Ähm, naja wenn willst kannst du dir auch aus all dem Kram einen "TabletWaschmaschinenTelefonDesktopAuto-Cluster" bauen. Nur die Frage ist wie Sinnvoll das ist. Die Vernetztung wird nämlich so viel Overhead verursachen, das dein Desktop PC (ich vermute mal deine schnellest Kiste) n mal früher alleine fertig ist. Dazu kommt das sich nicht alle Probleme parallelisieren lassen und Abhängigkeiten entstehen können. Aber prinzipiell könnte man trotzdem so einen Cluster bauen, was zum Teil auch gemacht wird. Das ganze nennt sich dann Gridcomputing und BOINC unterstützt mitlerweile auch Android und damit Handys, TV, Digitalkameras, Tablets, vielleicht bald auch Kühlschränke und Waschnmaschinen.

    So ich hoffe soweit konnte ich dir erstmal weiter helfen ;-)

  7. Re: Schöner Artikel

    Autor: nie (Golem.de) 24.10.14 - 17:41

    Danke, für solches Feedback machen wir uns gern die Mühe ;)

    Nico Ernst
    Redaktion Golem.de

  8. Re: Schöner Artikel

    Autor: Anonymer Nutzer 27.10.14 - 07:46

    Boandlgramer schrieb:
    --------------------------------------------------------------------------------
    > Mich auch...
    >
    > Ich würd' aber einen Gedanken beisteuern wollen, der mir zu kurz kam. Es
    > geht ja im Ergebnis um Rechenleistung; in den 80ern und 90ern gab's da als
    > öffentliche Diskussion den Gegensatz CISC/RISC - und wenn ich das richtig
    > interpretiere, ist das im Wesentlichen für CISC ausgegangen. Das bedeutet
    > ja, ein Teil der Rechenleistung ist deswegen besser, weil sie nicht von
    > einem Compiler organisiert wird, sondern on Chip "erzeugt" wird. Weil der
    > Compiler nicht gut genug war...
    >
    > Um die Kurve zu kriegen: Hardware und Software lassen sich im Detail dann
    > gar nicht gut trennen. Und was die Software - im ersten Durchgang natürlich
    > Compiler und Interpreter - angeht, stecken wir imho noch in den 70ern oder
    > 80ern fest.
    >
    > Die Themen Multiprocessing/-threading, Optimierung und sogar OOP kreisen
    > immer noch ziellos. OOP hat sich als Dogma (unter der Voraussetzung
    > industrieller Erzeugung von Software) durchgesetzt, ist aber bezogen auf
    > die erzielbare Rechenleistung ein Hindernis. Bei Optimierungen würd' ich
    > als Beispiel den sagenhaften Boost der JVM von Android zwischen der Version
    > 2.2 und 2.3 (ich hoffe, ich erinnere mich richtig) anführen, das zeigt, wie
    > viel Luft da nach oben ist. Beim Multithreading sind keine einheitlichen,
    > vorteilhaften Konzepte sichtbar; das ist anwendungsspezifisches Gebastel -
    > zum Teil getrieben durch das Gebastel in den Betriebssystemen. Am Ende
    > wird's als Teufelszeug doch einfach ignoriert. Kann mdraid mittlerweile
    > mehr als einen Kern belasten?
    >
    > Als provokanter Einschub: Warum haben mein Tablet, mein Telefon, mein
    > Desktop, mein Auto, meine Uhr, meine Waschmaschine jeweils ein eigenes
    > Leistungslimit; obwohl die (teiweise) heute schon miteinander vernetzt sind
    > und also sehr wohl bestimmte Aufgaben gemeinschaftlich lösen könnten?
    >
    > Deswegen glaube ich, dass die Software in den nächsten Jahrzehnten Moores
    > Law weiter tragen wird, auch wenn die Hardware nicht mehr dieses Tempo
    > alleine vorlegen kann.
    >
    > Und dann wäre die Erkenntnis vielleicht einfach nur, dass Moore und Co die
    > Begrifflichkeiten zu Eng gesetzt haben.


    Ich werfe mal in den Raum, dass wenn die MS DOS Rechner auf RISC basiert gearbeitet hätte, heute RISC die führende und überlegene Plattform wäre. Ganz einfach weil viel mehr Geld durch den breiten Markt für R&D zur Verfügung gestanden hätte.

  9. Re: Schöner Artikel

    Autor: bassfire 27.10.14 - 10:39

    Soweit ich mich meiner Mikroprozessorvorlesung erinnere, hat sich RISC durchgestzt. Im wesentlichen weil bei CISC weitaus mehr Instruktionen zur Verfügung stehen, die bei RISC vom Compiler zusammengesetzt werden. Bei CISC wurden deshalb die Steuerwerke des Prozessors deshalb oft viel zu komplex und nahmen mehr als 50% der Chipfläche ein.

  10. Re: Schöner Artikel

    Autor: Quantium40 27.10.14 - 12:21

    DY schrieb:
    --------------------------------------------------------------------------------
    > Ich werfe mal in den Raum, dass wenn die MS DOS Rechner auf RISC basiert
    > gearbeitet hätte, heute RISC die führende und überlegene Plattform wäre.
    > Ganz einfach weil viel mehr Geld durch den breiten Markt für R&D zur
    > Verfügung gestanden hätte.

    Die meistverkaufte CPU-Architektur sind die ARMs, die wohl irgendwie als RISC-CPUs gelten, obwohl die Befehlssätze im Laufe der Zeit kräftig gewachsen sind.
    Auf der anderen Seite sind aktuelle x86-CISC-CPUs eigentlich RISC-CPUs mit einer zusätzlichen Übersetzungsschicht von CISC (Makro-Ops) auf RISC (Mikro-Ops).

  11. Re: Schöner Artikel

    Autor: MikeMan 20.04.15 - 14:13

    nie (Golem.de) schrieb:
    --------------------------------------------------------------------------------
    > Danke, für solches Feedback machen wir uns gern die Mühe ;)

    Welche Mühe, der ist doch republished von 2014. Nicht mal die Korrektur der Jahresangaben hat Mühe erfordert, da nicht geschehen.

    Ich meine, der Artikel ist gut und ich hätte auch nichts gesagt, aber eine so wohlfeile und selbstzufriedene Antwort fordert es ja dann doch heraus...sorry.

  12. Re: Schöner Artikel

    Autor: koelnerdom 20.04.15 - 14:22

    Tja, bevor man so austeilt, sollte man vielleicht genau hinschauen, oder? Denn auch der Kommentar ist vom vergangenen Jahr.

  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. MVV EnergySolutions GmbH, Mannheim
  2. Rems-Murr-Kliniken gGmbH, Winnenden
  3. Zentrale zur Bekämpfung unlauteren Wettbewerbs Frankfurt am Main e. V., Bad Homburg
  4. Dynamit Nobel Defence GmbH, Berlin

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 4,25
  2. 4,49€
  3. 5,99€


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