1. Foren
  2. Kommentare
  3. PC-Hardware
  4. Alle Kommentare zum Artikel
  5. › Hawk: Deutscher 24-Petaflops…

Wer benutzt die und wie?

  1. Thema

Neues Thema Ansicht wechseln


  1. Wer benutzt die und wie?

    Autor: bionade24 13.11.18 - 21:44

    Aus dem Super-MUC Artikel hab ich erfahren, dass die HPCs dann aufegeteilt werden und dort dann Power über nen Ticket-System vergeben wird. Deshalb frage ich mich, warum mann nicht einfach einzelnes nodes wie Google, AWS und Azure macht.

    Bitte BBCode nutzen und nicht einfach Links reinpasten, wir sind hier schließlich in einem IT-Forum!

  2. Re: Wer benutzt die und wie?

    Autor: xenofit 14.11.18 - 00:35

    Das ist einfach zu teuer und die Interconnects sind nicht schnell genug.

    Die Cloud Dienste lohnen sich eigentlich nur dann wenn man wechselnden Workload hat. Also Manchmal viel und manchmal wenig.
    Diese HPC Systeme für die Forschung laufen eigentlich immer unter Vollast. Wenn da Kapazität frei ist kommt jemand dreht seine Simulation um einen Freiheitsgrad hoch oder erhöht irgendwie anders den Aufwand der Simulation und schon ist wieder Vollast angesagt. Bei den großen Systemen wie zum Beispiel beim SuperMuc oder auch dem HLRN in Berlin und Hannover stellen die Forscher Monate im vorraus Anträge auf Rechenzeit und die werden dann oft auch noch ein bisschen Runtergestuft. Das heißt die Komplexität muss dann reduziert werden. Das verringert dann natürlich die Qualität der Ergebnisse.

    Der zweite Grund, ist wie oben schon gesagt die Performance des Interconnects. In den HPC Systemen wird eigentlich immer mit Infiniband bzw. seit neustem auch Omnipath gearbeitet. Die sind sehr schnell und latenzarm und ermöglichen damit unter anderem RDMA (remote direct memory access). Damit kann direkt ohne Umweg über die CPU (ausgenommen der Speicherkontroller) auf den RAM eines anderen Knotens zugegriffen werden.
    Über diese Interconnects sind dann nicht nur die Knoten selbst vernetzt sondern auch das Speichersystem. Auch das ist nochmal ne größenordnung Performanter als das was bei den Cloud Hostern so rumsteht.

  3. Re: Wer benutzt die und wie?

    Autor: Quantium40 14.11.18 - 00:41

    bionade24 schrieb:
    > Aus dem Super-MUC Artikel hab ich erfahren, dass die HPCs dann aufegeteilt
    > werden und dort dann Power über nen Ticket-System vergeben wird. Deshalb
    > frage ich mich, warum mann nicht einfach einzelnes nodes wie Google, AWS
    > und Azure macht.

    Grundsätzlich besteht auch der Super-MUC aus vielen einzelnen Nodes. Der Unterschied besteht darin, wie diese miteinander kommunizieren und inwieweit sie auf die Resourcen der anderen Nodes zugreifen können.

  4. Re: Wer benutzt die und wie?

    Autor: Theoretiker 14.11.18 - 11:45

    Die Frage ist, welche Art von Berechnungen man macht. Wie die anderen schon geschrieben haben ist das Netzwerk der entscheidende Unterschied; die eigentlich Rechner sind heutzutage Standardhardware.

    Wir lösen hauptsächlich große Gleichungssysteme (Größenordnung 100M Gleichungen). Diese haben bei uns die Besonderheit, dass nur die Einträge um die Diagonale ungleich null sind, wir also eine sehr dünn besetzte Matrix haben. Dies haben wir als Stencil-Operator implementiert, der von den benachbarten Rechnern die Werte abfragen muss. So haben wir nur Kommunikation zwischen nächsten Nachbarn, aber nicht global.

    Im Gegensatz zu für uns unrealistischen Benchmarks wie LINPACK hängen wir ganz kritisch von der Latenzzeit des Netzwerkes ab, weil wir zu wenig zu berechnen haben für die Menge an Daten, die wir kommunizieren müssen. Nehmen wir aber weniger Nodes, so passen wir dort nicht mehr in die Caches rein und die Performance geht auch ordentlich runter. Würden wir das also in der Cloud mit normalen 1 GBit/s Ethernet laufen lassen und Latenzzeiten in der Ecke von 0.1 bis 1 ms, würde das die Skalierung auf viele Nodes effektiv verhindern. Auf Maschinen wie JUQUEEN gab es worst-case Latenzzeiten von 0.0025 ms, also drastisch besser. Wo jetzt Infiniband und OmniPath liegen, weiß ich nicht, aber es wird schon ordentlich sein.

    Jedoch hat jeder Code das Problem, dass er nicht beliebig weit skalieren kann. Irgendwann hat man pro Node fast nichts mehr zu rechnen und das System erstickt an der Kommunikation. Da wir das gleiche Programm auf meist so 500 Datensätzen laufen lassen, nehmen wir lieber 500 kleinere Jobs, die dann parallel laufen könnten. Hier ist aber das Problem dass die Rechenzentren es gerne sehen, wenn Leute einen Großteil der Maschine gleichzeitig nutzen würden und diese Art Jobs dann priorisieren. Wenn das Netzwerk aber nicht ausreicht, wäre das nur eine Verschwendung von Rechenzeit.

  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. WEGMANN automotive GmbH, Veitshöchheim
  2. ServiceOcean SalesDE GmbH, Köln
  3. RUAG Ammotec GmbH, Fürth
  4. Fraunhofer-Institut für Integrierte Schaltungen IIS, Nürnberg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 34,99€ (Release 5. Februar)
  2. 29,99€
  3. 5,75€


Haben wir etwas übersehen?

E-Mail an news@golem.de