RAID-Technologie verspricht höhere Performance und mehr Sicherheit beim permanenten Speichern von Daten. Die ADMIN-Redaktion gibt einen Überblick über ... (mehr)

Parallelarbeit

Schon aus der Geschwindigkeit lässt sich ablesen, dass Julia die Aufgabe parallel abgearbeitet hat (alternativ kann man sich die Worker-Prozesse auch mit »top« ansehen). Zu beachten ist, dass diese einfache Schleife keine Informationen über Anzahl oder Ort der Cores brauchte. Das ist ein sehr mächtiges Feature, weil man damit eine Applikation zunächst auf einer kleinen Anzahl Cores laufen lassen kann, die sich später vergrößern lässt.

Obwohl diese Methode nicht immer für Effizienz garantiert, ist es doch immer hilfreich, wenn der Programmierer von der Buchführung bei der Parallelarbeit entlastet wird. Viele andere nützliche Funktionen sind eine Untersuchung wert, etwa »myid()« , die eine eindeutige Prozessornummer zurückgibt, die der Identifizierung dient.

Der zweite Weg Cores hinzuzufügen benützt die Grid Engine [10] und die Funktion »addprocs_sge()« . Andere Scheduler wie Torque werden in der Zukunft wohl auch unterstützt. Das unscheinbare Feature erlaubt es, Programmen unter Einbeziehung des gesamten Clusters zu skalieren. Damit lassen sich Programme konstruieren, die sich dynamisch und selbstständig die benötigten Ressourcen zusammensuchen.

So könnte eine Applikation auf dem Notebook eines Benutzers laufen, aber Cores eines Clusters anfordern. Kann sie nicht bedient werden, könnte sie sich selbst beenden oder aber warten, bis die Ressourcen verfügbar sind. Einige Features der selbst in Julia geschriebene Parallel Computing-Komponente, etwa das Entfernen nicht mehr benötigter Cores oder ein besseres Recovery, sind derzeit noch in Entwicklung.

Ein anderes interessantes Szenario ist eine HPC-Workstation, bei der der Anwender oder ein Scheduler automatisch Cores freischaltet, sobald sie gebraucht werden. Das Julia-Programm könnte sich damit selbst verwalten und selbstständig Ressourcen anfordern, sobald sie nötig sind. Der Anwender muss dabei niemals über Nodes oder Batch Queues nachdenken, sondern kann sich ganz auf das Problem konzentrieren, das er lösen will, statt auf die Details der Parallelverarbeitung.

Teile und herrsche

Den Nutzer von der Verantwortung für das Managen der Kommunikation und Synchronisation zu entbinden, hat viele Vorteile. Wie die Arbeit dabei genau verteilt wird, ist dabei für den Anwender transparent. Julia startet viele parallele Berechnungen als Task oder Co-Routinen. Immer, wenn der Code eine Kommunikationsroutine wie »fetch()« oder »wait()« erfordert, suspendiert der Scheduler zunächst die aktuelle Task und lässt eine andere laufen. Wenn der Wait-Event beendet ist (weil beispielsweise die Daten berechnet sind) wird die suspendierte Task anschließend wieder aufgenommen.

Dieses Design hat den großen Vorteil, dass sich der Nutzer nicht explizit um die Synchronisation kümmern muss. Zusätzlich erlaubt dieses dynamische Scheduling die recht einfache Implementierung von Master/Worker-Umgebungen nach dem Schema "Teile und herrsche".

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019