Sämtliche Beiträge des Monats Dezember 2008
Good-bye 2008 und Willkommen, 2009!
Quelle: pixelio.de
Was macht man als guter Blogger am letzten Tag des Jahres?! Genau, man hält Rück- und Vorschau. Also, was war und was kommt alles auf uns zu.
Retrospektiv lässt sich erst mal eine Zahl nennen: 50. So viele Beiträge haben wir hier nämlich seit 20. Oktober verfasst, also seit dem Geburtstag des Software Dev Blogs. In diesen 5×10 Artikeln ging es vor allem um eine Thema: Wie holt man als Anwendungsentwickler das Optimum aus seiner Software heraus, damit sie auf Multicore-Plattformen wie dem Core i7 von Intel am besten läuft.
Daher haben wir uns natürlich die passenden Tools angesehen, die man für das Optimieren der Multithread-Software einsetzen kann. Dazu zählen: der Parallel Composer, für den man sich immer noch als Beta-Tester anmelden kann; der Thread Checker zum Aufspüren von Fehlern im Parallel-Code; Software-Bibliotheken zum Optimieren von bestehendem oder neuem Quellcode; Threading Building Blocks zum parallelen programmieren; C++- und Fortran-Compiler mit hohem Multicore-Potenzial und VTune Performance Analyzer zum Aufspüren von Schwachstellen im Quellcode.
Zwischendurch waren wir auf der Microsoft Tech-Ed Developers 2008 in Barcelona, um vor Ort mit Intel-Spezialisten über das Thema Multicore-Programmierung Videochats zu führen, aber auch um mit Steve Teixeira von Microsoft über die Redmonder Bemühungen hinsichtlich paralleler Programmierung zu reden.
Optimierte Parallel-Programmiersprachen braucht das Land
Gerade habe ich auf Technologyreview.com einen sehr interessanten Artikel zum Thema Multicore gefunden. Bereits sein Untertitel zeigt, worunter die Multicore-Programmierer derzeit am meisten leiden:
We need languages that take full advantage of multicore processing
Genau darum geht es heute. Nicht die Hardware ist der Hemmschuh, sondern die Software, sprich die Programmiersprachen, die derzeit zur Verfügung stehen. Oder wie es der Autor passend formuliert:
Computer evolution, however, is now headed down an entirely new path: instead of simply becoming faster, our computer processors are being conjoined to work together. That new computer architecture requires a serious evolution in computer programming. Without it, we can only scratch the surface of what multicore computing can really do.
Das ist die Kernthese, mit der sich auch dieses Blog immer wieder beschäftigt, denn die Zeiten der GHz-Spirale sind endgültig vorbei, und eine neue Ära des “Parallel Computing” ist angebrochen – sogar im Mainstream-Markt. Denn was die HPC-Gemeinde seit Jahren vormacht, ist auf dem gemeinen Desktop-PC und Notebook jetzt auch möglich, wird nur zu selten richtig eingesetzt.
Eine weitere interessante These stellt der TR-Artikel in Sachen “Umdenken” auf: So wie seinerzeit diverse Software-Entwickler den Trend der objektorientierten Programmierung verschlafen haben, droht heute die Gefahr erneut, da das Schreiben von parallel-orientiertem Sourcecode ebenfalls einen völlig neuen Denkansatz erfordert. Dies betrifft vor allem den gemeinsamen Zugriff auf Daten, dessen Koordinierung in parallelen Systemen bedeutend anspruchsvoller ist als im seriellen Universum.
Buchtipp: Multicore-Programmierung lernen mit Intel
Für alle, die sich mit dem Thema Multicore-Programmierung autodidaktisch auseinandersetzen wollen, haben wir heute einen Buchtipp: “Multicore-Programmierung” von Shameem Akhter und Jason Roberts. Für alle, die mehr auf das Original stehen, sei das Buch in Englisch bei Amazon empfohlen (54,90 Euro, ISBN-10: 3939084700) oder die deutsche Übersetzung “Multicore-Programmierung”, die es bei Entwickler.press für denselben Preis zu kaufen gibt.
Das Buch ist unterteilt in elf Kapitel, die sich allesamt mit dem Thema Multicore-Programmierung und Multithreading beschäftigen. Im ersten Abschnitt geht es zunächst um die Grundzüge von Multicore-Architekturen und die Frage, was das Amdahlsche Gesetz mit dem Ganzen zu tun hat.
Kapitel Nummer 2 betrachtet Threads im Speziellen und zeigt, wo sie eine Rolle spielen und wie hier die Virtualisierung ins Spiel kommt. Der dritte Teil des Buches erläutert dann, wie ein Programm in Threads zerlegt werden sollte, um ein Höchstmaß an Parallelität in die Anwendung zu implementieren.
Anschließend geht es ans Eingemachte: Shameem und Jason betrachten die einzelnen Schritte, die bei der Multithread-Programmierung anfallen, also die Synchronisierung von Daten und Aufgaben, und erklären auch, wie Deadlocks entstehen und wie man diese vermeidet. Kapitel fünf und sechs widmen sich den Threading-Modellen, also den Windows- und POSIX-Threads sowie OpenMP, die wir auch schon betrachtet haben.
BASTA! Spring 2009: C#4.0, Visual Studio 2010 und mehr
Software & Support Media gibt einen Tag vor Heilig Abend feierlich bekannt: Die BASTA! Spring 2009 findet im kommenden Frühjahr vom 23. bis 27. Februar in Darmstadt statt. Schwerpunkte der Entwicklerkonferenz werden unter anderem sein: Windows Azure, Windows 7, Oslo, C# 4.0, Visual Studio 2010 und dynamische Sprachen.
Natürlich wird es wieder ganz viele Tipps & Tricks rund um das Thema .NET geben. Darüber hinaus geht es auf der BASTA! um das Thema parallele Programmierung. Dafür werden schon alleine die VS 2010-Sessions sorgen.
Für den Blick hinter die Kulissen hat Software & Support Media wieder ganz viele Experten eingeladen, die mithilfe anschaulicher Beispiele und “Best Practices” .NET näher bringen wollen. Zu diesen Fachleuten gehören beispielsweise Christian Binder (Microsoft), André Krämer (CSC), Neno Loje (AIT), Peter Nowak (T-Systems) und Dr. Holger Schwichtenberg (IT-Visions).
Neben den geplanten Vorträgen wird es parallel zur BASTA! vier Themenspecials geben, die sich mit C#, SharePoint, Architekturen und Visual Basic beschäftigen werden. Daneben besteht die Möglichkeit, anhand der angebotenen Sessions und Workshops sein ganz individuelles Konferenzprogramm zusammenzustellen.
Die Tech-Sessions sind in unterschiedliche Technologie-Tracks gegliedert und dauern jeweils 75 Minuten. Außerdem können in ganztägigen “Power-Workshops” spezielle Themen sehr detailliert besprochen und vertieft werden. Sämtliche Konferenzinhalte können bereits heute online abgerufen werden.
Preistipp: Wenn Sie sich bis zum 22. Januar 2009 für die BASTA! Spring 2009 anmelden, können Sie als “Early Bird” richtig Geld sparen. Also, worauf warten Sie noch?!
Beliebte Fehler bei der Parallelprogrammierung
Parallelprogrammierung ist keine einfache Disziplin und birgt eine Menge Fehlerquellen. Das beginnt beim grundsätzlichen Design der Anwendung und endet bei falsch gesetzten “Locks”. Daher folgen an dieser Stelle die beliebtesten Fehler der Multicore-Programmierung. Und was man dagegen tun kann, erfahren Sie hier auch.
Zunächst einmal helfen unsere fünf Multicore-Regeln, die wir Ende letzten Monats aufgestellt haben. Die wichtigste davon lautet beim Software-Design: Denke parallel! Denn nur so hält man am Schluss eine Anwendung in den Händen, die sich mithilfe der passenden Tools bestmöglich parallelisieren lässt.
Eine beliebte Fehlerquelle ist ein Überangebot an Threads, vor allem dann, wenn Sie diese “manuell” programmieren, so wie im Falle von Pthreads. Daher sollte man durchaus sparsam mit dem Erstellen von Threads umgehen, denn nur eine ausgewogene Balance von parallelem und seriellem Quellcode bringt die erwünschten Leistungsschübe. Oder man bedient sich nützlicher Tools wie Intel TBB, die Threads automatisch generieren.
Mac OS X 10.5 (Leopard) fährt voll auf Multicore ab
J, ja, es ist schon ein paar Tage her, dass Mac OS X 10.5, auch bekannt als Leopard, das Licht der Welt erblickt hat. Aber ich habe gerade ein paar sehr interessante Details bezüglich der Multicore-Affinität des Apple-Betriebssystems entdeckt. Und so richtig viel darüber habe ich im Web nicht gefunden.
Hardware-seitig bietet Apple ja mit dem Mac Pro die volle Mehrkerntechnik von Intel: Acht Prozessorkerne beschleunigen vor allem die Bild- und Videobearbeitung, aber auch für Apple-eigene Anwendungen ist der Intel Xeon Prozessor, eine Quadcore-CPU mit maximal 3,2 GHz, nützlich.
Von dieser Mehrkern-Architektur profitieren unter anderem Programme wie Mail, das Adressbuch und die Verwaltung der Schriftensammlung, indem anfallende Aufgaben auf die vorhandenen Ressourcen möglichst optimal verteilt werden. Darum kümmert sich übrigens die neu programmierte Ablaufsteuerung von Leopard.
In Sachen Netzwerk hat sich Apple ebenfalls Gedanken gemacht: So wurde ein multithreading-fähiger Netzwerkstapel implementiert, der die Ein- und Ausgabeanfragen des LANs schneller verarbeiten kann. Außerdem wurde die indizierte Suchfunktion Spotlight beschleunigt, genauso wie die Wörterbuchfunktion von Mac OS X 10.5. Dies hat vor allem mit der objektorientierten API Cocoa zu tun, die ebenfalls für den Multicore-Betrieb optimiert wurde.
Optimierte Compiler helfen beim Parallelisieren
Auf dem Software Dev Blog war schon von diversen Entwickler-Tools die Rede, die Programmierern beim Erstellen multicore-tauglicher Anwendungen helfen sollen. Ob das die Threading Building Blocks sind, der Thread Checker, Hochleistungsbibliotheken oder der VTune Performance Analyzer – stets geht es darum, das Optimum aus seiner Software herauszuholen, falls diese auf Multicore-Plattformen möglichst gut skalieren soll.
Wie aber sieht es mit den fundamentalen Tools aus, die bei der Programmierung an erster Stelle stehen, also etwa den Compilern, mit denen sich der Quellcode in eine ausführbare Anwendung verwandeln lässt? Nun, auch hierfür gibt es multicore-optimierte Lösungen, die sich vor allem an C++- und Fortran-Programmierer richten. Das Ganze gibt es sogar als komplettes Entwicklerpaket, das neben dem C++-Compiler die TBB-Suite umfasst, die Integrated Performance Primitives und die Math Kernel Library.
Praktisch an dem Intel C++-Compiler für Windows sind vor allem zwei Dinge: Zum einen lässt er sich direkt in Visual Studio einbinden, was das Kompilieren innerhalb der gewohnten Umgebung ermöglicht. Und zum anderen ist der Compiler für Multicore-Plattformen optimiert. Das bedeutet, dass der Quellcode auf mögliche Parallelitäten hin untersucht wird. Findet der Compiler entsprechende Programmabschnitte, fügt er automatisch die passenden Konstrukte und Funktionen ein, die den seriell programmierten Abschnitt parallelisieren.
Neu an der Version 11 des Intel C++-Compilers sind übrigens unter anderem die eingebauten Lambda-Funktionen, OpenMP 3.0 und die Unterstützung von dezimalen Fließpunktoperatoren und -registern. Und natürlich gibt es die Intel Compiler auch für Linux (inklusive Eclipse-Unterstützung) und für Mac OS X (in Verbindung mit XCode).
Mit Intel Threading Building Blocks parallel programmieren
Über die Intel Threading Building Blocks haben wir schon das ein oder andere Mal berichtet, aber eine gründliche Betrachtung stand bisher noch aus. Bisher!
Die Intel TBB lassen sich in sechs fundamentale Einzelteile zerlegen:
1. Algorithmen
2. Container
3. Memory Allocator
4. Mutual Exclusion
5. Timer
6. Task Scheduler
1. Die TBB-Algorithmen richten sich vor allem an parallel ausführbare Schleifenkonstrukte, aber auch Sortieralgorithmen lassen sich mithilfe der TBB recht problemlos parallelisieren. Die zugehörigen Funktionen nennen sich parallel_for, parallel_reduce, parallel_scan, parallel_while, parallel_pipeline und parallel_sort. Eine genauere Betrachtung dieser Funktionen findet auf dem Software Dev Blog in einem späteren Beitrag statt.
2. Die Intel TBB setzen sich aus drei Containern zusammen: queue, vector und hash table. Diese Container findet man zwar auch in den Standard Template Libraries von C++ und Fortran, diese sind allerdings weniger thread-sicher als die der Intel TBB.
3. Der Memory Allocator der Intel TBB ist äußerst skalierbar und daher in der Lage, gemeinsam genutzten Speicher auf mehrere Threads so zu verteilen, dass sich diese nicht gegenseitig behindern. Damit kümmert sich der Allocator der TBB um das gleichzeitige Ausführen der wichtigsten Funktionen wie malloc, new und delete.
4. Die Mutual Exclusions der Intel TBB kümmern sich um konsistente Daten bei der Ausführung paralleler Funktionen. Es geht also um das Sperren und Freigeben von Daten (Lock und Unlock) während der Ausführung verschiedener Threads. Somit ist gewährleistet, dass sich Threads bei der Manipulation von Daten nicht ins Gehege kommen, was zu richtigen Ergebnissen führen soll.
5. Die in den Intel TBB implementierte Timing-Funktion – also das Ermitteln der Programmdauer per Subtraktion zweier Uhrzeiten – ist für viele Entwickler ein wichtiger Aspekt. Von Bedeutung dabei ist aber auch ein Ergebnis, auf das man sich selbst dann verlassen kann, wenn der zugehörige Thread auf mehreren Prozessorkernen parallel ausgeführt wird.
6. Eine Kernfunktion der Intel TBB ist der Task Scheduler, der die Vielzahl unterschiedlicher Aufgaben, die mithilfe der Algorithmen aus Punkt 1 definiert werden, auf die vorhandenen Threads, also Prozessorkerne, optimal verteilt. Um dies zu garantieren, beherrscht der Task Scheduler das Load Balancing, was dazu führt, dass parallele Aufgaben möglichst effizient von den vorhandenen CPU-Cores ausgeführt werden. Folge: Maximale Performance der Anwendung!
Von Single-Threading bis zur Multicore-Programmierung
Betrachtet man die Evolution der Programmiermethoden der letzten Jahre, hat sich hier viel getan. Über Jahrzehnte hinweg galt die sequenzielle Programmierung (mal abgesehen von den HPC-Jungs) als konform und anerkannt. Jede Aufgabe, die es zu programmieren galt, wurde streng linear ausgeführt und erforderte daher keine parallelen Ansätze.
Mit der Einführung neuer Betriebssysteme wie Microsoft Windows und besserer Prozessoren wie dem Intel Pentium MMX standen auf einmal im Desktop-Segment ganz neue Möglichkeiten zur Verfügung: Mit Multitasking konnten zeitversetzt von einem Prozessor mehrere Aufgaben anscheinend gleichzeitig erledigt werden. Und das Multithreading erlaubte es dank neuer Befehlssätze (SSE), Daten gleichzeitig zu verarbeiten, wenn diese keine Abhängigkeit zueinander aufwiesen. Dazu gehört auch die SIMD-Architektur, die beispielsweise gleichartige Operationen in großen Integer-Registern parallel ausführen kann.
Dann wurde mit dem Intel Pentium 4 HT der erste Prozessor für den Verbrauchermarkt vorgestellt, der auf Basis der Hyperthreading-Technik zwei Aufgaben gleichzeitig in einem Prozessorkern ausführen konnte. Dies ermöglichte ganz neue Anwendungen, da deutlich mehr Rechenleistung auf Standard-PCs zur Verfügung stand. Die HT-Technik wird auch als simultanes Multithreading bezeichnet.
Mit dem Aufkommen von Dual- und Quadcore-Prozessoren im Massenmarkt ließen sich erstmals Anwendungen zur Laufzeit in unterschiedliche Aufgaben zerlegen, die dann auf mehreren CPU-Cores gleichzeitig, also parallel, verarbeitet werden können. Dies erfordert allerdings von den Software-Entwicklern sehr viel mehr Denkarbeit, um ein Programm von Haus aus parallel zu entwickeln. Zudem sollte er auf Software-Tools setzen, die ihn bei der parallelen Programmierung so gut wie nötig und möglich unterstützen.
Vier Schritte zum optimierten Multicore-Quellcode
Wir haben uns hier ja schon mit den Regeln der parallelen Programmierung beschäftigt und sind auch der Frage nachgegangen, welche Tools hierfür zur Verfügung stehen. Heute geht es um die vier wesentlichen Schritte, die zur Erstellung des optimalen Multicore-Codes notwendig sind.
1. Untersuche! Und zwar den gesamt Quellcode auf potenzielle Parallelisierung hin. Hierfür eignen sich vor allem Schleifenkonstrukte, die beispielsweise eine große Menge an Daten berechnet, was oft simultan geschehen kann. Es geht aber auch um “Hotspots”, die es in jedem Programm gibt und die die Leistungsfähigkeit der Anwendung negativ beeinträchtigen können. Um diese Untersuchungen möglichst effizient durchzuführen, gibt es spezielle Tools wie den VTune Performance Analyzer, der genau für diese Aufgaben geschaffen worden ist.
2. Kodiere! Und zwar parallel. Nachdem die passenden Programmstellen identifiziert worden sind, beginnt die eigentliche Arbeit, nämlich die des Kodierens. Packen Sie also all den parallelen Code in Ihr Programm, von dem Sie glauben, dass er Ihre Anwendung schneller macht, da sie von den vorhandenen Prozessorkernen profitiert. Und Sie können es sich dabei ein wenig leichter machen, indem Sie auf Tools zurückgreifen, die Ihnen mithilfe vorgefertigter Routinen und Bibliotheken dabei helfen. Dies können einfache Anweisungen paralleler Schleifenkonstrukte sein, aber auch komplexe Funktionen für Multimedia- oder Wissenschaftsanwendungen.
TU München verstärkt ihr Multicore-Engagement
Erst am Freitag habe ich mich mit der Frage beschäftigt, warum in diesem Land zu wenig Geld und zu wenig Ressourcen in Sachen Multicore-Ausbildung gesteckt werden. Allerdings setzen einige Universitäten und Fachhochschulen bereits auf die Mehrkerntechnik und haben ihre Lehrpläne dahingehend optimiert.
So wie die TU München, die schon seit längeren mit Intel in Sachen Multicore-Programmierung zusammenarbeitet. Hierzu habe ich auf Blip.tv ein sehenswertes Video mit Professor Doktor Arndt Bode gefunden, dem Vizepräsidenten der Technischen Uni zu München.
In diesem sechsminütigen Videochat erfährt man diverse aufschlussreiche Dinge:
- Nicht nur Informatikstudenten sollten sich mit dem Thema Multiprozessor-Architektur beschäftigen, sondern auch die anderen Fakultäten. Und klar, programmieren für mehrere CPU-Kerne sollten sie auch können.
- Steigerungsraten in Sachen Rechenleistung lassen sich nur noch mithilfe mehrerer Prozessorkerne erzielen und der damit einhergehenden Threads, die parallel verarbeitet werden können. Denn die Zeiten der Gigahertz-Mania sind endgültig vorbei (sic!).
Software-Projekte mit Multicore-Bibliotheken optimieren
Gerade auf Entwickler von Multimediaanwendungen wartet ein großes Optimierungspotenzial in Sachen Multicore-Programmierung. Ein gutes Beispiel sind Videoschnittprogramme wie PowerDirector 7 von CyberLink, in denen ein hohes Maß an Datenparallelität steckt, da beispielsweise beim Rendern sämtliche Bildpunkte simultan manipuliert werden können.
Wie gut, dass es für die Parallelisierung solcher Anwendungen die passenden Tools gibt, die Intel unter dem Begriff „Performance Libraries“, also Hochleistungsbibliotheken, anbietet. Dazu gehören die schon besprochenen Intel Threading Building Blocks, aber auch spezielle C++-Bibliotheken namens Intel Integrated Performance Primitives (Intel IPP) und Intel Math Kernel Library (Intel MKL).
Die Intel IPP wenden sich an all diejenigen, die programmierseitig viel mit En- und Dekodern für Audio- und Videoinhalte zu tun haben, aber auch mit Datenkompression, Spracherkennung und Bildbearbeitung. Für all diese (und weitere) Anwendungen bieten die Intel IPP nämlich die passenden Bibliotheken, die sich mit wenig Aufwand in das eigene Softwareprojekt integrieren lassen. Man muss ja schließlich das Rad nicht jedes Mal neu erfinden. Außerdem kann man sicher sein, dass die IPP in höchstem Maße multithreaded sind.
Ausbildungslücken bei der Multicore-Programmierung
Ein Interview auf Elektroniknet.de brachte mir eine fundamentale Erkenntnis: Die Multicore-Programmierung findet offensichtlich noch in einem zu geringen Ausmaß statt, da es nicht an Entwicklertools fehlt, sondern an Entwicklern, die damit umgehen können. Diese Theorie stellt zumindest Professor Klaus Kißig von der FH Kiel auf. Seine Kernthese dürfte die Ohren diverser Kollegen und Dekane anderer Bildungseinrichtungen zum Klingeln bringen:
Das Problem ist eher, dass es zu wenige Leute gibt, die die Kenntnisse haben, um diese Compiler effektiv anzuwenden und die Hardware optimal ausnutzen können.
Mit „diese Compiler“ meint er unter anderem Intel-Compiler, die ständig weiterentwickelt werden. Aber auch den Einsatz von OpenMP in Verbindung mit Standard-Compilern sieht er in diesem Kontext als großen Vorteil.
Das bedeutet also, dass es vor allem bei der Ausbildung hakt, da es die jeweiligen Einrichtungen bis dato offensichtlich noch nicht geschafft haben, neue Techniken wie Multicore-Systeme in den Vorlesungsplan zu integrieren.
Crysis und Sacred 2 räumen beim Entwicklerpreis 2008 ab
Gestern Abend fand in Essen die Verleihung des Deutschen Entwicklerpreises 2008 in Sachen deutsche Computerspiele statt. Dabei konnten zwei Spieletitel gewinnen, die nachweislich für Multicore-Plattformen, aber auch für Notebooks optimiert wurden: Crysis der deutschen Entwicklerschmiede Crytek aus Frankfurt am Main sowie Sacred 2 – Fallen Angel, für das Ascaron zuständig ist.
Dass sich die Multithread-Optimierung für Crytek ausgezeichnet hat, zeigen auch die weiteren Preise in den Kategorien „Bestes Gamedesign“ und „Beste Spielegrafik“. Aber wie haben die das bloß gemacht?
Nun, sowohl im Falle von Crysis als auch Sacred haben beide Entwicklerfirmen ganz eng mit Intel zusammengearbeitet, um eine möglichst hohe Multicore-Optimierung hinzubekommen. So haben die Spieleentwickler von Crytek es geschafft, die unterschiedlichen Aufgaben wie das Rendering, die physikalischen Effekte wie Wind und Wasser und die Soundeffekte auf unterschiedliche Prozessorkerne zu verteilen, was die CPU extrem gut auslastet und damit für noch mehr Realismus und einen hohen Detailgrad sorgt.
Darüber hinaus haben sich die Entwickler von Crytek des Intel Laptop Gaming TDK bedient, das mit relativ wenig Aufwand beispielsweise das Einbinden einer Batterieanzeige in der Spielumgebung ermöglicht. Damit hat man als Notebook-Gamer stets die Restlaufzeit des Akkus im Auge. Mehr dazu gibt es übrigens in diesem Video.
Programmiermethoden: Daten- und Aufgabenparallelität
Bei der parallelen Programmierung unterscheidet man grundsätzlich zwischen drei Formen, die letztlich darüber entscheiden, welche Programmiermethoden man anwenden sollte.
Die eine Form der parallelen Programmierung orientiert sich an den zu verarbeitenden Daten, die zur Laufzeit der Anwendung anfallen. Ein gutes Beispiel für die Datenparallelität ist das Rendern eines Bildes, das aus vielen tausend Bildpunkten besteht, die sich unabhängig voneinander berechnen, zeichnen oder mit einem Filter versehen lassen.
Darin steckt also eine Menge an Multicore-Potenzial, wofür sich der Einsatz von OpenMP oder Intel TBB empfiehlt. Ein weiteres gutes Beispiel ist die Rechtschreibprüfung eines Textverarbeitungsprogramms. Hier können sämtliche Wörter simultan überprüft werden, da sie zueinander in keiner Abhängigkeit stehen.
Auf der anderen Seite existiert der Aufgabenparallelismus, der voneinander getrennte Aufgaben betrachtet, die sich vortrefflich parallel ausführen lassen. Ein gutes Beispiel hierfür ist Outlook, das aus unterschiedlichen Modulen besteht (Adressen, Kalender, E-Mail etc.), die sich grundsätzlich unabhängig voneinander ausführen lassen und damit auf separaten Prozessorkernen laufen können.
PowerDirector 7 ist für Core i7-Prozessor optimiert
Es ist jetzt gerade mal zwei Wochen her, dass Intel den Core i7 Prozessor vorgestellt hat, und schon erreicht uns heute eine E-Mail von Cyberlink, dass der taiwanesische Software-Hersteller sein Videoschnittprogramm PowerDirector 7 für den Quadcore-Prozessor optimiert hat.
Das bedeutet primär, dass die Videobearbeitung dank der acht gleichzeitig ablaufenden Threads auf den vier Prozessorkernen einen enormen Leistungssprung erfährt. Darüber hinaus profitiert PowerDirector 7 von der Intel QuickPath-Technologie und dem 8 MByte großen L3-Cache des Core i7 – für noch mehr Tempo beim Videoschnitt.
Der Quadcore-Prozessor ist unter anderem dafür verantwortlich, dass das Vorschau-Rendering schneller geschieht als auf herkömmlichen Quadcore-Rechnern, dass Effekte schneller verarbeitet werden und dass sich optische Medien noch schneller brennen lassen. So ist beispielsweise ein HD-Video, das mit dem rechenintensiven Pencil-Sketch-Effekt versehen wird, in weniger als einer Minute vollständig gerendert. Auf einem Core 2 Quad Q9550 benötigt derselbe Rechenaufwand zwei Minuten. Fazit: Die Wartezeit lässt sich mit dem Core i7 locker halbieren.
Wem diese Infos ein wenig zu dünn sind, der kann sich schon mal auf mehr freuen. Wir wollen nämlich auch wissen, an welchen Stellen Cyberlink Code-Optimierung vorgenommen hat und welche Tools hierfür zum Einsatz gekommen sind. Sobald wir diese Details vorliegen haben, gehen diese online. Versprochen!
Ach ja: Wer mehr zu PowerDirector 7 lesen will, kann dies auf der passenden Webseite tun.
Apple Mac OS X 10.6 mit hohem Multicore-Potenzial
John Hubbard scheint ein ziemlich kluger Kopf zu sein. Denn erstens beschäftigt er sich bei Apple als Director of Unix Technologies mit sehr komplexen und ernsthaften Dingen. Und zweitens hat er Mitte November auf einer Konferenz in San Diego bemerkenswerte Dinge über Intel und Multicore gesagt. Beispiele gefällig?
Forget everything you thought you knew about multi-threaded programming (and, as it turns out, most developers didn’t know much anyway).
The kernel is the only one who really knows the right mix of cores and power states to use at any given time – this can’t be a pure app-driven decision.
We need new APIs and mechanisms for dealing with this incoming meteor.
Wie gut, dass sich Intel über Letzteres bereits Gedanken macht und Tools wie Intel TBB und Intel Parallel Studio bietet, mit deren Hilfe die Multicore-Programmierung deutlich erleichtert werden kann.
Weniger schlau während seines Vortrags war allerdings die Folie Nummer 5, auf der er (ganz inoffiziell natürlich) den Erscheinungszeitraum der nächsten OS-X-Version 10.6 aka Snow Leopard bekannt gegeben hat, nämlich das erste Quartal 2009. Anfang Juni während der Apple-Entwicklerkonferenz WWDC’08 war noch von ungefähr einem Jahr die Rede, bis Mac OS X 10.6 in die Läden kommt. Tja, dumm gelaufen!
Und was hat das alles mit Multicore-Programmierung zu tun? Nun, in der nächsten Version des Apple-Betriebssystems wird ganz viel Multicore-Unterstützung stecken. Leider gibt Apple noch nichts Konkretes raus (und John leider auch nicht), aber einige grundsätzliche Dinge sind heute schon klar:
