Rechnerarchitekturen und Betriebssysteme (CS201): UMA/NUMA, software-morphing CPUs Cell-CPU, Intro Betriebssysteme

Transkript

1 Rechnerarchitekturen und Betriebssysteme (CS201): UMA/NUMA, software-morphing CPUs Cell-CPU, Intro Betriebssysteme 24. Oktober 2014 Prof. Dr. Christian Tschudin Departement Mathematik und Informatik, Universität Basel Wiederholung / Diskussion 1. Was ist eine Pipeline innerhalb einer CPU? 2. Was ist eine skalare/superskalare CPU? 3. Was ist mit Very Long Instruction Word (VLIW) gemeint? 4. Was ist Hyperthreading? c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 2/43

2 Uebersicht Schluss von Moore s law UMA NUMA Crusoe-Prozessor Cell-Prozessor Intro zu Betriebssystemen Tiny-OS (micaz) c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 3/43 UMA und NUMA Bisher gesehen: 1 N CPU-Kerne, mit 1 Memory (für Daten, ev sep. Codespeicher). Andere Speicherarchitekturen für Multiprozessoren? UMA Uniform Memory Architecture 1 gemeinsamer Speicher für alle Cache möglich, ist aber transparent viel Hardwareaufwand, einfache Programmierung Multi-Core sind typischerweise UMA NUMA Non-Uniform Memory Architecture Prozessor hat lokale Speicherkopie, vermeidet Bottleneck Problem der Konsistenz zwischen den Daten-Kopien c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 4/43

3 Beispiel zu UMA vs. NUMA Graphik-Prozessor macht heutige PCs zu Mehrprozessoren-Syst. Wie sieht es mit dem Speicher aus? c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 5/43 Der Transmeta CRUSOE Prozessor Firma Transmeta (Californien), 1995 gegründet, arbeitete jahrelang versteckt, Oeffentlichkeit ab 1999 Transmeta hatte berühmte Leute angestellt Linus Torwalds (Linux) Dave Taylor (Quake) 2000 Crusoe CPU mit Software Morphing 2003 Efficeon (nächste Generation) 2005 nur noch Lizenzierung der Patente Sept 2008: Transmeta bietet sich selbst zum Verkauf an c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 6/43

4 Zitate aus Transmetas Info-Material We rethought the microprocessor The first software-based microprocessor The first microprocessor whose instruction set is implemented entirely in Software. Huh? c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 7/43 Transmetas Ausgangspunkt RISC ist nicht mehr simple, enorme Chip-Komplexität: riesige Entwickler-Teams lange Entwicklungs-Zyklen Geschwindigkeitsrausch entspricht nicht den Anforderungen von mobilen Geräten (mehr Geschwindigkeit = mehr GhZ = mehr Energieverbrauch) Ziele: einen einfachen, sauberen und schnellen Chip x86-kompatibilität durch Software low-power ist zentral c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 8/43

5 Chip Facts (erste Crusoe Generation) Chip-Grösse (2000): < 80 mm 2 (mobile P-II: 180 mm 2 ) Clock: MHz Power: ca. 1 Watt Proprietäre ISA (Instruction Set Architecture) very long instruction words (128 bits, Efficeon: 256 bits) 7-stufige Pipeline für Integer-Operationen Chip beinhaltet: MMU, Interface für PCI und RAM bus Adaptiver Spannungspegel und Taktrate: HW entdeckt idle -Perioden, reduziert Taktrate c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 9/43 Crusoe s VLIW Instruktionen sind 128 Bits weit Ein 128-Bits-Wort wird Molekül genannt Ein Molekül enthält bis zu 4 Atome c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 10/43

6 Code Morphing Software (> 8 MBytes gross) Wie mit VLIW und propr. ISA die x86-kompatibilität erbringen? x86 interpreter loop : hole X86-Befehl, erzeuge entspr VLIW Worte, wiederhole! Der Interpreter ist in Crusoe VLIW-Befehlen geschrieben. c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 11/43 Wie kann (fast) Pentium-Geschwindigkeit erreicht werde? Interpretation ist immer langsam (die Analyse und Emulation eines x86-befehls braucht mehrere VLIW Worte). Amortisierte Interpretation durch Erinnern der Analyse Uebersetzung wird in einem Cache abgelegt Spezielle HW erkennt ganze x86-code-sequenzen und lokalisiert die entsprechende Uebersetzung im Cache Konsequenz: langsamer Start bis Cache einige Uebersetzung gespeichert hat nachher kein Overhead mehr (für gleiche Codesequenzen) c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 12/43

