Abo
  1. Foren
  2. Kommentare
  3. PC-Hardware
  4. Alle Kommentare zum Artikel
  5. › Server-on-a-Chip: Suns UltraSPARC…

Das kommt mir vor ...

Anzeige
  1. Thema

Neues Thema Ansicht wechseln


  1. Das kommt mir vor ...

    Autor: yeti 10.08.07 - 12:51

    als ob mein viel geliebter Transputer
    http://de.wikipedia.org/wiki/Transputer
    wieder auferstanden wäre.

    Nach dem Gigaherzwahn kommt nun endlich die parallele Datenverarbeitung in die Pötte.

  2. Re: Das kommt mir vor ...

    Autor: lulula 10.08.07 - 14:42

    yeti schrieb:
    -------------------------------------------------------

    > Nach dem Gigaherzwahn kommt nun endlich ...

    ... der Core-Wahn.
    Da es immer Parallelisierungsverluste gibt und man sowiso nicht beliebig parallelisieren kann wird man ab einer gewissen Anzahl von Cores in vergleichbare Probleme laufen.

    L.



  3. Re: Das kommt mir vor ...

    Autor: Ikke 10.08.07 - 15:09

    lulula schrieb:
    -------------------------------------------------------
    > yeti schrieb:
    > --------------------------------------------------
    > -----
    >
    > > Nach dem Gigaherzwahn kommt nun endlich ...
    >
    > ... der Core-Wahn.
    > Da es immer Parallelisierungsverluste gibt und man
    > sowiso nicht beliebig parallelisieren kann wird
    > man ab einer gewissen Anzahl von Cores in
    > vergleichbare Probleme laufen.
    >
    > L.
    >
    >

    Das sagte Amdahl schon ;-)

    http://wiki.linuxeinsteiger.net/index.php/Parallel_computing

  4. Re: Das kommt mir vor ...

    Autor: yeti 10.08.07 - 16:37

    > Das sagte Amdahl schon ;-)
    Amdahl beweist garnichts.

    Beispiel:
    Das Internet als Ganzes ist 1 paralleles System !

    Am einfachsten sind Client/Server Anwendungen parallelisierbar.
    Man hat 1 Server-Thread pro Client.
    Wenn die Anzahl der Clients wächst, braucht der Server nur immer mehr Threads aufmachen.

    Das ist z.B. bei Webservern so.

  5. Re: Das kommt mir vor ...

    Autor: Ikke 10.08.07 - 17:01

    yeti schrieb:
    -------------------------------------------------------
    > > Das sagte Amdahl schon ;-)
    > Amdahl beweist garnichts.
    >
    > Beispiel:
    > Das Internet als Ganzes ist 1 paralleles System !
    >
    > Am einfachsten sind Client/Server Anwendungen
    > parallelisierbar.
    > Man hat 1 Server-Thread pro Client.
    > Wenn die Anzahl der Clients wächst, braucht der
    > Server nur immer mehr Threads aufmachen.
    >
    > Das ist z.B. bei Webservern so.


    Du kennst den Unterschied zwischen Hochverfügbarkeit und HPC?

  6. Re: Das kommt mir vor ...

    Autor: lulula 10.08.07 - 18:17

    yeti schrieb:
    -------------------------------------------------------
    > > Das sagte Amdahl schon ;-)
    > Amdahl beweist garnichts.

    Amdahl beschreibt Profanitäten, die jedem, der sich mit paralleler Programmierung befasst, sowiso klar sind. Ich mag mich irren, aber dem, was Du schreibst, entnehme ich, dass Deine Erfahrungen in massiv-paraller Programmierung nicht sehr umfangreich sind.

    > Beispiel:
    > Das Internet als Ganzes ist 1 paralleles System !

    Jep, ist es. Du kannst ja mal gegenrechnen, wievie theoretische Rechenleistung im Internet zur Verfügung steht und wie gut man darauf eine Aufgabe parallelisieren kann.

    > Am einfachsten sind Client/Server Anwendungen
    > parallelisierbar.
    > Man hat 1 Server-Thread pro Client.
    > Wenn die Anzahl der Clients wächst, braucht der
    > Server nur immer mehr Threads aufmachen.

    Ah ja, so einfach ist das.
    Dann haben wir einen Haufen threads, die sich um die Ressourcen streiten. Das erste Dutzend threads langweilt sich, weil ein anderer Thread gerade die Datei offen hat, das zweite dutzend Threads muss sich schön hinten anstellen, um auf das Netzinterface zuzugreifen, dann will der eine Thread was von dem anderen, der andere ist damit aber noch nicht fertig...

    > Das ist z.B. bei Webservern so.

    Der tatsächliche Leistungszuwachs ist selbst bei gut parallelisierbaren Aufgaben nicht direkt proportional zum Kernelzuwachs, er ist noch nichteinmal linear dazu.

    L.


  7. Re: Das kommt mir vor ...

    Autor: hobel 10.08.07 - 19:28

    lulula schrieb:

    > Der tatsächliche Leistungszuwachs ist selbst bei
    > gut parallelisierbaren Aufgaben nicht direkt
    > proportional zum Kernelzuwachs, er ist noch
    > nichteinmal linear dazu.
    >
    Oehm... oehm...
    und jetzt erklaere bitte noch eben den Unterschied zwischen
    "direkt proportional" und "linear"...


  8. Re: Das kommt mir vor ...

    Autor: Ikke 10.08.07 - 20:15

    hobel schrieb:
    -------------------------------------------------------
    > lulula schrieb:
    >
    > > Der tatsächliche Leistungszuwachs ist selbst
    > bei
    > gut parallelisierbaren Aufgaben nicht
    > direkt
    > proportional zum Kernelzuwachs, er ist
    > noch
    > nichteinmal linear dazu.
    >
    > Oehm... oehm...
    > und jetzt erklaere bitte noch eben den Unterschied
    > zwischen
    > "direkt proportional" und "linear"...
    >
    >


    Exponentiell proportional :o)

  9. Re: Das kommt mir vor ...

    Autor: lulula 10.08.07 - 20:51

    hobel schrieb:
    -------------------------------------------------------
    > Oehm... oehm...
    > und jetzt erklaere bitte noch eben den Unterschied
    > zwischen
    > "direkt proportional" und "linear"...

    f(x)=ax

    wobei
    a=1
    vs.
    a Element IR

    L.

  10. Re: Das kommt mir vor ...

    Autor: pdOrta 11.08.07 - 19:15

    Ikke schrieb:
    -------------------------------------------------------
    > Du kennst den Unterschied zwischen
    > Hochverfügbarkeit und HPC?

    Das Gesetz von Amdahl besagt, daß jeder parallele Algorithmus durch einen sequentiellen Bestandteil gebremst wird.

    Das greift hir nicht unbedingt. Denn auf den 8 Cores können ja 8 unterschiedliche Programme laufen. Dann gilt Amdahl schon mal nicht.

    lg
    pdOrta

  11. Re: Das kommt mir vor ...

    Autor: yeti 12.08.07 - 10:07

    > Ich mag mich irren, aber dem, was Du
    > schreibst, entnehme ich, dass Deine Erfahrungen in
    > massiv-paraller Programmierung nicht sehr
    > umfangreich sind.
    Ich habe nur eine Dissertation über massiv-parallele Programmierung auf Transputern geschrieben.

    > Das Internet als Ganzes ist 1
    > paralleles System !
    >
    > Jep, ist es. Du kannst ja mal gegenrechnen, wievie
    > theoretische Rechenleistung im Internet zur
    > Verfügung steht und wie gut man darauf eine
    > Aufgabe parallelisieren kann.
    Man darf nicht nur die theoretische Rechenleistung sehen,
    es kommt auch (vor allen Dingen) auf die Kommunikation unter den einzelnen Knoten an.

    > > Am einfachsten sind Client/Server
    >
    > Ah ja, so einfach ist das.
    > Dann haben wir einen Haufen threads, die sich um
    > die Ressourcen streiten.
    Z.B. bei Webservern brauchen sich die Threads nur um die Festplatte "streiten".

    > Das erste Dutzend threads
    > langweilt sich, weil ein anderer Thread gerade die
    > Datei offen hat,
    Die meisten Operationen bei Webservern sind aber "read" und das kann parallel ohne Warten gemacht werden.

    > das zweite dutzend Threads muss
    > sich schön hinten anstellen, um auf das
    > Netzinterface zuzugreifen,
    Natürlich müssen sich die Threads die Bandbreite des Netzwerkinterface teilen.

    > dann will der eine
    > Thread was von dem anderen, der andere ist damit
    > aber noch nicht fertig...
    Wieder zum Beispiel Webserver: Die Threads, die die einzelnen Clients bedienen, brauchen sich nicht untereinander zu unterhalten. Die sind logisch völlig voneinander losgelöst.

    > Der tatsächliche Leistungszuwachs ist selbst bei
    > gut parallelisierbaren Aufgaben nicht direkt
    > proportional zum Kernelzuwachs, er ist noch
    > nichteinmal linear dazu.
    Im realen Leben wird auch parallelisiert. Nimm z.B. ein Fliessband.
    Da gibt es mehrere Bearbeitungsschritte, die parallel laufen können.
    Wichtig ist dabei, dass im "Input" immer ein Vorrat an Rohprodukten liegt.
    Sonst müsste der "Worker" nämlich Däumchen drehen.
    Ist etwas im "Input" kann sich der "Worker" das Rohprodukt schnappen und bearbeiten. Das bearbeite Produkt wird dann in den "Input" des nächsten "Worker" gelegt.

    Mit anderen Worten:
    Die Kommunikation zwischen den einzelnen Instanzen des Fliessbandes muss einen Puffer enthalten (FIFO), damit der Sender "Rohprodukte" senden kann, ohne auf den nächsten in der Pipeline warten zu müssen. Request/Response Zyklen sind zu vermeiden.

    Das Problem beim Transputer war, dass kein solcher FIFO vorgesehen war sondern auf das Rendezvous Verfahren gesetzt wurde, bei dem sich Sender und Empfänger zur Datenübergabe treffen mussten.

  12. Parallel vs. Seriell

    Autor: Suomynona 12.08.07 - 18:57

    yeti schrieb:
    -------------------------------------------------------
    > Im realen Leben wird auch parallelisiert. Nimm z.B. ein Fliessband.

    Entschuldigung aber gerade das Fliessband ist doch eher ein serielles Beispiel und damit eher mit den Verarbeitungsschritten in den Pipelines der einzelnen CPU-Kerne vergleichbar.

    Parallelisierung waere dann eher mehrere Fliessbaender parallel zu installieren die unabhaengig voneinander jeweils ein Produkt oder eine Baugruppe zusammensetzen.
    Das wichtigeste Stichwort ist hier "unabhaengig", denn nur dann kann man wirklich voll parallelisieren und muss nicht ein Fliessband anhalten um auf das Andere zu warten.

    Um an dem Beispiel weiterzuspinnen: Solange FB1 und FB1 jeweils das komplette Produkt zusammensetzen sind sie vollkommen unabhaengig voneinander. Sobald aber FB1 Baugruppe1 und FB2 Baugruppe2 zusammensetzen und diese beiden Baugruppen an FB3 zum fertigen Produkt verarbeitet werden, haengen alle 3 Fliessbaender voneinander ab, FB3 muss warten egal ob es auf FB1 oder FB2 zu einer Verzoegerung kommt. Puffer zwischen den Fliessbaendern sind hier auch kein Allheilmittel; sobald es um die zeitnahe Produktion geht, bei der so schnell wie moeglich hinten vom Band laufen muss, was eben erst vorn angefordert wurde, sorgen Puffer fuer stoerende Verzoegerungen.
    Des weiteren wir hier sehr schoen klar, dass man bei unabhaengigen Problemen sehr schoen parallelisieren kann, sobald man es aber mit nur einem Problem zu tun hat erzeugt die Parallelisierung sehr schnell mehr Overhead durch die Verwaltung der Parallelisierung, als Zuwachs bei der Geschwindigkeit der Problemloesung.

    Zurueck zu Computern und deren CPUs: Jenseits der 2 Kerne wird es fuer den Alltagsgebrauch sehr schnell sehr duenn bei den Leistungszuwaechsen, mehr als 4 Kerne werden ohne massive Aenderung des Nutzungsprofils niemals sinnvoll sein. Mit Kerne sind hier CPU-Kerne gemeint, die saemtliche Funktionseinheiten einer klassischen CPU enthalten.

    Einzig bei Spezialisierung einzelner Kerne auf eng eingegrenzte Probleme kann eine hoehere Anzahl Kerne sinnvoll genutzt werden, um den Preis, dass viele Resourcen brach liegen, wenn Probleme mit einseitigen Anforderungen geloest werden muessen.

    Bei Servern wird sich die Frage nach dem Sinn weiterer Parallelisierung jenseits 8 oder 16 Kernen pro System stellen, nicht umsonst gibt es nur ein paar wenige Supercomputer mit unzaehligen CPUs und die grosse Masse besteht aus 2- und 4-Prozessor-Systemen, die laut Studien zum Einsatz von Virtualisierungsloesungen oftmals nur zu 20% ausgelastet sind.
    Durch Virtualisierung laesst sich die Grenze vielleicht noch bis 32 Kerne verschieben, wobei diese Rechnung eigtl. nicht richtig ist, ersetzt doch dann ein Server zwei oder mehr alte Systeme womit das Gegenteil einer Parallelisierung stattfindet.

    snafu,
    Syomynona

  13. Re: Parallel vs. Seriell

    Autor: yeti 13.08.07 - 10:17

    > Entschuldigung aber gerade das Fliessband ist doch
    > eher ein serielles Beispiel und damit eher mit den
    > Verarbeitungsschritten in den Pipelines der
    > einzelnen CPU-Kerne vergleichbar.
    Auch bei einem Fliessband wird parallel gearbeitet.
    Man kann natürlich auch Fliessbänder parallel stellen.

    In jeder Station des Fliessbandes werden einzelne Bearbeitungsschritte durchgeführt.
    - Kotflügel einbauen
    - Sitze einbauen
    - Windschutzscheibe einsetzen
    - Kofferraumdeckel einbauen
    etc.

    Das geht dann parallel !!!

    Beim Computer denke ich da z.B. an ein System aus der Regelungs- und Steuerungstechnik.
    Da gibt es viele Übertragungsglieder (Regler, Filter, Beobachter ...),
    die in einem Netz verschaltet sind.
    Traditionell wurden diese Glieder in Analogtechnik ausgeführt und verdrahtet.
    Das ist "echt" parallel.
    Je nach Grösse der Anlage kommen mehr oder weniger Übertragungsglieder vor.

    Mit digitaler Technik könnte nun jedes dieser Übertragungsglieder auf einer eigenen CPU gerechnet werden, um die Zykluszeiten zu erhöhen.

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Anzeige
Stellenmarkt
  1. Robert Bosch GmbH, Weilimdorf
  2. Sky Deutschland GmbH, Unterföhring bei München
  3. VeriTreff GmbH, Ruhrgebiet
  4. Schaeffler Technologies AG & Co. KG, Herzogenaurach

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Blu-ray-Angebote
  1. 299,99€ (Vorbesteller-Preisgarantie)
  2. 12,99€
  3. (u. a. Hobbit Trilogie Blu-ray 43,89€ und Batman Dark Knight Trilogy Blu-ray 17,99€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Smartphoneversicherungen im Überblick: Teuer und meistens überflüssig
Smartphoneversicherungen im Überblick
Teuer und meistens überflüssig
  1. Winphone 5.0 Trekstor will es nochmal mit Windows 10 Mobile versuchen
  2. Librem 5 Das freie Linux-Smartphone ist finanziert
  3. Aquaris-V- und U2-Reihe BQ stellt neue Smartphones ab 180 Euro vor

Erneuerbare Energien: Siemens leitet die neue Steinzeit ein
Erneuerbare Energien
Siemens leitet die neue Steinzeit ein
  1. Siemens und Schunk Akkufahrzeuge werden mit 600 bis 1.000 Kilowatt aufgeladen
  2. Parkplatz-Erkennung Bosch und Siemens scheitern mit Pilotprojekten

Cubesats: Startup steuert riesigen Satellitenschwarm von Berlin aus
Cubesats
Startup steuert riesigen Satellitenschwarm von Berlin aus
  1. Arkyd-6 Planetary Resources startet bald ein neues Weltraumteleskop
  2. SAEx Internet-Seekabel für Südatlantikinsel St. Helena
  3. Sputnik Piep, piep, kleiner Satellit

  1. Siri-Lautsprecher: Apple versemmelt den Homepod-Start
    Siri-Lautsprecher
    Apple versemmelt den Homepod-Start

    Apples erster Siri-Lautsprecher kommt nicht mehr in diesem Jahr auf den Markt. Apple kann die Markteinführung des Homepod nicht einhalten. Ein Verkaufsstart in Deutschland rückt damit in weite Ferne.

  2. Open Routing: Facebook gibt interne Plattform für Backbone-Routing frei
    Open Routing
    Facebook gibt interne Plattform für Backbone-Routing frei

    Facebook hat seine Netzwerk-Routing-Plattform Open/R unter eine freie Lizenz gestellt und auf Github veröffentlicht. Das Unternehmen nutzt Open/R selbst in seinen eigenen Backbone-Netzen und hat die Software zunächst für urbanes GBit-Wi-Fi erstellt.

  3. Übernahme: Vivendi lässt Ubisoft ein halbes Jahr in Ruhe
    Übernahme
    Vivendi lässt Ubisoft ein halbes Jahr in Ruhe

    In den nächsten Monaten will der französische Medienkonzern Vivendi die feindliche Übernahme von Ubisoft nicht weiter vorantreiben - danach sind aber wieder alle Optionen offen. Immerhin hat Vivendi durch den Anteilskauf bislang rund eine Milliarde Euro an Buchgewinnen gemacht.


  1. 19:05

  2. 17:08

  3. 16:30

  4. 16:17

  5. 15:49

  6. 15:20

  7. 15:00

  8. 14:40