Was bringen mehrere Rechenkerne?
-
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.
-
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.
