Was bringen mehrere Rechenkerne?
-
this->that schrieb:
Gregor schrieb:
IMHO ist beides wichtig.
Ja. Drum versteh ich ja net, wieso du Caches so hervorhebst;)
Naja, also ehrlich gesagt habe ich nicht viel Ahnung vom Raytracing im Allgemeinen, aber ich habe einiges mit Raycasting gemacht. In dem Thread da ist ein altes Beispielbild von dem, was ich so gemacht habe: http://www.c-plusplus.net/forum/viewtopic-var-t-is-191889-and-postdays-is-0-and-postorder-is-asc-and-start-is-10.html
Ok, wenn es beim Raytracing ähnliche Probleme wie beim Volume-Raycasting gibt, dann sieht die Situation ungefähr so aus: Die Zugriffe auf die Daten erfolgen in keiner bestimmten Reihenfolge und das kann man auch nicht durch irgendwelche Tricks erreichen. Man durchläuft die Daten also nicht in Speicherreihenfolge, sondern ganz zufällig und für die CPU nicht vorhersehbar. Damit sind dann diverse Verzögerungen verbunden, zum Beispiel kommen die Daten mit enormer Verspätung an, aber auch die Pipeline im Prozessor muss andauernd neu gefüllt werden. Die Auswirkungen des Caches kann ich bei meinem Raycaster ganz leicht beobachten, nämlich dadurch, dass ich die Größe des betrachteten Datenvolumens variiere. Die Größenordnungen sind da ungefähr so: Um ein Volumen der Größe 128*128*128 Voxel zu rendern benötige ich weniger als 0,1 Sekunden. Dieses Volumen passt komplett in meinen Cache. Ein deutlich größeres Volumen passt da nicht mehr rein. Und ein Volumen, das 64mal so groß ist, also 512*512*512 Voxel groß ist, braucht zum Rendern mehr als 90 Sekunden. Das ist also mindestens 900 mal langsamer als ein Volumen mit nur einem 64tel der Daten. Diese unproportionale Verlangsamung kommt praktisch ausschließlich durch den Unterschied zwischen dem Zugriff auf den Cache und dem Zugriff auf den RAM. Der Algorithmus weist zumindest keine derartige Abhängigkeit von der Datenmenge auf, dass man das dadurch erklären könnte. Der ist eher O(n). Wenn ich die Zahlen vergleiche, dann komme ich darauf, dass das Programm, wenn es nur den Cache nutzen muss, um einen Faktor >14 schneller ist, als wenn es in erster Linie das RAM nutzen muss. Ganz einfach weil die CPU bei einer starken Nutzung des RAMs die meiste Zeit damit verbringt, auf die Daten zu warten. Meine CPU hat nur einen einzigen Kern, der von der Leistungsfähigkeit auch nicht mehr Up-To-Date ist, aber das Raycasting ließe sich natürlich auch unglaublich gut auf mehrere Kerne parallelisieren. Skaliert es aber mit der Anzahl der Kerne? Vermutlich nur dann, wenn der Datensatz in den Cache passt, der Flaschenhals zwischen RAM und CPU ist bei mir ja jetzt schon begrenzend: Was soll da noch mehr Rechenleistung in der CPU bringen, wenn dadurch nur noch viel mehr auf die Daten gewartet wird? Diese Schwachstelle wurde in den letzten Jahren nämlich nicht in dem Maße verbessert, wie man es bei der puren Rechenleistung der CPUs sehen konnte.
Wie gesagt: Das muss nicht unbedingt 1:1 auf das Raytracing übertragbar sein, aber es gibt in jedem Fall Anwendungsbeispiele, in denen ein größerer Cache deutlich mehr bringt als vielleicht 10-20% die man ihm im Schnitt über alle Anwendungsgebiete gemittelt zubilligen würde.
-
Gregor schrieb:
Aber Du weißt schon, was in der nächsten Ausbaustufe dieses Testchips dazukommt, oder?
Nein, was denn?
this->that schrieb:
Meiner Meinung nach wird auch in Zukunft das normale Polygonbasierende Rendering der alleinige Ansatz sein. Aber der Grund dafür ist nicht technischer Natur, sondern viel banaler: der Markt ist träge und gerade die Spieleentwicklerbranche ist eher konservativ.
Man kann allerdings auch mit Raytracing polygonbasiert rendern. Die Umstellung auf eine entsprechende Engine dürfte daher gar nicht mal so problematisch sein. Die Frage ist nur, wie schnell Hardware und Schnittstellen verfügbar sind. Danach kann man Schritt für Schritt weiterentwickeln. Heutige 3D Engines wurden ja auch nicht von 0 auf 100 aus dem Boden gestampft.
Gregor schrieb:
Ok, wenn es beim Raytracing ähnliche Probleme wie beim Volume-Raycasting gibt, dann sieht die Situation ungefähr so aus: Die Zugriffe auf die Daten erfolgen in keiner bestimmten Reihenfolge und das kann man auch nicht durch irgendwelche Tricks erreichen. Man durchläuft die Daten also nicht in Speicherreihenfolge, sondern ganz zufällig und für die CPU nicht vorhersehbar. Damit sind dann diverse Verzögerungen verbunden, zum Beispiel kommen die Daten mit enormer Verspätung an, aber auch die Pipeline im Prozessor muss andauernd neu gefüllt werden. Die Auswirkungen des Caches kann ich bei meinem Raycaster ganz leicht beobachten, nämlich dadurch, dass ich die Größe des betrachteten Datenvolumens variiere. Die Größenordnungen sind da ungefähr so: Um ein Volumen der Größe 128*128*128 Voxel zu rendern benötige ich weniger als 0,1 Sekunden. Dieses Volumen passt komplett in meinen Cache. Ein deutlich größeres Volumen passt da nicht mehr rein. Und ein Volumen, das 64mal so groß ist, also 512*512*512 Voxel groß ist, braucht zum Rendern mehr als 90 Sekunden. Das ist also mindestens 900 mal langsamer als ein Volumen mit nur einem 64tel der Daten. Diese unproportionale Verlangsamung kommt praktisch ausschließlich durch den Unterschied zwischen dem Zugriff auf den Cache und dem Zugriff auf den RAM.
Das letzte ist aber entscheidend, der Zugriff auf den RAM. Nur deswegen gibt es eine solche Diskrepanz. Nicht, weil der Cache hier so effektiv ist. Und wenn du alles in den Cache packen willst, über welche Grössenordnungen reden wird denn dann, bei sagen wir mal einer Auflösung von 1600x1200? Einen Faktor von 1000 zu aktuellen Caches? Das wird nicht passieren. Erstens ist Cache nicht ganz billig. Schau dir zB mal die Penryn CPUs von Intel an. Die bestehen zur Hälfte aus Cache. Das ist pure Verschwendung von Die Fläche. Damit sinken die Yields und steigen die Preise. Und zweitens nimmt damit natürlich auch die Leistungsaufnahme zu. Cache wird auch in Zukunft ein Thema bleiben. Aber nur soweit, wie der Fertigungsprozess oder Entwicklungen wie eDRAM das zulassen. Es wird keine unproportionale Sprünge geben.
Btw, darf ich mal fragen, mit welcher CPU du getestet hast? Deinem Post oben zufolge habe ich das Gefühl, du scheinst AMD seit 2003 total verschlafen zu haben. Ein IMC und ein vernünftiger Bus (HT) lassen den Unterschied zwischen Cache und RAM deutlich schrumpfen. Intel bietet momentan jedenfalls keine Basis für eine derartige Betrachtung.
Wie gesagt, Cache ist sicherlich ein Thema. Entscheidend für Raytracing Hardware sind aber Recheneinheiten und Infrastruktur. Alles weitere wird man sehen, sowohl was technisch machbar als auch sinnvoll ist.
-
@groovemaster: Ich habe mir meinen Rechner natürlich nicht mit der Absicht gekauft, genau diese Anwendung am Besten laufen zu lassen: Momentan habe ich nur ein Notebook und da steckt ein Pentium M drin. Ein IMC würde das Problem sicherlich etwas vermindern, AFAIK soll der die Latenzzeit zum RAM etwa um die Hälfte verringern, aber das Problem wäre immer noch da. Ein Faktor 7 ist auch noch sehr relevant. Und wie gesagt: Inzwischen wird der Unterschied eher noch größer sein.
Bezüglich Intels Terascale Chip habe ich einen guten Artikel mit nem hübschen Bild gefunden:
Artikel: http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2925&p=1
Bild: http://images.anandtech.com/reviews/cpu/intel/terascaleISSCC/future.gif
Wenn man das Bild anguckt, dann ist mein aktueller Stand bezüglich des Testchips, dass man da auf dem Bild ganz links ist: Man hat einfach viele Kerne, die auf Fließkommaberechnungen spezialisiert sind, über ein ganz intelligentes Netzwerk zusammengeschaltet. Als nächstes kommt dann wohl die SRAM-Schicht dazu, die Du direkt daneben sehen kannst. Also praktisch die 50% Cache, die Dir da bisher gefehlt haben.
Und dann geht man wohl von den spezialisierten Kernen hin zu mehr generalisierten Kernen.Steht so auch nochmal in dem Artikel:
Intel stated that the two next steps for this research chip are to introduce a 3D stacked die, which we're suspecting Intel has already made significant progress on, and to introduce some more capable cores.
Dieses Die-Stacking könnte durchaus auch irgendwann in den nächsten Jahren in handelsüblichen Prozessoren auftauchen. IMHO eine sehr interessante Entwicklung. Und man wird die übereinanderliegenden Dies IMHO nicht gerade dafür nutzen, um in jedem dieser Dies Rechenkerne unterzubringen. Ich würde zumindest vermuten, dass das zu echten Problemem bezüglich der Wärmeentwicklung führen würde. Stattdessen wird man diese gestapelten Dies vor allem für (SRAM-) Cache verwenden. Oder auch für DRAM, der sehr nah an den Rechenkernen gelagert ist. Zumindest für Speicher, der für die Rechenkerne viel schneller und mit viel höherer Bandbreite erreichbar ist als der normale Arbeitsspeicher. AFAIK plant man da auch deutlich mehr als 2 Dies übereinander zu lagern. Da kannst Du Dir überlegen, dass die Speichermenge innerhalb der Prozessoren möglicherweise irgendwann innerhalb der nächsten Jahre enorm anwächst. Nehalem hat erstmal etwas weniger Cache, aber wart mal noch 5 weitere Jahre ab. Vielleicht sehen wir da plötzlich 256MB Cache in einem Prozessor. Das ist für mich zumindest durchaus vorstellbar.
-
groovemaster schrieb:
Man kann allerdings auch mit Raytracing polygonbasiert rendern.
Das ändert nichts an dem grundsätzlichen Problem, dass Du die Daten vermutlich nicht in der Reihenfolge im Speicher halten kannst, wie Du sie verarbeiten musst. Beim Raytracing verfolgst Du Strahlen und Du brauchst gerade immer die Daten, mit denen der Strahl als nächstes "in Kontakt" tritt. Der Strahl verläuft aber nunmal nicht in Speicherreihenfolgen, sondern kann kreuz und quer durch Deine Szene gehen. Das ist das grundsätzliche Problem, was ich sehe: Aus diesem Grund wirst Du bei fast jedem Zugriff auf den Datensatz die volle Latenzzeit des Hauptspeichers zu spüren kriegen. Es sei denn, der Datensatz liegt komplett oder zumindest zum Großteil im Cache. Und je größer der Cache ist, desto größere Datensätze kannst Du in akzeptabler Zeit verarbeiten.
-
groovemaster schrieb:
Und wenn du alles in den Cache packen willst, über welche Grössenordnungen reden wird denn dann, bei sagen wir mal einer Auflösung von 1600x1200? Einen Faktor von 1000 zu aktuellen Caches?
Hi. Die Größe des Datensatzes hat nichts mit der Auflösung zu tun.
-
Gregor schrieb:
Wenn man das Bild anguckt, dann ist mein aktueller Stand bezüglich des Testchips, dass man da auf dem Bild ganz links ist: Man hat einfach viele Kerne, die auf Fließkommaberechnungen spezialisiert sind, über ein ganz intelligentes Netzwerk zusammengeschaltet. Als nächstes kommt dann wohl die SRAM-Schicht dazu, die Du direkt daneben sehen kannst. Also praktisch die 50% Cache, die Dir da bisher gefehlt haben.
Und dann geht man wohl von den spezialisierten Kernen hin zu mehr generalisierten Kernen.Genau das sage ich doch die ganze Zeit. Das Kern-Cache-Verhältnis wird sich nicht plötzlich von heute auf morgen gravierend ändern. Wie viel Cache zukünftige Chips haben werden, hängt letztendlich von den technischen Möglichkeiten ab. Meine letzten Informationen zu Tera Scale waren übrigens, dass pro Kern sehr wenig Cache zum Einsatz kommt und das Hauptaugenmerk ganz klar auf der Vernetzung der Kerne liegt. Was daraus letztendlich wird, kann man noch nicht abschätzen. Vor 2015 wird Tera Scale vermutlich auch kein Thema sein. Aber wie gesagt, hier bewegen wir uns auf einem Gebiet, was weit entfernt von GP CPUs ist. Abseits vom High-End Bereich geht der Trend sowieso zu sparsamen und kostengünstigen Chips, und hier sind Unmengen an Cache kontraproduktiv.
Gregor schrieb:
groovemaster schrieb:
Und wenn du alles in den Cache packen willst, über welche Grössenordnungen reden wird denn dann, bei sagen wir mal einer Auflösung von 1600x1200? Einen Faktor von 1000 zu aktuellen Caches?
Hi. Die Größe des Datensatzes hat nichts mit der Auflösung zu tun.
Nicht? Wovon denn dann? Ein im Vergleich zur Auflösung zu kleiner Datensatz führt doch zu sichtbarem Aliasing. Dafür braucht man auch kein Raytracing. Ok, Raytracing hat natürlich noch andere Vorteile. Aber gerade die pixelgenaue Projektion ist doch einer der wichtigsten Vorteile.
Nehalem hat erstmal etwas weniger Cache, aber wart mal noch 5 weitere Jahre ab. Vielleicht sehen wir da plötzlich 256MB Cache in einem Prozessor. Das ist für mich zumindest durchaus vorstellbar.
Halte ich eher für unwahrscheinlich. In 5 Jahren sind wir vermutlich bei 22nm, also die Die Fläche gegenüber 45nm auf ein Viertel reduziert. Rechnen wir das naiv mal hoch, macht das 32 MiB (4 x 8 MiB). Vielleicht wird man durch kompaktere Speicherzellen das noch um Faktor 2 bis 3 erhöhen können. Macht also irgendwas zwischen 50 und 100 MiB. Nur, was steht dem entgegen? 16 Kern CPUs? Und welche Datenmengen fliessen dann durch sämtliche Busse? Das Kern-Cache-Verhältnis kann sich durchaus zugunsten von Cache entwickeln, aber nicht in der Dimension, wie du dir das vielleicht vorstellst.
-
groovemaster schrieb:
Nicht? Wovon denn dann? Ein im Vergleich zur Auflösung zu kleiner Datensatz führt doch zu sichtbarem Aliasing. Dafür braucht man auch kein Raytracing. Ok, Raytracing hat natürlich noch andere Vorteile. Aber gerade die pixelgenaue Projektion ist doch einer der wichtigsten Vorteile.
Inwiefern führen kleine Datensätze zu Aliasing?
groovemaster schrieb:
Halte ich eher für unwahrscheinlich. In 5 Jahren sind wir vermutlich bei 22nm, also die Die Fläche gegenüber 45nm auf ein Viertel reduziert. Rechnen wir das naiv mal hoch, macht das 32 MiB (4 x 8 MiB). Vielleicht wird man durch kompaktere Speicherzellen das noch um Faktor 2 bis 3 erhöhen können. Macht also irgendwas zwischen 50 und 100 MiB. Nur, was steht dem entgegen? 16 Kern CPUs? Und welche Datenmengen fliessen dann durch sämtliche Busse? Das Kern-Cache-Verhältnis kann sich durchaus zugunsten von Cache entwickeln, aber nicht in der Dimension, wie du dir das vielleicht vorstellst.
Du bist gar nicht auf meine Begründung eingegangen.
Du gehst weiterhin davon aus, dass die verfügbare Fläche konstant bleibt. Wenn die das mit dem Die-Stacking hinkriegen, hast Du aber vielleicht nicht mehr 100mm² zur Verfügung, sondern effektiv vielleicht 8*100mm² oder so.
-
Gregor schrieb:
Inwiefern führen kleine Datensätze zu Aliasing?
Inwiefern führen Polygone zu Aliasing?
Ist das gleiche Prinzip, nur statt Kantenpunkt-Pixel-Dichte ist hier Strahlen-Pixel-Dichte entscheidend.groovemaster schrieb:
Du bist gar nicht auf meine Begründung eingegangen.
Du gehst weiterhin davon aus, dass die verfügbare Fläche konstant bleibt. Wenn die das mit dem Die-Stacking hinkriegen, hast Du aber vielleicht nicht mehr 100mm² zur Verfügung, sondern effektiv vielleicht 8*100mm² oder so.Aber mit Sicherheit nicht in den nächsten 5 Jahren. Solche Multi-Layer Wafer sind pure Zukunftsmusik. Die Kosten sind vermutlich auch exorbitant. Von dem, was ich bisher davon mitbekommen habe, sind auch erstmal nur wenige Layer, 2-3, denkbar. Und ob diese dann auch für Cache genützt werden, ist ebenfalls pure Spekulation.
-
groovemaster schrieb:
Solche Multi-Layer Wafer sind pure Zukunftsmusik. Die Kosten sind vermutlich auch exorbitant. Von dem, was ich bisher davon mitbekommen habe, sind auch erstmal nur wenige Layer, 2-3, denkbar. Und ob diese dann auch für Cache genützt werden, ist ebenfalls pure Spekulation.
Warum siehst Du da so eine Beschränkung? Ich meine, etwas ganz neues ist das Stapeln von Dies ja nicht. Bei Flashspeicher wird das bereits gemacht, siehe zum Beispiel da:
http://www.koreatimes.co.kr/upload/news/070905_p10_hynix.jpg
Da haben wir 24 Dies übereinandergestapelt. Das einzig wirklich neue, was Intel dazubringen will, ist IMHO die Verbindungstechnik. Wie Du auf dem Foto siehst, gehen bei diesen gestapelten Flash-Speichern die Drähte mehr oder weniger seitlich aus den Dies raus. Das will Intel anders machen und die Verbindungen direkt zwischen den Chips auf den flachen Seiten der Chips anbringen (und sie vor allem direkt von Chip zu Chip gehen lassen). Natürlich ist das momentan noch etwas neues, aber ich sehe da ehrlich gesagt kein prinzipielles Problem. Wenn Intel es hinkriegt, das mit 2 Dies übereinander zu realisieren, dann beherrschen sie es praktisch sofort auch für deutlich mehr Schichten. Und vom Preis her ist das auch kein Problem. Die Dies werden separat gefertigt und getestet. Am Schluss nimmt man einfach die funktionierenden Dies und stapelt sie aufeinander. Die Die-Fläche selbst ist nicht sooo teuer: Siehst Du ja an DRAMs und ähnlichen Speichern: Da kriegst Du viel mehr Die-Fläche für viel weniger Geld als bei Prozessoren. Was bei den Prozessoren wirklich teuer sein dürfte, ist die Entwicklung des Produkts, nicht die Herstellung. Die Entwicklung eines Speichers dürfte aber nicht so teuer sein: Du siehst ja auf jedem Bild einer CPU, was für regelmäßige und periodische Strukturen solche Caches sind. Da ist im Wesentlichen millionenfach die gleiche Struktur auf einem Chip realisiert und im Extremfall entwickelt man das am Rechner vielleicht durch ein paar Mausklicks. Ok, ist vielleicht übertrieben, aber an den Entwicklungsaufwand eines Rechenkerns kommt man bei Caches um Größenordnungen nicht ran.
-
die caches werden meist an die anwendung angepasst. und wenn man garnichts mehr inteligentes machen kann, stopft man die chips mit caches voll.
das prozessorgefluester der c't ist gerade online bei heise, darin steht dass der naechste chip 32+32kb 1lvl, 256kb 2lvl und nen shared 8MB 3lvl cache haben werden. im gegensatz zu dem derzeitigen 2*6MB.
wenn man raytracen wollen wuerde, wuerde man wegen den random zugriffen ohne ende cache brauchen und zudem sehr sehr schnellen cache.
heutige GPUs haben hingegen so ziemlich keinen cache. nur ein paar kb, was effektiv pro 'core' bzw 'thread' so ziemlich nur ein paar byte sind. nicht weil man nicht weiss wie das geht, sondern schlicht weil es keine beschleunigung geben wuerde.
vielleicht sollte man das hier zu einem raytracing thread splitten
-
Gregor schrieb:
Warum siehst Du da so eine Beschränkung?
Weil ich nun mal realistisch bleibe.
In der Theorie kann man immer viel. Die Praxis sieht aber oft anders aus. Ein Vergleich mit Flash oder anderen Speicherchips ist auch nicht ganz realistisch. CPUs haben zB eine ganz andere Thermik. Alleine das wird die Anzahl der Layer stark begrenzen.
Bei IBM übrigens wird dieses Stacking afaik erst mit 32nm Strukturen in Verbindung gebracht. Und selbst dann ist die Entwicklung noch lange nicht abgeschlossen. Von ersten Samples bis hin zu fertigen Produkten vergeht dann ebenfalls noch mal ordentlich Zeit. Wie ich schon sagte, das ist pure Zukunftsmusik. In den kommenden Jahren wirst du bei CPUs davon nichts sehen.
Btw, preislich halte ich das übrigens für ein erhebliches Problem. Was ist wohl wirtschaftlicher? 2 Dies für 2 separate Produkte, welche zB für jeweils $100 verkauft werden können? Oder 2 Dies für ein etwas leistungsstärkeres Produkt, welches zB für $150 verkauft werden kann? Die Kosten für Entwicklung und Umrüstung der Fabs werden sicherlich auch nicht gerade gering ausfallen. Es ist, wie so oft, eine Kosten-Nutzen-Frage. Für solche Hardware brauchst du hohe Margen. Und dann sind wir aber schon wieder in einem Nischenmarkt, auf dessen Basis du keine Massenware unters Volk bringen kannst. D.h., das ist kein Markt für GP CPUs.
Glaube es mir oder auch nicht, Raytracing Hardware wird sehr wahrscheinlich nicht auf GP CPUs basieren. Egal wie viel Cache dort theoretisch reingestopft werden kann. Weitaus wahrscheinlicher sind eben speziell dafür konzipierte GPUs. Ob dediziert oder in Verbindung mit einer CPU (siehe Swift), bleibt abzuwarten. Dein Cache Argument ist dabei genauso sehr oder vielmehr wenig relevant, wie dies bei aktuellen Rasterizern der Fall ist.
-
gehen wir hier nicht implizit davon aus, dass ein single-core prozessor aufgaben mit 100% erledigen kann?
wenn das nicht der fall ist, kann es sehr wohl sein, dass ein n-core prozessor mehr als doppelt so effizient sein kann.
-
Es gibt auch noch andere Fälle in denen man superlineare Speedups erzielen kann (also mit p Prozessoren mehr als p-fache Geschwindigkeit). Man stelle sich beispielsweise eine Suche mit branch-and-bound vor. Durch das parallele Absuchen mehrere Suchpfade stehen eventuell früher im Suchverlauf bessere Schranken zu Verfügung, die dazu führen können, dass größere Teilbereiche des Suchraums abgeschnitten werden können.
Allerdings wird der Unterschied auch nicht sooo riesig sein. Wäre er es doch, so sollte man einfach seinen einzelnen Prozessor benutzen um n Stück zu simulieren.
-
Gregor schrieb:
Artikel: http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2925&p=1
Bild: http://images.anandtech.com/reviews/cpu/intel/terascaleISSCC/future.gif
Ist ja cool, nur wie nutzen die Anwendungen effektiv 80 Cores? Manche Anwendungen sind ja schon bei 2 Cores ueberfordert.
-
DEvent schrieb:
Gregor schrieb:
Artikel: http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2925&p=1
Bild: http://images.anandtech.com/reviews/cpu/intel/terascaleISSCC/future.gif
Ist ja cool, nur wie nutzen die Anwendungen effektiv 80 Cores? Manche Anwendungen sind ja schon bei 2 Cores ueberfordert.
Naja, das ist natürlich erstmal nur ein Testchip, der seine Rechenleistung nur bei wenigen, ganz speziellen Anwendungen ausspielen kann. Aber es gibt durchaus Anwendungen, die sehr sehr viele Kerne ausnutzen können. Guck Dir heutige Supercomputer an: JUGENE in Jülich hat zum Beispiel mehr als 65.000 Prozessoren. Offensichtlich finden die Leute Anwendungen, die das ausnutzen können. So ein Supercomputer wird sicherlich eher im wissenschaftlichen Bereich genutzt und hin und wieder sicherlich auch an die Industrie "vermietet", aber ich wüsste nicht, warum Anwendungen für viele Kerne nur in so einem Umfeld anzutreffen sein sollten. Viele Kerne kann man ja schon schnell für die Bildverarbeitung, Videobearbeitung und so weiter verwenden: Dort kommt es oft vor, dass man die gleiche Operation auf jeden einzelnen Pixel eines Bildes anwenden möchte. Im Prinzip könntest Du soetwas so weit parallelisieren, wie es Pixel im Bild gibt. ...aber es wäre natürlich auch schon toll, wenn man für jede Bildzeile einen eigenen Kern zur Verfügung hat. Oder meinetwegen auch ein Kern pro 50 Bildzeilen. Raytracing wurde hier ja auch schon angesprochen. Das ist auch praktisch beliebig parallelisierbar. Mag sein, dass das in Computerspielen nicht kommt oder nicht so schnell kommt, aber für Kinofilme nimmt man das auf jeden Fall. Und wenn zu Hause mal jemand kreativ werden will, hat er mit derartigen Chips eine gute Grundlage für vieles, was er machen möchte.
Von einer massiven Erhöhung der Anzahl der Kerne profitieren natürlich bei weitem nicht alle Anwendungen. Es wird Anwendungen geben, denen das gar nichts bringt, sicherlich auch sehr rechenintensive Anwendungen. Aber ist das ein Grund, soetwas nicht zu machen? Ich finde nicht.
@groovemaster: Auf der ersten Seite des Artikels da oben steht übrigens sehr schön beschrieben, warum bei einer Erhöhung der Kernanzahl Die-Stacking kommen wird und warum man diese zusätzlichen Schichten dazu nutzen wird, einen sehr schnellen Speicher unterzubringen. Und bezüglich der Größes dieses Speichers:
Obviously there will still be a need for main memory, as Intel is currently estimating that a single layer could house 256MB of memory. With a handful of layers, and a reasonably wide external memory bus, keeping a CPU with tens of cores fed with data now enters the realm of possibility.
256MB pro Schicht. Das ist ja noch viel mehr, als ich erhofft hatte.
-
Ich denke bei so 80 Cores kommen die VMs wie Java oder .net zum Zuge. Eine Java Applikation hat jetzt 4 Threads:
- Daemon Thread AWT-XAWT
- AWT-Shutdown
- AWT-EventQueue
- DestroyJavaVM
Dazu kommen noch ein paar Timer-Threads wenn man irgendwelche Daten hat die sich staendig aendern, usw.
Ich denke bei 80 Cores kann man dann ohne nachzudenken fuer jede Aufgabe ein eigenen Thread laufen lassen. Vielleicht haben wir dann eine API, die das dann vernueftig aufteilen kann und ueberfluessige Threads vereinen kann oder so.
Was das Standard wird, wird man in der Zeit nie mehr was von single-Thread-Anwendungen hoeren
-
Gregor schrieb:
@groovemaster: Auf der ersten Seite des Artikels da oben steht übrigens sehr schön beschrieben, warum bei einer Erhöhung der Kernanzahl Die-Stacking kommen wird und warum man diese zusätzlichen Schichten dazu nutzen wird, einen sehr schnellen Speicher unterzubringen. Und bezüglich der Größes dieses Speichers:
Obviously there will still be a need for main memory, as Intel is currently estimating that a single layer could house 256MB of memory. With a handful of layers, and a reasonably wide external memory bus, keeping a CPU with tens of cores fed with data now enters the realm of possibility.
256MB pro Schicht. Das ist ja noch viel mehr, als ich erhofft hatte.
Ja ja, Intel war immer schon gross im Ankündigen. Selten haben sie das auch gehalten. Ich warte zB immer noch auf den 10 GHz P4.
Du scheinst mich auch nicht zu verstehen. Ich habe nicht gesagt, dass diese Entwicklung nicht stattfinden wird. Nur in den kommenden Jahren wirst du davon nichts sehen. Und wenn man soweit ist, werden erstmal sehr wenige Layer eingesetzt und schrittweise weiterentwickelt. Leistung ist schon lange nicht mehr alles, Effizienz ist in vielen Bereichen weitaus wichtiger. Und inwiefern sowas dann im Massenmarkt eingesetzt wird, bleibt abzuwarten. Wirtschaftlich macht das nur begrenzt Sinn. GP CPUs werden jedenfalls nicht die Träger für Echtzeit Raytracing sein. Ende der Geschichte.DEvent schrieb:
Gregor schrieb:
Artikel: http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2925&p=1
Bild: http://images.anandtech.com/reviews/cpu/intel/terascaleISSCC/future.gif
Ist ja cool, nur wie nutzen die Anwendungen effektiv 80 Cores? Manche Anwendungen sind ja schon bei 2 Cores ueberfordert.
Das sind allerdings keine 80 Kerne, wie du sie von x86 CPUs kennst. Das sind ganz einfache Recheneinheiten, vergleichbar mit Shadern in GPUs. Ob so eine CPU jemals die notwendige x86 Kompatibilität besitzen wird, um sie in gewöhnlichen Desktop Rechnern einzusetzen, ist auch fraglich. Der Multicore Ansatz ist für Desktop- und Mobil-Plattformen auch eher suboptimal. Tera Scale ist auch erstmal ein reines Forschungsprojekt. Konkrete Anwendungen sind noch nicht geplant. Und wie ich schon sagte, vorstellbar wäre der Einsatz in zukünftigen Grafiklösungen von Intel. Vielleicht kann man damit aber auch die z-Serie von IBM angreifen.
-
groovemaster schrieb:
Ja ja, Intel war immer schon gross im Ankündigen. Selten haben sie das auch gehalten. Ich warte zB immer noch auf den 10 GHz P4.
Du scheinst mich auch nicht zu verstehen. Ich habe nicht gesagt, dass diese Entwicklung nicht stattfinden wird. Nur in den kommenden Jahren wirst du davon nichts sehen. Und wenn man soweit ist, werden erstmal sehr wenige Layer eingesetzt und schrittweise weiterentwickelt. Leistung ist schon lange nicht mehr alles, Effizienz ist in vielen Bereichen weitaus wichtiger. Und inwiefern sowas dann im Massenmarkt eingesetzt wird, bleibt abzuwarten. Wirtschaftlich macht das nur begrenzt Sinn. GP CPUs werden jedenfalls nicht die Träger für Echtzeit Raytracing sein. Ende der Geschichte.Hi. GPCPUs sind eine andere Entwicklung, die nichts mit Raytracing zu tun hat. Das sehe ich auch. IMHO ist das vorerst eine Entwicklung, um Bürorechner billiger zu machen. Die Grafikfunktionalität des Chipsatzes wird da dann einfach in die CPU verlagert.
Aber die Erhöhung der Anzahl der Kerne im Prozessor ist eben auch eine Entwicklung, die sich auch sicherlich noch in den nächsten Jahren fortsetzen wird. Ich habe immer einen Zeitpunkt "in 5 Jahren" im Blick. Es kann sein, dass Du da eher die nähere Zukunft betrachtest. In 5 Jahren könnten wir zumindest 16 bis 32 Kerne in einem Prozessor haben. Das sind schon eine ganze Menge Kerne und die Probleme bezüglich der Speicheranbindung, die in dem Artikel skizziert werden, sind bei dieser Kernanzahl definitiv schon sehr real. Und dafür müssen dann auch Lösungen gefunden werden, sonst kommt man an einen toten Punkt der Entwicklung. Denn was will man auf einem Prozessor-Die unterbringen? Eine andauernde Erhöhung der Komplexität der einzelnen Kerne bringt zumindest immer weniger, was das Verhältnis aus Leistungszuwachs und zusätzlich benötigter Die-Fläche betrifft. Und wenn man zusätzliche Kerne nicht auslasten kann, dann bringt es auch nichts, davon noch mehr auf den Chip zu setzen. Was macht man also mit der zusätzlichen Transistorzahl, die bei jedem Miniaturisierungsschritt verfügbar wird? Intel hat zumindest gesagt, dass sie die Lösung für dieses Problem im Die-Stacking sehen. Das geißt, dass in diese Richtung Forschung und Entwicklung betrieben wird. Ich persönlich sehe dazu momentan auch keine Alternative. Siehst Du eine? Wenn ein entsprechender Speicherausbau im Prozessor vorhanden ist, stellt sich allerdings die Frage, wie man in der Computergrafik weitermachen will. Man ist dann an einem Punkt, an dem das Raytracing in Echtzeit vielleicht sehr viel eher zu realisieren ist, als heutzutage. Und es gibt schon eine ganze Menge Gründe, Raytracing gegenüber konventioneller Computergrafik, wie sie momentan von GPUs beschleunigt wird, zu bevorzugen. Guck Dir entsprechende Kinofilme an: Warum nutzen die Leute da Raytracing? Weil das Ergebnis besser ist und sie die Zeit und die Rechenleistung haben, um heute schon Raytracing zu nutzen.
-
BTW: Gerade habe ich das da entdeckt:
http://tech.slashdot.org/tech/08/03/31/1423247.shtml
This is breaking news. Microsoft has not only decided to support ray tracing in DirectX 11, but they will also be basing it on Intel's x86 ray-tracing technology and get this ... it will be out by the end of the year!
-
Ganz bestimmt ein Aprilscherz.