7 Vergleich EPIC/Merced und Crusoe Intel Merced (VLIW) x86 Kompatibilität durch x86 hardware box alter x86 Code: Superscalar (HW Logik, um feingranularer ILP zu erkennen) Merced VLIW Code: Instruction scheduling zur Kompilationszeit, d.h. man muss alten x86-code neu uebersetzen! Crusoe (VLIW) x86 Kompatibilität durch Code- Interpretation x86 Interpreter (Software für Code-Uebersetzung) Crusoe VLIW Code: Instruction scheduling zur Lauf- /Uebersetzungszeit, keine Rekompilation nötig. c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 13/43 Coole Sachen mit dem Crusoe Hole Dir Deine CPU via das Internet! Prinzipiell liesse sich die Morphing Software versenden Beispielweise: erhalte einen Prozessor per . Aehnliche der ganz frühen Micro-Programmierung bei den IBM Mainframes und VAX-Maschinen In Theorie könnte auch zu einem PowerPC CPU (Mac) gemorpht werden. In der Praxis wohl schwierig, weil x86-spezifische HW-Tricks nötig waren. c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 14/43

8 Transmeta: Patente statt Chips Okt 2006: Klage gegen Intel wegen Patentverletzung 24. Okt. 2007: Intel gibt klein bei, zahlt Lizenzgebühren (Heise) Intel legt Patentstreit mit Transmeta bei Chiphersteller Intel legt seinen Patentstreit mit dem Chipdesigner Transmeta gegen Zahlung von insgesamt 250 Millionen US-Dollar bei. Im Rahmen des Abkommens, das Transmeta am heutigen Mittwoch bekannt gab, zahlt Intel einmalig 150 Millionen US-Dollar und jährlich jeweils 20 Millionen US-Dollar für die kommenden fünf Jahre. Transmeta hatte den Chipgiganten im vergangenen Oktober verklagt, woraufhin Intel Anfang des Jahres mit einer Gegenklage reagierte. Diese wird das Unternehmen ebenfalls zurücknehmen. Im Gegenzug erhält Intel nicht-exklusive Lizenzen für alle von Transmeta gehaltenen Patente. c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 15/43 Cell-Prozessor Gemeinsame Entwicklung von IBM, SONY und TOSHIBA Seit 2001 in Arbeit, Februar 2005 vorgestellt 10 Times the Performance of the Latest PC Processors RISC-Revival (wie Transmeta), neue Kombination Performance: 25 gigaflops double precision 256 gigaflops single precision Ende 2009: Entwicklung einer 32-SPE-Version bei IBM gestoppt März 2011: Sony nutzt Cell-CPU für PS4 und Bravia-TV c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 16/43

9 Cell CPU-Chip 9 core -CPU: 1 Haupt-CPU (PPC), 8 kleine Vektor-ALUs (auch SPE, für Synergistic Processor Element) SPEs haben kein Cache; lokales RAM durch SW gesteuert Network on a chip (4 Ringe) Vision: externes Netzwerk bindet weitere Cells (PDAs etc) c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 17/43 Cell CPU-Architektur(Forts. II) Details zu den 8 Vektor-ALUs (SPE/ Synergistic Processor Element ) RISC 32-bit Instruktionen dual issue (2 Instr/Takt) SIMD 128 x 128-bit Register eigenes RAM Floating-Point lastig c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 18/43

10 Cell CPU-Architektur (Forts. III) Bekannte oder geplannte Anwendungen des Cell-Prozessor: Videogame-Konsolen Sony PlayStation 3 Home Cinema HDTV (Dekodierung von MPEG-2-Videostreams) Super-Computing, Blade server Koppelung mehrere solcher Broadband Engines (?) Linux unterstützt Cell ab Kernel (März 2006) Anspruch, gut für energieffizientete Supercomputer zu sein. c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 19/43 Cell-Prozessor Details siehe Slides von M. Perrone, insbesondere: Intro (Verschiedene Grenzen, die es zu überwinden gab) Anhang: Details zu SPE Blade-Rechner c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 20/43

