Intel bringt das Multicore-Problem in die Diskussion: In naher Zukunft soll es Prozessoren nicht nur mit 8 oder 16 Kernen geben, sondern mit Hunderten oder gar Tausenden. Die Software muss entsprechend angepasst werden, um diese Power zu nutzen.
Und das ist ziemlich komplex. Jedes Programm muss so entwickelt werden, dass es alle zur Verfügung stehenden Kerne nutzen kann. In einigen Fällen gibt es dafür bereits Lösungen: Raytracing soll zum Beispiel bestens skalieren und der nächste Knaller bei 3D-Spielen sein. Andere Algorithmen müssen erst noch entwickelt werden. Außerdem fehlt es noch an Tools, meistens werden nur Single Thread-Programme unterstützt.
In Zukunft reicht es also nicht mehr aus, einfach einen schnelleren Prozessor einzubauen, sondern die Software muss grundsätzlich anders entwickelt werden, um die Performance zu nutzen.
Das ist ja nun wirklich nichts neues, dass selbst Quad Core CPUs im Vergleich zu Dual Core CPUs z.T. langsamer sind, wenn die Anwendung nicht dementsprechend angepasst bzw. programmiert worden ist.
Tja, daher gibts bei mir kein QuadCore, da bleibt ich erstmal beim Dual.
Wer nicht gerade 4 rechenintensive Programme parallel laufen lässt, sondern so wie ich eine Sache macht hat für die Hintergrundprozesse noch einen Kern frei. :)
Finde ich eine sehr elegante Mischung, lieber 50% Aulastung eines Dual als 25% eines Quad, der Effektivität wegen.
ich finde das durchweg gut. Ich besitze einen Q6600. und ich kann sagen dass vier kerne nicht genug sind. zumindest bei meinem Anwendungsszenario(Videokodierung, Rendering und Compiling). Abgesehen davon unterstüzt ja bereits ein ganzer haufen Multicoring. Bei einigen Anwendungen geschieht das automatisch andere(wie zb VirtualDub) müssen erst dazu überredet werden
... und da hat eben IBM mit dem Power Prozessor und den Cell Prozessoren die Nase soweit was von vorne ... Da wird das weitgehend vom Betriebssystem und teilweise von den Compileren gehandhabt. Allerdings ist heute immer noch Computing für Erwachsene und hat nichts mit dem Desktop zu tun. Nicht nur aus Kostengründen. Multithreading ist komplex und der Entwickler ist damit meist überfordert. Der Compiler muss das handhaben können. M$ sollte auch bei den Entwicklungsumgebungen mal in diese Richtung vorwärts machen...
Müsste dafür nicht besser eine neue IDE entwickelt werden, die das für den Coder automatisch macht? Der einzelne Entwickler dürfte damit wohl überlastet sein, wenn er das selbst mit einplanen soll.?
So ein Scheiss.
Intel hat da auf ganz galante Weise einen Weg gefunden das mooresche Gesetz einzuhalten. Von der Leistung welche die Benchmarks versprechen kommt aber beim Durchschnittskunden nichts an. Was soll ich mit einen Dual oder Quad, wenn die Software nur einen Kern nutzen kann? Dann ist der Leistungszuwachs eines einezelnen Kerns eines Multicore gegenüber einem Singlecore so gering, dass es niemand wagen würde, dazu einen Benchmark aufzustellen. Das Ergebniss wäre ernüchternd. Ein ganz toller Marketing-Gag. Und während Intel schon am 16-Core arbeitet, hinkt die Software der Entwicklung hinterher. Ich frag mich ob die Blase dann irgendwann mal platzt, wenn die Schere zwischen Entwicklung von Multicore und passender Software zu groß wird.
was wird dann in die Zukunft passieren. Sagen wir mal 10 - 20 Jahren. Wird dann jeder seine eigene Atomtests durchfuehren koennen. Oder seine eigene Wettervorhersage errechnen koennen. Was soll denn ein BS machen, das gleiche wie in den Film "Iron Mann". Ein Computer der dir aus die Seele spricht und mit dir als normaler Mensch kommunizieren kann. Der dir die ganze Arbeit abnimmt. Aber sicher wird es ein Schweine Geld kosten. Und alle auf diesem Planeten sind Reiche Menschen. Androids die als Frau/Mann rumlaufen, um die Befriedigung eines Mesnchen zu geben oder erfuellen.
Weil dann kann Blue/Gene in 20 Jahren Trilliarden Flops berrechnen. Weil ich sehe immer noch nicht den Nutzen von diese Monster Maschinen, ausser die Ranglisten wer schneller ist.
Ich kann verstehen das man Power braucht fuers Rendering, kodieren usw. Nur fuer viele ist das ja nicht so toll. Will man dann Virtual Spiele Spielen. Tja, beam me up Computer, let's Play Crysis in Virtual Real Life.
Die Zukunft ist doch schon geschrieben. Ich sage doch, Spielfilme sagen dir doch die Zukunft voraus. Nur viele Menschen glauben immer noch an Horoscope und lassen sich die Karten lesen, weil es gibt ja viele Menschen die die Technik verhassen.
@|dukat|
das ist doch das was ich die ganze Zeit sage!!
Das das alles irgendwie total komische verarsche ist und niemand merkts.
Damals war bei den Singlecors bei ca. 2,8-3 GHz einfach Schluss!
MEHR GING NICHT!
Und auf einmal soll man es sogar verdoppeln können?
Ich glaube ebenfalls nach wie vor nicht drann, das mehrere kerne in einem prozzesor wirklich mehr bringen. auser das man halt viele sachen auf einmal machen kann...
Müsste dafür nicht besser eine neue IDE entwickelt werden, die das für den Coder automatisch macht? Der einzelne Entwickler dürfte damit wohl überlastet sein, wenn er das selbst mit einplanen soll.?
Es wäre schön, wenn das so ginge, aber so lange ein Compiler nicht über die Intelligenz und die Krativität eines erfahrenen Programmierers verfügt wird daraus leider nichts.
Um das Ganze mal zu konkretisieren ein paar Beispiele:
Du hast als Aufgabe die Erstellung eines Filters für ein Foto. Der Filter soll das Foto in Schwarz-Weiß umwandeln. Das ist eine vorzügliche Aufgabe für Multiprocessing, denn es ist eine unabhängige Aufgabe... jedes Pixel wird anhand der RGB-Werte in entsprechende Grauwerte umgerechnet. Je nachdem wie viele physikalische (oder logische) Prozessoren das System hat teilst Du das Bild in Teilbilder auf. Sowas könnte auch ein Compiler noch erledigen.
Jetzt hast Du die Aufgabe einen Filter für ein Foto zu erstellen, der das Bild normalisiert, also den Unterschied zwischen dem hellsten Pixel und dem dunkelsten Pixel herausfindet und diese Differenz auf einen jeweiligen Höchst- und Niedrigstwert umrechnet. Jetzt wird es schon schwerer. Der erfahrene Programmierer erkennt, dass hier zwei getrennte Aufgaben vorliegen. Einmal die Analyse des Bildes zum Aufspüren der beiden Max-Werte und einmal die Aufgabe der Änderung der Einzelpixel.
Jeder Teil der Aufgabe ist parallellisierbar, jedoch nicht beide zusammen. Man kann mehrere Threads auf das Bild loslassen um die Max-Werte zu finden, man kann jedoch nicht die mehreren Threads drarauf loslassen es umzurechnen, so lange die Max-Werte gefunden sind. Hier wird es für einen Compiler schon schwieriger, da muss ihm der Programmierer schon helfen.
Jetzt hast Du die Aufgabe einen Filter zu erstellen, der ein Bild prüft, ob darin Text enthalten ist (OCR), der diesen Text auswertet, bestimmte Worte ersetzt und in eine neue Datei schreibt.
Der unerfahrene Programmierer würde sich jetzt denken, dass Teil 1 (erkennen von Text) nicht parallelisierbar ist, da es schwer wird für einen Trhead nur ein Viertel des Buchstaben "A" als solches zu erkenne, wenn er das Bild zerteilt. Der erfahrene Programmierer wird jedoch erkennen, dass ein Thread, der ein Bild nur nach Kontrasten scannt schneller ist, als einer, der in dem Bild nach Buchstaben sucht und ergo wird er einen Startthread programmieren, der mit geringen Kosten erst einmal schaut wo in dem Bild Text sein könnte. Auf diese Bereich schickt er dann die teuren OCR-Sanner in Form einzelner Threads los. Diese können dann parallel scannen und ersetzen. Bei dem letzten Teil, dem Schreiben in eine neue Datei, wird es dann wieder enger, dazu aber gleich mehr.
Was ich damit zeigen will ist, dass die Entscheidung ob etwas parallelisierbar ist oder nicht oftmals nicht-trivial ist. Ganz schwierig ist es im Bereich der Höheren Mathematik. Dort lassen sich Probleme erstmal nur dann parallel lösen, wenn man eine neue mathematische Herangehensweise entwickelt hat. Mit den normalen Modellen ist die Aufgabe streng linear. Wer jedoch imstande ist, dieses Problem zu lösen, der wird auch tunlichst dies entsprechend in Code umsetzen (und es auch können, oder wissen wer es kann). Die Entscheidung, ob etwas parallelisierbar ist kann also oft nur getroffen werden, wenn die Kenntnis über die Art der Aufgabe und deren Abhängigkeiten vorhanen ist... dies ist (derzeit) für Compiler definitiv eine zu anspruchsvolle Aufgabe, denn ein Compiler weiß nicht per sé, was eine Primzahl, was ein menschliches Auge auf einem Foto, oder was die Bedeutung des Wortes "Blödsinn" ist und wie diese mit Gott-und-der-Welt zusammen hängen. Dawird vielleicht in etwas fernerer Zukunft die KI so weit sein auch logische Zusammenhänge zu erfassen.
Aber mal zurück zum Artikel... die Programmierung der Software ist nur die halbe Wahrheit, denn die Zeiten in denen Software im Real-Mode lief sind lange vorbei. Heute hat das Betriebssystem und sein Sheduler die Oberhoheit über die Systemresourcen, wozu auch die CPU-Kerne gehören. Der Sheduler verteilt Prozesse und Threads, fragt deren Status ab und schickt sie nötigenfalls auf eine Extrarunde um den Platz, wenn sie so böse waren und die ganze Prozessorzeit für sich haben wollten und die anderen Schlange stehen mussten. Macht der Sheduler seine Aufgabe schlecht, dann kann der Programmierer sich bücken wie er will, schneller als der Sheduler es zulässt wird es nicht. Andererseits hat der Sheduler die nette Angewohnheit, dass er auch störrische Single-Threading-Anwendungen mit bestimmten Worten in ihre Schranken und auf einen freien Kern weisen kann. So kann sein ein schlauer Sheduler den Thread des Virenscanners auf CPU0, den Thread des Browsers (und von denen sind leider fast alle störrisch wenig muti-threading) auf CPU1, den Thread des Emailprogrammes auf CPU2 und was sich sonst noch tummelt auf CPU3 verweisen.
Nun kommen wir zum Kern der Sache... seit Microsoft nachdrücklich versuchte im Bereich des HPC (auf gut Deutsch: High Performance Computing) Fuß zu fassen wurde leider offensichtlich was vorher schon vermutet wurde: Der Windows-Kernel zählt nicht gerne, was bedingt, dass er sich mit vielen CPU-Kernen etwas schwer tut. Der Fachmann drückt das fogendermaßen aus: Er skaliert nicht gut. Vielleicht kennt der ein oder andere noch einen der Scherzkense, die sich in den frühen Jahren ein System mit 2 CPUs zulegten und darauf Windows 98 installierten... das war so effektiv wie die zweite CPU auf die Fensterbank zu legen, denn der Kernel von Windows 98 konnte nicht einmal bis zwei zählen, da hätte sich die Software und ihr Programmierer auf den Kopf stellen und mit den Zehen wackeln können. Will meinen, er hätte seine Aufgaben parallelisieren und in Threads zerlegen können bis zum umfallen... es wäre auf dem System einfach nicht gegangen (und es hat auch niemand versucht, eben weil es nicht ging).
Wenn man nun die bisherige Erfahrung heranzieht, dass sämtliche Microsoft-Kernel ab spätestens 8 logischen CPUs ein merkliches Problem mit den Fingern beim Abzählen bekommen, dann sollte man vielleicht erst einmal daran denken hier anzusetzen, bevor man die armen Anwenungsprogrammierer mit der Eselsmütze in der Ecke stehen lässt, denn es bringt nichts wenn sie ihre Probleme in 32 Threads packen die sich dann um 8 CPU-Kerne prügeln müssen. Da wäre es effektiver, wenn 4 Programmierer ihre Probleme in 8 Threads packen, die das schlae Betriebssystem auf 32 Kerne verteilt.
Ich hoffe nur das es nicht zum Tagwerk wird die Parallelisierung in Hochsprachen manuell zu bedienen. Klar ist es gute Arbeit aber ich befürchte dann kann man sich nicht immer auf die echte Funktionsweise des Programms konzentrieren.
Den normalen Teil der Aufgabenverteilung muss der Scheduler machen. Wie Du geschrieben hast, Pgm 1 auf CPU 1, Pgm 2 auf CPU2 etc. er muss auch gut genug sein um stehende Prozesse auslagern zu können und Memory frei zu geben.
Wenn's dann speziell wird, kommt Multithreading zum Einsatz. Nicht jede Anwendungsart kann so entwickelt werden, z.B. kann nicht ein Program die Totalzeile einer Rechnung aufbereiten während die Posten noch nicht bereit sind. Aber eine Formel in allen Zellen einer Spreadsheet Kolonne berechnen, die sich nicht auf sich selbst (dieselbe Kolonne) bezieht, könnte wieder Sinn machen. Der Aufwand um zu bestimmen was geeignet ist ist gross, die Umsetzung bedeutet viel Aufwand, in vielen Fällen lohnt sich das nicht mal, womit wir wieder bei der intelligenten Bestimmung einer Unit of Work sind und einem Job-Scheduler der seinen Namen auch zu Recht trägt.
Am Ende ist die Diskussion akademisch.
Solange wir ein Mail schreiben können ohne zu merken dass im Hintergrund eine DVD geschrinkt wird, der Virenscanner einen Fullsearch macht, eine Software die Bilderdatenbank mit 100'000 Bildern nach Duplikaten durchsucht und ein FTP Download läuft während wir mit einem Kollegen Skypen ist doch alles gut, oder etwa nicht?
News: Multithreaded Software
Conqueror
Redaktion
Synthetic_codes
xafford
thomas71berlin
