Was bringen mehrere Rechenkerne?
-
Optimizer schrieb:
Skeptiker schrieb:
raps schrieb:
dass dir das argument nicht reicht dass ich in der praxis mehr als n-fache leistungssteigerung mit mehreren kernen hatte ueberliest du da sicher gerne.
Dann beleg doch mal, dass du mehr als N-fache + X Leistung bekommen hast, nur durch das Hinzufügen mehrerer Kerne.
Ist doch einfach zu überlegen. Wenn du 1 Kern hast, dann läuft außer dem Programm noch ne Menge anderer Scheiß auf dem OS (besonders, wenn's ein Linux ist). Dein Programm kriegt also zum Beispiel nur 90% von 1 Kern. Bei zwei Kernen kriegt dein Programm dann 190%, was mehr ist als das Doppelte.
Du kennst offenbar nicht mal den Unterschied zwischen Threads und Prozessen.
-
Optimizer schrieb:
Gregor schrieb:
Bei konventionellen Grafikkarten scheint sich die Entwicklung ja etwas totgefahren zu haben: Es kommen zwar immer wieder neue Grafikkarten auf den Markt, aber die meisten Spiele sind diesbezüglich nicht mehr auf das Non-Plus-Ultra angewiesen. Das war früher anders. rapso wird da mehr Ahnung als ich haben, aber anscheinend haben die Spieleentwickler echte Probleme, die Grafikkarten mit genug Daten zu füttern, dass diese auch ausgelastet sind. Wenn man aber auf Dauer immer weniger Leistung solcher Grafikkarten wirklich ausnutzt, dann stellt sich die Frage, warum man überhaupt noch Spezialhardware dafür nutzen sollte. In ein paar Jahren sollte die CPU auch genug Rechenleistung haben, um die Grafikberechnungen in den meisten Spielen durchführen zu können.
Die Rechenpower, die du zum Beispiel für realistische Lichtberechnungen verbrauchen könntest, wenn du sie nur hättest, ist doch nahezu unbegrenzt.
Grafikkarten sind nicht auf die Berechnung realistischen Lichts ausgelegt. Das ist eher eine Stärke von Raytracing, das auf der CPU besser läuft. Also noch ein Grund mehr, von heutigen Grafikkarten wegzukommen.
-
omg.. schrieb:
Optimizer schrieb:
Skeptiker schrieb:
raps schrieb:
dass dir das argument nicht reicht dass ich in der praxis mehr als n-fache leistungssteigerung mit mehreren kernen hatte ueberliest du da sicher gerne.
Dann beleg doch mal, dass du mehr als N-fache + X Leistung bekommen hast, nur durch das Hinzufügen mehrerer Kerne.
Ist doch einfach zu überlegen. Wenn du 1 Kern hast, dann läuft außer dem Programm noch ne Menge anderer Scheiß auf dem OS (besonders, wenn's ein Linux ist). Dein Programm kriegt also zum Beispiel nur 90% von 1 Kern. Bei zwei Kernen kriegt dein Programm dann 190%, was mehr ist als das Doppelte.
Du kennst offenbar nicht mal den Unterschied zwischen Threads und Prozessen.
Ahja.
Das ist ja mal die dämlichste Antwort in diesem Thread. Es ist vollkommen irrelevant, was für schedulbare Einheiten du verwendest, es ist in verschiedenen Betriebssystemen verschiedentlich implementiert und du kannst dein Programm verschiedentlich dazu bringen, mehrere Kerne zu nutzen, beispielsweise über weitere Prozesse oder weitere Thread. Plus, das ganze hat mit dem Thema nichts zu tun.
EDIT: Aber ich verstehe schon, warum du dich weigerst, solche Aussagen anzuerkennen. Du bist gedanklich in einer idealisierten Welt, in der es nichts außer deinem Programm gibt. Die Realität ist aber nicht so und es ist schon vorstellbar, dass dadurch, dass mehr Kerne vorhanden sind, die Wartezeit woanders geringer wird und ein anderer Kern dadurch weniger idlet. Es gibt viele mögliche Gründe, warum man auch mal einen unverhältnismäßigen Leistungsanstieg verzeichnen kann. Dabei geht es um die Leistung, die dir was nützt und nicht um die Leistung, die idlet. Natürlich haben 2 Kerne nur die Power von 2 Kernen, aber du kannst sie möglicherweise besser für dich nutzen, aus verschiedensten Gründen.
-
Gregor schrieb:
Optimizer schrieb:
Gregor schrieb:
Bei konventionellen Grafikkarten scheint sich die Entwicklung ja etwas totgefahren zu haben: Es kommen zwar immer wieder neue Grafikkarten auf den Markt, aber die meisten Spiele sind diesbezüglich nicht mehr auf das Non-Plus-Ultra angewiesen. Das war früher anders. rapso wird da mehr Ahnung als ich haben, aber anscheinend haben die Spieleentwickler echte Probleme, die Grafikkarten mit genug Daten zu füttern, dass diese auch ausgelastet sind. Wenn man aber auf Dauer immer weniger Leistung solcher Grafikkarten wirklich ausnutzt, dann stellt sich die Frage, warum man überhaupt noch Spezialhardware dafür nutzen sollte. In ein paar Jahren sollte die CPU auch genug Rechenleistung haben, um die Grafikberechnungen in den meisten Spielen durchführen zu können.
Die Rechenpower, die du zum Beispiel für realistische Lichtberechnungen verbrauchen könntest, wenn du sie nur hättest, ist doch nahezu unbegrenzt.
Grafikkarten sind nicht auf die Berechnung realistischen Lichts ausgelegt. Das ist eher eine Stärke von Raytracing, das auf der CPU besser läuft. Also noch ein Grund mehr, von heutigen Grafikkarten wegzukommen.
Dann nimm halt beliebige lokale Algorithmen der Bildverarbeitung. Heute wird doch in Computerspielen eh schon massiv Gebrauch von Postprocessing gemacht. Ich glaube wirklich nicht, dass in absehbarer Zeit die Leistung einfach "ausreicht".
-
Gregor schrieb:
Grafikkarten sind nicht auf die Berechnung realistischen Lichts ausgelegt. Das ist eher eine Stärke von Raytracing, das auf der CPU besser läuft. Also noch ein Grund mehr, von heutigen Grafikkarten wegzukommen.
Wie kommst du darauf, dass es auf CPUs besser läuft? Nur weil es einfacher ist, eine brauchbare Schnittstelle anzubieten? Wenn Echtzeit Raytracing kommt, dann ziemlich wahrscheinlich auf dafür entwickelten GPUs, und nicht auf Mehrzweck-CPUs wie x86. Schau dir einfach mal an, welche Rohleistung heutige Grafikkarten bieten. Davon können CPUs nur träumen. So schnell werden Grafikkarten auch nicht aussterben, auch wenn smartere Lösungen durchaus an Bedeutung gewinnen könnten, siehe Swift von AMD.
-
groovemaster schrieb:
Wie kommst du darauf, dass es auf CPUs besser läuft? Nur weil es einfacher ist, eine brauchbare Schnittstelle anzubieten? Wenn Echtzeit Raytracing kommt, dann ziemlich wahrscheinlich auf dafür entwickelten GPUs, und nicht auf Mehrzweck-CPUs wie x86. Schau dir einfach mal an, welche Rohleistung heutige Grafikkarten bieten. Davon können CPUs nur träumen. So schnell werden Grafikkarten auch nicht aussterben, auch wenn smartere Lösungen durchaus an Bedeutung gewinnen könnten, siehe Swift von AMD.
Irgendwo stand mal, dass Raytracing sehr von großen Caches profitiert. Das Raytracing ist auf soetwas also praktisch angewiesen. Klassische GPUs haben aber keine großen Caches. Den haben die CPUs.
-
Und was gewinnst du durch grosse Caches an Leistung? 10%? 20%? Dadurch kannst du die momentan mehr als 20-fache Leistung von Grafikkarten aber nicht wegmachen.
Man sollte immer bedenken, Cache kann die Leistung nicht effektiv erhöhen. Man kann dadurch lediglich den Leistungsabfall verringern. Intel braucht momentan halt viel davon, weil sie im Gegensatz zu AMD eine langsame Speicheranbindung (FSB) haben. Bei Nehalem zB wandert der Speichercontroller ebenfalls in die CPU und wird mittels QPI gespeist. Dann wird auch der Cache wieder geringer, 8 MiB (aktuell 12 MiB).
-
groovemaster schrieb:
Und was gewinnst du durch grosse Caches an Leistung? 10%? 20%? Dadurch kannst du die momentan mehr als 20-fache Leistung von Grafikkarten aber nicht wegmachen.
Man sollte immer bedenken, Cache kann die Leistung nicht effektiv erhöhen. Man kann dadurch lediglich den Leistungsabfall verringern. Intel braucht momentan halt viel davon, weil sie im Gegensatz zu AMD eine langsame Speicheranbindung (FSB) haben. Bei Nehalem zB wandert der Speichercontroller ebenfalls in die CPU und wird mittels QPI gespeist. Dann wird auch der Cache wieder geringer, 8 MiB (aktuell 12 MiB).Der Unterschied zwischen "Daten aus dem Cache holen" und "Daten aus dem RAM holen", ist ungefähr 5ns vs. 50ns. Es geht dabei also um einen Faktor 10, falls bei einer Anwendung an dieser Stelle der Flaschenhals liegen sollte. Wenn man beim Raytracing vielleicht von einer Datenmenge ausgeht, die in größere Caches passen könnte und auf die die Zugriffe mehr oder weniger zufällig erfolgen, dann liegt hier ganz sicher der Flaschenhals. Und vermutlich wird in dem Fall zusätzlich noch die Bandbreite limitierend. Vom RAM in den Cache wird immer gleich eine ganze Speicherzeile übertragen. Wenn man davon aber nur ein konkretes Datum braucht, dann hat man das Meiste umsonst übertragen, man hat also viel Bandbreite verschwendet. Bei der heutigen Arbeitsweise von Grafikkarten kannst Du das vermeiden, weil Du die Daten oft in Speicherreihenfolge bearbeiten kannst. Beim Raytracing wird das nicht so sein. Mit anderen Worten: Es ist stark zu bezweifeln, dass Du einen Prozessor ohne großem Cache auch nur ansatzweise beim Raytracing mit den Daten füttern kannst, die er theoretisch verarbeiten könnte.
-
Das darfst du gerne bezweifeln. Aber selbst mit 1 GiB Cache werden CPUs weitaus langsamer sein als Grafikkarten. Ich glaube, du überschätzt die Bedeutung von Cache gewaltig. Wie ich schon sagte, Cache dient nicht zur effektiven Leistungssteigerung, sondern ausschliesslich zur Pufferung. Dein Beispiel mit den Latenzen ist auch irreführend. In der Praxis hat das nur geringe Auswirkungen, da Flaschenhälse noch an ganz anderen Stellen zum tragen kommen. Ohne ALU und FPU Power nützt dir der Cache alles nix. Und daran scheitert es bei GP CPUs.
Wenn es dich wirklich interessiert, wie Chips für Echtzeit-Raytracing in Zukunft aussehen könnten, google mal nach Tera Scale von Intel. Infrastruktur ist entscheidend, nicht Cache.
-
groovemaster schrieb:
Wenn es dich wirklich interessiert, wie Chips für Echtzeit-Raytracing in Zukunft aussehen könnten, google mal nach Tera Scale von Intel. Infrastruktur ist entscheidend, nicht Cache.
Aber Du weißt schon, was in der nächsten Ausbaustufe dieses Testchips dazukommt, oder?
Vielleicht werden wir das ja auch relativ kurzfristig durch das nächste IDF Anfang April mitkriegen. Ich bin da sehr gespannt, hoffentlich gibt es auch Nehalem-Benchmarks, damit ich nen Grund finde, noch'n dreiviertel Jahr mit nem Rechnerkauf zu warten. 
-
Irgendwie versteh ich auch nicht so ganz, wieso Caches so unglaublich wichtig sein sollten beim Thema Raytracing. Entscheidender sollte doch eher eine massiv parallele Architektur mit riesiger FP Verarbeitungsgeschwindigkeit sein.
-
this->that schrieb:
Irgendwie versteh ich auch nicht so ganz, wieso Caches so unglaublich wichtig sein sollten beim Thema Raytracing. Entscheidender sollte doch eher eine massiv parallele Architektur mit riesiger FP Verarbeitungsgeschwindigkeit sein.
Hi. IMHO ist beides wichtig. Natürlich brauchst Du eine massive Parallelisierung, um möglichst viele Daten verarbeiten zu können. Aber Du musst die Daten dazu auch zur Verfügung haben. Wenn die Bandbreite zum Speicher nur ausreicht, um 2 Kerne andauernd mit Daten zu versorgen, was machst Du dann mit den anderen 14 Kernen, wenn Du meinetwegen 16 Kerne hast.
Ein grundsätzliches Problem bei Moore's Gesetz ist, dass die Komponenten außerhalb der Chips nicht einen derartigen technischen Fortschritt durchlaufen, wie die Chips selbst. Du kannst zum Beispiel die Anzahl der Leitungen zu einem Chip nicht ins unermässliche steigen lassen. Was hat man da momentan? Bei Intel heißt der Sockel "Socket 775", es gibt also wohl 775 Leitungen zum Chip. Kannst Du Dir vorstellen, dass das in 10 Jahren 32 mal so vielen sein werden? Ich meine, die Anzahl der Transistoren im Chip wird um diesen Faktor anwachsen. Also ich kann es mir nicht vorstellen. Eine derart hohe Anzahl von Leitungen kann man weder auf dem Mainboard realisieren, noch vernünftig mit dem Chip verbinden. Kann man da vielleicht die Taktfrequenz erhöhen? Ne, kann man auch nicht. Die Signallaufzeit liegt da AFAIK irgendwo bei ungefähr 2/3 der Lichtgeschwindigkeit, das RAM ist um die 10cm vom Chip entfernt, jetzt kannst Du ja mal ausrechnen, was so die maximale Frequenz wäre, die man durch so eine theoretische Betrachtung schnell abschätzen kann. Das wären so 2 GHz und da liegen wir momentan ohne viel Fortschritt in Sicht noch eine Größenordnung drunter. Ein E-Techniker kann Dir da vermutlich noch deutlich mehr Gründe nennen, warum wir nicht ansatzweise an diese 2GHz rankommen werden. Mit anderen Worten: Der Datenkanal vom RAM zum Chip ist in seinen Möglichkeiten relativ begrenzt. Die Chips werden aber immer leistungsstärker und deshalb werden auch die Caches immer wichtiger.
Jetzt haben wir beim Raytracing vermutlich eine Situation, bei der das RAM besonders benachteiligt ist, deshalb wird der Flaschenhals in diesem Fall viel früher an genau dieser Stelle liegen, als bei anderen Anwendungen.
-
Gregor schrieb:
Hi.
Hiho.
Gregor schrieb:
IMHO ist beides wichtig.
Ja. Drum versteh ich ja net, wieso du Caches so hervorhebst;)
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. Selbst wenn Intel in ein paar Jahren eine tolle Raytracer Karte rausbringt wird das nichts ändern, da es erst bei einer großen Verbreitung interessant wird. Ganz abgesehen davon, dass 100e Millionen Zeilen an Renderer/Rasterizer Spiele-Code vorliegen, den man auch nicht so leicht umstellen/verwerfen kann. Insofern ist es etwas müßig, bereits jetzt zu diskutieren wie die HW für eine Raytracer Karte aussehen müsste;)
-
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.
