Report

Verwendung einer Sony PlayStation 3 als Workstation
Alexander Jesner, David Forstenlechner und Lukas Grossar
1. April 2008
1
Vorbereitung
1.1
Ziel des Projektes
Das Ziel des Projektes ist es, eine handelsübliche Sony PlayStation 3 entsprechend mit
Linux aufzusetzen, um sie als Workstation nutzen zu können. Die PlayStation 3 ist aufgrund des verbauten Cell Prozessors, welcher 8 Kerne beherbergt, für parallelisierte Berechnungen bzw. Simulationen prädestiniert und wird unter anderem von Mag. Manfred
Liebmann für seine Parallel Toolbox1 verwendet werden.
1.2
1.2.1
Verwendete Hardware
Sony PlayStation 3
Wir haben uns für das zu Beginn des Projekts herausgekommene 40 GB Modell entschieden, da es um etwa e 100 günstiger ist als das 60 GB Modell und für unsere Verwendung
keinerlei Nachteile birgt. Eines der Probleme, das uns schon zu Beginn des Projekts bewusst war, ist der sehr kleine Arbeitsspeicher von gerade einmal 256 MB XDR-DRAM
was vor allem bei der Wahl des Window Managers für die Linux-Installation wenig Auswahl lässt. Leider gibt es auch keine Möglichkeit nachzurüsten, da der RAM fest verbaut
ist.
1.2.2
Samsung SyncMaster 226BW
Beim Monitor mussten wir auf mehrere Dinge achten:
• muss einen DVI/HDMI Eingang besitzen und das HDCP Protokoll unterstützen
• sollte preislich unter e 300 liegen
• Problemloser Betrieb der PlayStation 3 muss möglich sein
Laut einiger Test die wir im Internet gefunden haben war dieser Monitor eine gute Balance der Ansprüche, da ein Monitor mit höherer Auflösung unser Budget hoffnungslos
gesprengt hätte.
1
http://paralleltoolbox.sourceforge.net/
1
2
Installieren des alternativen Betriebssystems
2.1
Yellow Dog Linux 5.0.2
Wir haben uns zur Installation von Yellow Dog Linux (YDL) entschieden, da er Distributor Terra Soft Solutions 2 sich auf die Power Architektur spezialisiert hat und daher auch
eine unproblematische Installation auf der PlayStation 3 garantiert. Die Installation mittels des von Terra Soft Solutions zur Verfügung gestellten HowTo verlief auch problemlos.
Leider veröffentlichte IBM kurz darauf eine neue Version der Cell Broadband Engine SDK
welche YDL 5.0.2 nicht mehr unterstützt. Daher entschieden wir uns infolgedessen für
eine Installation von Fedora 7, was zwar mehr Installationsaufwand bedeutet, uns aber
dafür im Nachhinein weniger Probleme bereiten sollte.
2.2
Fedora 7
Da die Cell Broadband Engine SDK seitens IBM nur auf Red Hat Enterprise Linux 5.1
und auf Fedora 7 unterstützt wird haben wir uns für eine Neuinstallation entschieden.
Mittels eines sehr guten HowTos3 und der Cell Linux Addon CD 4 verlief auch diese
Installation relativ unproblematisch – sie dauerte aber trotzdem mehrere Stunden.
2.2.1
FluxBox
Nach den ersten grauenhaften Erfahrungen bezüglich der Geschwindigkeit des Gnome
Window Managers entschieden wir uns für eine Installation des FluxBox5 Window Managers, was sich als sehr gute Entscheidung entpuppte, da die PlayStation damit gefühlt
doppelt so schnell unterwegs ist. Hier wirft sich natürlich die Frage auf, warum die für ihre Grafik bekannte PlayStation beim Anzeigen von einfachen Fenstern Probleme machen
sollte. Dies ist sehr schnell beantwortet: es gibt für Linux keine Driver um die Grafikkarte
direkt ansprechen zu können.
3
Einrichten der Workstation
3.1
Installation der Cell SDK 3.0
Auch hier haben sich natürlich wieder ein paar Probleme eingeschlichen. Da das Installationsskript ein paar falsche URLs gespeichert hatte, mussten wir die entsprechenden
Pakete händisch nachinstallieren. Prinzipiell verlief diese Installation aber problemlos.
2
http://www.terrasoftsolutions.com/
http://www.gnuradio.org/trac/wiki/PS3FC7Install
4
http://www.kernel.org/pub/linux/kernel/people/geoff/cell/
5
http://fluxbox.sourceforge.net/
3
2
4
Parallele Programmierung und der IBM Cell Broadband
EngineTM (Cell BE) Prozessor
4.1
Motivation
Eine der Hauptaufgaben der Computational Sciences ist die Entwicklung möglichst genauer Modelle naturwissenschaftlicher Vorgänge. Eine exakte analytische Lösung ist in
vielen Fällen nicht möglich, numerische Methoden sind in diesen Fällen einsetzbar. In
numerischen Modellen steht die Genauigkeit der Ergebnisse meist in direktem Verhältnis
mit dem erforderlichen Rechenaufwand. Die Geschwindigkeit mit der die Modelle ausgeführt werden können bestimmt also wie lange die Forscher auf Ergebnisse warten müssen
und wie genau diese Ergebnisse sein können.
Als kreativer Vorgang wird das Entwickeln neuer Modelle von der Möglichkeit interaktiv zu Experimentieren gefördert (Ideal: “Work at the speed of thought!”). Neben
der Optimierung des angewendeten Algorithmus ist die verfügbare Rechenleistung der
Hardware entscheidend für die erreichbare Geschwindigkeit. Beispiele für Strategien um
die erreichbare Rechenleistung zu erhöhen sind:
• Höhere Taktraten der Prozessoren.
Die Frequenz mit der Prozessoren Befehle ausführen steht im direkten Verhältnis
mit der theoretisch erreichbaren Rechenleistung. Die reale Rechenleistung hängt
auch von der Geschwindigkeit mit der Daten zur Berechnung an den Prozessor
geliefert werden können ab.
• Mehrere Recheneinheiten (Cores) auf einem Prozessor.
Um höhere Rechenleistung zu erzielen versuchen Prozessorhersteller eine steigende Anzahl von Recheneinheiten auf einem einzelnen Chip unterzubringen. Damit
vervielfacht sich die theoretisch erreichbare Rechenleistung.
• Verteilte Berechnung (Cluster).
Mehrere Rechner können durch spezielle Software und Protokolle in einem Netzwerk
verbunden und ihre Rechenleistung kombiniert werden.
In einem Clustern können auch Rechner mit mehreren Recheneinheiten enthalten
sein, um die verfügbare Rechenleistung weiter zu erhöhen. Auch die Möglichkeit mehrere
Datenpakete mit einem Befehl auszuführen (SIMD – Single Instruction, Multiple Data)
sei hier erwähnt.
4.2
Multithreaded, parallele und verteilte Programmierung
Im idealen Fall ist mit n Recheneinheiten eine n-fache Ausführungsgeschwindigkeit von
Algorithmen zu erreichen6 .
6
In der Realität kann manchmal eine mehr als n-fache(super −lineare) Geschwindigkeitserhöhung gemessen werden. Das ist auf die Architektur moderner Prozessoren und Speichersysteme zurückzuführen,
die die Bearbeitung kleinerer Datenpakete bevorzugt.
3
Konventionelle Programmiersprachen wie Java, C++ und Python sind imperative
Programmiersprachen, die Befehle in einer sequentiellen Ordnung ausführen, und können
damit nicht ohne weiteres auf mehrere Recheneinheiten verteilt werden.
Um Geschwindigkeitsvorteile aus multiplen Recheneinheiten zu ziehen müssen Algorithmen speziell für die parallele Ausführung auf mehrere Recheneinheiten entworfen
und programmiert werden. Einige Gesetze zur Bestimmung der erreichbaren Geschwindigkeitserhöhung werden im folgenden vorgestellt.
4.2.1
Amdahls Gesetz
Für Algorithmen die zu 100% parallelisierbar sind ist die zu erwartende Geschwindigkeit
wie erwähnt das n-fache, mit n als die Anzahl der Recheneinheiten.
Um die Beschleunigung von Algorithmen die nicht zur Gänze parallelisierbar sind,
und damit aus sequentiellen Teilen bestehen, abzuschätzen kann folgendes von Gene
Amdahl 1967 definiertes Gesetz eingesetzt werden:
S(N ) =
1
(1 − P ) +
P
N
Abbildung 1: Amdahls Gesetz
Mit P als dem Anteil des Algorithmus der parallelisiert werden kann und N der
Anzahl der Recheneinheiten auf die der Algorithmus verteilt wird. Aus dem Amdahl
Gesetz wird gefolgert dass die durch Parallelisierung erreichbare Beschleunigung durch
den sequentiellen Anteil limitiert ist.
Selbst bei 95% Parallelisierbarkeit des Algorithmus ist laut Amdahls Gesetz mit 50
Prozessoren nur eine 15-fache Beschleunigung zu erreichen, Amdahls Gesetz wurde lange
Zeit als Argument gegen die Effizienz massiv paralleler Rechenmaschinen eingesetzt.
4.2.2
Gustafsons Gesetz
Ende der 80er Jahre wurde Kritik an Amdahls Gesetz laut, als die Gruppe um John L.
Gustafson mit massiv parallelen Rechnern deutlich bessere Ergebnisse erzielte als es laut
Amdahls Gesetz möglich scheint.
Gustavson definierte 1988 folgende Formel:
4
S(N ) = N − (1 − P ) ∗ (N − 1)
Abbildung 2: Gustafsons Formel
Im Gegensatz zu Amdahls Gesetz vermindert sich der Einfluss des nicht parallelisierbaren Teils mit der Anzahl der Prozessoren, die erreichbare Geschwindigkeit ist nicht
nach oben begrenzt.
4.3
IBM Cell Broadband EngineTM (Cell BE)
Der IBM Cell Chip ist eine Weiterentwicklung der PowerPC Architektur. Er besteht aus
einer Recheneinheit mit höherem Funktionsumfang (PPE – PowerPC processing element)
und 8 Recheneinheiten mit kleinerem Funktionsumfang (SPEs – synergistic processing
elements).
Abbildung 3: Cell Prozessor Architektur
Die PPE ist ein regulärer PowerPC Kern, damit können Betriebssysteme wie Linux
auf diesem Prozessor ohne aufwändige Anpassungen ausgeführt werden.
5
Die SPEs sind speziell auf Rechenleistung optimiert – jede von ihnen besitzt 256Kb
sehr schnellen Cache Speicher für Daten und Code, spezielle Prozessor-Befehle zur gleichzeitigen Verarbeitung mehrerer Daten (SIMD) und 128 Register (jedes 128 Bit breit). Sie
sind untereinander durch einen sehr schnellen Speicher-Bus verbunden der einen Strom
von Daten zwischen den SPE effizient ermöglicht und den Cell Prozessor damit für die
parallele Verarbeitung von Daten-Streams sehr schnell macht.
Die PPE weist ihnen Code und Daten zu, insbesondere ist es den SPEs nicht möglich
direkt auf den Hauptspeicher zuzugreifen, Daten werden in Paketen angefordert und
asynchron durch DMA (direct memory access) in den Speicher geschrieben. Im idealen
Fall erlaubt dieses Konzept den SPEs ohne Unterbrechung auf höchster Auslastung zu
Rechnen.
4.3.1
Cell BE SDK
Die Architektur des Cell Prozessors erfordert spezielle Tools und Implementierungstechniken um die SPEs anzusprechen. Die Cell BE SDK stellt diese Tools zur Verfügung.
Neben angepassten C++ Compilern und Analyse-Tools bietet die SDK einige auf die
SPEs optimierte Bibliotheken um die Umsetzung von Algorithmen zu erleichtern. An
dieser Stelle sei auf die für IBM übliche, exzellente Dokumentation der SDK verwiesen.
4.4
Konkurrierende Prozessorarchitekturen
Neben IBM verfolgen auch alle anderen grossen Prozessor-Hersteller die Strategie mehrere
Recheneinheiten auf einem Chip unterzubringen. Einige der wichtigsten werden hier kurz
besprochen.
4.4.1
Intel Larrabee
Intels Antwort auf die enorme Rechenleistung von GPUs und Cell Prozessor ist derzeit
in Entwicklung unter dem Namen „Larrabee“. Die ersten Publikationen weisen auf ein
Prinzip ähnlich dem IBM Cell Prozessor hin, mit mehreren (16–24) vereinfachten x86
Kernen auf einem vom Hauptprozessor getrennten Chip.
4.4.2
Intel Multicore Prozessoren
Intel Multicore Prozessoren integrieren mehrere Recheneinheiten ihrer erfolgreichen „Pentium“
Reihe auf einem Chip.
Der Vorteil dieser Strategie besteht darin, dass bestehende Programme ohne Anpassungen auf diesen Recheneinheiten lauffähig sind. Durch die relativ hohe Komplexität der
einzelnen Einheiten ist der Platzbedarf hoch, die Anzahl der möglichen Recheneinheiten
die auf einen Chip passen dadurch limitiert.
6
4.4.3
Graphics Processing Units
GPUs setzen auf eine massive Anzahl einfacher Recheneinheiten (bis zu 420 zur Zeit der
Erstellung dieses Dokuments). Die theoretische Rechenleistung dieser Lösung ist sehr
hoch – die Entwicklung von Algorithmen, die für GPUs optimiert sind, kann jedoch sehr
aufwändig sein.
5
5.1
Zukunftsaussichten und Hoffnungen
Verwendung der PlayStation 3 GPU
Leider ist es noch immer nicht möglich, auf die integrierte nVidia RSX Grafikkarte
zuzugreifen. Die Verwendung der GPU wird durch den Hypervisor, der zwischen das
installierte Linux und die PlayStation 3 Hardware geschalten ist, verhindert. Es gab
bereits ein paar seltene Erfolge, welche aber mit der Version 2.10 der PS3 Firmware wieder
zunichte gemacht wurden. Sony schafft es bisher erfolgreich einen Zugriff zu verhindern,
da sie sich durch eine 3D-Beschleunigung innerhalb des alternativen Betriebssystems
einen starken Rückgang beim Spieleverkauf erwarten.
7