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

Das kommt mir vor ...

  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

Stellenmarkt
  1. Lidl Digital, Heilbronn
  2. PFALZKOM | MANET, Ludwigshafen
  3. GSI Helmholtzzentrum für Schwerionenforschung GmbH, Darmstadt
  4. Carl Spaeter Südwest GmbH, Karlsruhe

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. mit Gutschein: HARDWARE50 (nur für Neukunden, Warenwert 104 - 1.000 Euro)
  2. (Neuware für kurze Zeit zum Sonderpreis bei Mindfactory)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Automatisiertes Fahren: Der schwierige Weg in den selbstfahrenden Stau
Automatisiertes Fahren
Der schwierige Weg in den selbstfahrenden Stau

Der Staupilot im neuen Audi A8 soll der erste Schritt auf dem Weg zum hochautomatisierten Fahren sein. Doch die Verhandlungen darüber, was solche Autos können müssen, sind sehr kompliziert. Und die Tests stellen Audi vor große Herausforderungen.
Ein Bericht von Friedhelm Greis

  1. Nach tödlichem Unfall Uber entlässt 100 Testfahrer für autonome Autos
  2. Autonomes Fahren Daimler und Bosch testen fahrerlose Flotte im Silicon Valley
  3. Kooperationen vereinbart Deutschland setzt beim Auto der Zukunft auf China

KI in der Medizin: Keine Angst vor Dr. Future
KI in der Medizin
Keine Angst vor Dr. Future

Mit Hilfe künstlicher Intelligenz können schwer erkennbare Krankheiten früher diagnostiziert und behandelt werden, doch bei Patienten löst die Technik oft Unbehagen aus. Und das ist nicht das einzige Problem.
Ein Bericht von Tim Kröplin

  1. Künstliche Intelligenz Vages wagen
  2. KI Mit Machine Learning neue chemische Reaktionen herausfinden
  3. Elon Musk und Deepmind-Gründer Keine Maschine soll über menschliches Leben entscheiden

Segelschiff: Das Vindskip steckt in der Flaute
Segelschiff
Das Vindskip steckt in der Flaute

Hochseeschiffe gelten als große Umweltverschmutzer. Neue saubere Antriebe sind gefragt. Der Norweger Terje Lade hat ein futuristisches Segelschiff entwickelt. Doch solch ein neuartiges Konzept umzusetzen, ist nicht so einfach.
Ein Bericht von Werner Pluta

  1. Energy Observer Toyota unterstützt Weltumrundung von Brennstoffzellenschiff
  2. Hyseas III Schottische Werft baut Hochseefähre mit Brennstoffzelle
  3. Kreuzschifffahrt Wie Brennstoffzellen Schiffe sauberer machen

  1. Satelliteninternet: Fraunhofer erreicht hohe Datenrate mit Beam Hopping
    Satelliteninternet
    Fraunhofer erreicht hohe Datenrate mit Beam Hopping

    Satelliteninternet kann mit DVB-S2X und Beam Hopping sehr viel mehr als bisher. Das will das Fraunhofer IIS bewiesen haben.

  2. Yager: Berliner Entwicklerstudio stellt Actionspiel The Cycle vor
    Yager
    Berliner Entwicklerstudio stellt Actionspiel The Cycle vor

    In 20 Minuten so viel erledigen wie möglich, Koop-Partnerschaften schließen - und überleben: Das ist das Grundprinzip von The Cycle. Hinter dem Shooter steckt das Entwicklerstudio Yager, vor allem für Spec Ops: The Line und Dreadnought bekannt ist.

  3. Macbook Pro: Apple kann den Core i9 nicht kühlen
    Macbook Pro
    Apple kann den Core i9 nicht kühlen

    Wird auf dem Macbook Pro ein längeres Videoprojekt exportiert, ist das Modell mit Core i9 langsamer als das von 2017, da die CPU unter den Basistakt drosselt. Apple könnte per Firmware-Update eingreifen.


  1. 18:05

  2. 17:46

  3. 17:31

  4. 17:15

  5. 17:00

  6. 15:40

  7. 15:16

  8. 15:00