11 Cell-Prozessor Bewertungen Cell ist eine Multi-Core CPU Typisch für RISC-Rechner: SW-Komplexität steigt Performance-Gewinn durch Parallelismus Programmierer muss Ressourcen zuteilen (was wo) Compiler-Unterstützung wird schwierig sein Beispiel: SPE rechnet nur im 256-KB-Speicher explizites Laden/Speichern vom Hauptspeicher (DMA) c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 21/43 Prozessoren für SmartPhones und Tablets Eigenschaften Heute im GHz-Bereich getaktet, mehrere Cores (Leistung mehrere ILLIAC-Rechner extreme Energieeffizienz, partielles Abschalten von Chip-Bereichen Interne Architektur wie bei Laptop- oder Desktop-CPUs Siehe Artikel zur A15-CPU-Architektur als Nachfolger von ARMs A9-Design (CHIP Juni 2012) c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 22/43

12 c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 23/43 In der Zukunft: Adiabatische CPUs? Das Schreiben einer 0 oder die Negation einer 1 benötigt (!) Energie. Ziel deshalb: Zustandsänderung ohne Wärmeverlust, wie bei einem Gas. Ansatz: 1 Bit durch zwei Drähte repräsentieren, jeweils einer führt Strom. Negation bedeutet hier: stromführenden Leiter wechseln. Oder durch Quantencomputer. Vergleich der Schaltkreise: Klassisch Adiabatisch Datum Bits (0, 1) Bits (0, 1) Zuweisung? Ja Nein Reversibel Nein Ja (!) Gatter AND, OR, NOT, CNOT, NOT CCNOT (Toffoli) c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 24/43

13 Ausblick Rechnerarchitektur Ziele: Verständnis für die Umsetzung des Prinzips eines Computers in Hardware Zusatzwissen: Assembler, Peripherie, Interrupts, etc Konkrete Anleitung in einfachem Umfeld (AVR), Erfahrung Einladung zum Weiterverfolgen neuer Entwicklungen c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 25/43 Betriebssystem DIN 44300: Unter einem Betriebssystem versteht man all diejenigen Programme eines digitalen Rechensystems, die zusammen mit den Eigenschaften dieser Rechenanlage die Basis der möglichen Betriebsarten des digitalen Rechensystems bilden und die insbesondere die Abwicklung von Programmen steuern und überwachen. c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 26/43

14 Aufgaben eines Betriebssystems Ressourcenverwaltung! Rechenzeit, Prozessverwaltung Speicher: Hauptspeicher sekundärer Speicher etc Ein-/Ausgabe, Interrupts Zugriffsrechte u.v.m. c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 27/43 Betriebssystem: Design-Richtlinien Wie Ordnung hineinbringen? z.b. Hardware-Abstraktion, Layering, Modularisierung Insbesondere für Portierbarkeit und Aufgabenteilung c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 28/43

15 Betriebssystem-Struktur Ein OS beinhaltet (meistens) alle Module der vorherigen Grafik Herausforderung: Welche Module? Wie untereinander organisieren? Schnittstellen? OS ist schwierige Software: umfangreich und komplex Nebenläufigkeit lange Lebensdauer, Weiterentwicklung Performance ist sehr wichtig c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 29/43 Entwicklung von Betriebssystemen, Linux Beispiel Linux-Kernel Source Code (ohne GNU-Tools!): Linux Version Jahr # Zeilen Grösse M M M M M M M M c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 30/43

16 Entwicklung von Betriebssystemen, Linux (II) c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 31/43 Monolithische Betriebssystem-Kerne Traditioneller Ansatz (Linux, BSD, Solaris, MSDOS): Umfasst alles zwischen Benutzerprogramm und Hardware. Vorteil: Interaktion zwischen Modulen ist einfach und effizient Nachtteil: schwierig zu über- und durchblicken schwierig, lokale Aenderungen durchzuführen schwierig zu unterhalten Stabilität (Fehler in 1 Modul kann ganzes System gefährden) Andere Strukturierung? c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 32/43

17 Layering, Beispiel THE -Betriebssystem Abstraktionsleistung: Jede Schicht realisiert einen Dienst THE-System von Dijkstra (1968) 5 Schichten: CPU scheduling, Speicherverwaltung, Konsole, Puffer, Benutzerprogramme System besteht aus (fester Anzahl) sequentieller Prozesse Ziel (und Eigenschaft): Jede Schicht unabhängig von der anderen testen. c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 33/43 TinyOS Hintergrund Sensor-Netzwerke: Erheben, Verarbeiten und Weiterleitung von Umweltdaten Extreme Einschränungen und Anforderungen KB Code, KB RAM keine Konsole (nur Drahtloskommunikation) batteriebetrieben, für Monate Unterschiedliche Hardwareumgebungen Portabilität von Software gewünscht Spezialisierte Anwendungen: Eine mit TinyOS realisierte Lösung muss/kann kein general purpose System sein case-by-case! c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 34/43

18 TinyOS Speicherarchitektur 1 Speicherbereich für das ganze System: globale Daten (der Module, inkl Anwendung) kein Heap, kein malloc, nur statische Speicherzuordnung gemeinsamer (!) Stack, für dynamischen Speicher c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 35/43 TinyOS Komponenten SW-Modell Unabhängige Module (Komponenten), einzeln programmiert Zwei Komponententypen: Module (Impl.) und Verdrahtungen; Aber von aussen gesehen gleich behandelbar (als Komponente) Statische Konstruktion der Gesamtsoftware durch Verdrahtung der Komponenten. Beinhaltet OS und Applikation Obere (und untere) Schnittstelle von Komponenten: jeweils empfangen von Commands (und Events) c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 36/43

19 Tinyos Komponentenhierarchie Commands / Befehle: fliesen von oben nach unten Kontrollfluss kehrt zum Caller zurück Events / Ereignisse (Upcalls): fliesen von unten nach oben Kontrollfluss kehrt zum Caller zurück Events können Commands aufrufen, aber nicht umgekehrt. Verdrahtung von Komponenten Benutzer/Lieferanten-Hierarchie c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 37/43 TinyOS Prozessmodell: Events und Tasks Events ähnlich Interrupts: zeitkritisch, kurze Dauer last-in-first-out (Preemption), keine Priorität Tasks ähnlich Prozessen: elastisch (Abarbeitung kann zeitlich gestreckt werden) keine Nebenläufigkeit von Tasks vollständige Abarbeitung bis freiwillige Abgabe der CPU (sog. run-to-termination) c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 38/43

20 TinyOS Programmiermodell Asynchroner Split phase -Aufruf: z.b. send msg() kann einige millisec dauern, Gewünscht: keine blockierende (synchrone) Aufrufe Deshalb: Befehl absetzen kehrt sofort zurück auf explizite Notifikation durch Event warten. Beispiel eines Interfaces (Auszug): char TOS_COMMAND(send_msg)(int addr,int type, char* data); // Event: char msg_send_done(char success); c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 39/43 TinyOS Programmiersprache TinyOS definiert neue Sprache. nesc: TinyOS-spezifische Variante von C Neue Schlüsselwörter für Komponenten und Verdrahtung Kein eigener Kompiler, aber ein Pre-Prozessor : überprüft SW-Eigenschaften (sog. Race Conditions ) erzeugt aus nesc gewöhnliches C aus dem C dann AVR-Binaries c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 40/43

21 TinyOS Anwendungen Anwendungen können (im Prinzip) nicht zur Laufzeit ausgewählt werden. OS und Anwendung werden zusammen compiliert (ein grosses C-File) Sensor hat nur 1 Anwendungen zu einem bestimmten Zeitpunkt Wechsel der Anwendung ( retasking ) bedingt ein neues Herunterladen des OS+Applik in den Sensor TinyOS ist dennoch als ein OS zu werten! c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 41/43 Tinyos AVR-Programmierung? Reprogrammierung (und installation/download) scheint für neue Anwendungen unumgänglich, falls: neue Dienste neue Komponenten für Hardware Variante analog zu Java: Virtuelle Maschine Maté Bytecode Interpreter implementiert Stackmaschine ist eine Tinyos-Komponente c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 42/43

22 TinyOS Maté 1-Byte-Befehle, Operanden meistens auf dem Stack Interpretierte Sprache Verlangsamung um Faktor 2 bis 30 Rechenzeit aber nicht limtierendes Element Code-Import via Funk durch Kapseln mit 24 Befehlen Fehlerhaftes Programm bringt TinyOS nicht zum Absturz Damit endet der TinyOS-Exkurs. c Christian Tschudin CS201 Rechnerarchitekturen und Betriebssysteme , 43/43