Intel Haswell-EP: Server-Derivate mit bis zu 160 Watt TDP und 16 Kernen?

[Threshold]

Haswell soll aber, soweit ich das zumindest gehört habe, eben auch eine "iGPU" bekommen. Solche Sachen sind aber durchaus mit Vorsicht zu genießen.

Das würde aber auch klar bedeutet dass es einen neuen Sockel gibt oder?

 

[Skysnake]

Den wird es wohl eh geben "Stichwort DDR4".

Ganz abgesehen von anderen Entwicklungen.

Leider wird MemoryCube wohl erst nach dem Start von DDR4 mal einzug halten Ich bin ja diesbezüglich immer etwas zu optimistisch, was die Zeit anbelangt bis zur Marktreife

Bis 2015/2016 könnten wir aber schon den MemoryCube eventuell in ersten Systemen sehen. Vorher glaube ich nicht wirklich leider.

 

[Threshold]

Vielleicht der Grund wieso Intel an Sockel 2011 noch eine Weile festhält und erst 2013 neue CPUs bringt damit sie für den Nachfolger gleich auf DDR4 setzen können.
Das dauert dann aber noch eine Weile. Wann soll Haswell EP kommen? 2014? Oder 2015?
Das bringt die Sache aber sehr durcheinander wie ich finde. Haswell DT kommt schon nächstes Jahr. Wenn als Haswell DT auf dem Markt ist gibt es auf der andere Seite immer noch Sandy EP. Ein riesen Unterschied.
Es scheint als wenn Intel seinen Fahrplan nicht mehr halten kann oder will.

 

[ruyven_macaran]

Also mit einem anderen war nVidia mit ihrem 5.ten Tegra-Kern gemeint, der von den anderen 4 abweicht und für kleinere Aufgaben herhalten muss.

Bei Haswell EP gibts die "Gerüchte", das man hier ähnlich wie AMD die ersten Server-APUs bekommt. Also CPU+iGPU.

Von 16 Kernen wird hier einfach gesprochen, weil eben Larrabee hier die "iGPU" stellen soll, was man auch als Kern ansehen kann. Die Frage ist nur, wie sich Intel die "Kerne" für Larrabee ALUs hinfriemelt. Wahrscheinlich wird 8/8 werden, wobei die Larrabee Dinger noch breiter werden als aktuell. Denn 8 Larrabee Kerne wären schon bischen wenig. Eventuell fasst man aber auch 4 Larrabee Kerne zusammen zu einem Haswell-iGPU-"Kern".

Solche Gerüchte sind ja hartneckig (weil naheliegend) - wie aktuell und wie fundiert sind deine Quellen da?
Ich persönlich würde jedenfalls erwarten, dass Intel erst eine Generation von Erweiterungskarten vorschickt, ehe sie eine integrierte Fassung fest einplanen. gpGPU erfordert nun einmal sehr spezifische Optimierungen und man opfer nicht 50% der DIE-Fläche für eine Henne-/Ei-Geschichte, wenn man es vermeiden kann. Sowas ist einfach zu riskant. Zumal sich, bei der anhaltend fehlenden Computeshader/OCL-Nutzung im Endkundenbereich, die Weiterentwicklung Larrabees zur prinzipiellen iGPU nicht lohnt.

Ungeachtet der Anwesenheit etwaiger Grafikeinheiten bleibt aber der Fakt, dass Intel diese bislang nie als Kerne gezählt oder auch nur tituliert hat und auch bei den Knights nicht müde wird, die SIMDs zu betonen - um die es ja nunmal auch primär geht.

Vielleicht der Grund wieso Intel an Sockel 2011 noch eine Weile festhält und erst 2013 neue CPUs bringt damit sie für den Nachfolger gleich auf DDR4 setzen können.

Intel hatte SD/DDR1, DDR1/DDR2 und DDR2/DDR3 Controller. Unwahrscheinlich, dass sie ihre Produktplanung für eine reine DDR4 Lösung anpassen - das wäre auch wiederum ein relativ großes Risiko, denn ohne zeitgleiche Verfügbarkeit passenden, bezahlbaren Speichers legen sich Platformen gern auf die Nase. Das hat gerade Intel zweimal eindrucksvoll bewiesen.

Das dauert dann aber noch eine Weile. Wann soll Haswell EP kommen? 2014? Oder 2015?
Das bringt die Sache aber sehr durcheinander wie ich finde. Haswell DT kommt schon nächstes Jahr. Wenn als Haswell DT auf dem Markt ist gibt es auf der andere Seite immer noch Sandy EP. Ein riesen Unterschied.
Es scheint als wenn Intel seinen Fahrplan nicht mehr halten kann oder will.

Intels "Fahrpläne" waren schon immer eher auf dem Niveau der griechischen denn der deutschen Bahn (geschweige denn stimmig). Wenn man Tick-Tock von Nehalem durchzählt (afaik wurde es damals erstmals öffentlich beworben?), dann müsste Haswell-E(P), als Nach-Nach-Nach-Nachfolger von Gainestown/Bloomfield, im November diesen Jahres erscheinen. Nimmt man noch die rückwirkend eingegliederte Core-Familie dazu, wäre es 6 Jahre nach Conroe sogar im September der Fall - und das mit leichter Verzögerung nach den Haswell-Desktopmodellen, deren erste Extreme-Version, als Ur-Ur-Ur-Ur-Enkel des X6800 in 6 Wochen anstände. (und man beachte, dass Intel uns in diesem Zweig eigentlich noch einen Lynnfield-Nachfolger in der Westmere-Generation schuldig ist)

 

[Skysnake]

Solche Gerüchte sind ja hartneckig (weil naheliegend) - wie aktuell und wie fundiert sind deine Quellen da?

Ziemlich aktuell, und ich denke, das es da auch etwas gibt, aber ob das dann eine Generation früher oder später kommt, oder gar eine größere Änderung bekommt ist halt so ne Sache. Man hört halt hier etwas und mal dort etwas, was dann eben teilweise auch erst durch neue Infos dann einen Sinn ergibt.

Ich persönlich würde jedenfalls erwarten, dass Intel erst eine Generation von Erweiterungskarten vorschickt, ehe sie eine integrierte Fassung fest einplanen. gpGPU erfordert nun einmal sehr spezifische Optimierungen und man opfer nicht 50% der DIE-Fläche für eine Henne-/Ei-Geschichte, wenn man es vermeiden kann. Sowas ist einfach zu riskant. Zumal sich, bei der anhaltend fehlenden Computeshader/OCL-Nutzung im Endkundenbereich, die Weiterentwicklung Larrabees zur prinzipiellen iGPU nicht lohnt.

Naja, es gibt ja schon länger eine Erweiterungskarte. Bzgl. Larrabee, war das Ding ja schon immer als GPU geplant, nur das man halt vieles in Software machen wollte. Ich habe ja auch ganz bewusst "iGPU" geschrieben. Ich weiß jetzt aber auch nicht, was man allgemein bzgl. MIC so weiß, zumal ich ja nichts weiß.

Ungeachtet der Anwesenheit etwaiger Grafikeinheiten bleibt aber der Fakt, dass Intel diese bislang nie als Kerne gezählt oder auch nur tituliert hat und auch bei den Knights nicht müde wird, die SIMDs zu betonen - um die es ja nunmal auch primär geht.

Ich kann mich nicht daran erinnern, was Intel dazu anscheinend sagt...

MIC ist auf jeden Fall nicht Larrabee...

Intel hatte SD/DDR1, DDR1/DDR2 und DDR2/DDR3 Controller. Unwahrscheinlich, dass sie ihre Produktplanung für eine reine DDR4 Lösung anpassen - das wäre auch wiederum ein relativ großes Risiko, denn ohne zeitgleiche Verfügbarkeit passenden, bezahlbaren Speichers legen sich Platformen gern auf die Nase. Das hat gerade Intel zweimal eindrucksvoll bewiesen.

OH JA! Da haste absolut Recht. Wenn aber mal MemoryCube kommt, wirst du diese Doppelstrategie nicht fahren können.

[/quote]
Intels "Fahrpläne" waren schon immer eher auf dem Niveau der griechischen denn der deutschen Bahn (geschweige denn stimmig). Wenn man Tick-Tock von Nehalem durchzählt (afaik wurde es damals erstmals öffentlich beworben?), dann müsste Haswell-E(P), als Nach-Nach-Nach-Nachfolger von Gainestown/Bloomfield, im November diesen Jahres erscheinen. Nimmt man noch die rückwirkend eingegliederte Core-Familie dazu, wäre es 6 Jahre nach Conroe sogar im September der Fall - und das mit leichter Verzögerung nach den Haswell-Desktopmodellen, deren erste Extreme-Version, als Ur-Ur-Ur-Ur-Enkel des X6800 in 6 Wochen anstände. (und man beachte, dass Intel uns in diesem Zweig eigentlich noch einen Lynnfield-Nachfolger in der Westmere-Generation schuldig ist)[/QUOTE]
Sag doch so was nicht, sonst kommen gleich irgendwelche Leute dahergelaufen

Vielleicht der Grund wieso Intel an Sockel 2011 noch eine Weile festhält und erst 2013 neue CPUs bringt damit sie für den Nachfolger gleich auf DDR4 setzen können.
Das dauert dann aber noch eine Weile. Wann soll Haswell EP kommen? 2014? Oder 2015?
Das bringt die Sache aber sehr durcheinander wie ich finde. Haswell DT kommt schon nächstes Jahr. Wenn als Haswell DT auf dem Markt ist gibt es auf der andere Seite immer noch Sandy EP. Ein riesen Unterschied.
Es scheint als wenn Intel seinen Fahrplan nicht mehr halten kann oder will.

Ich weiß jetzt nicht, ob sich dazu schon mal geäußert wurde, aber SB-E bleibt nicht bis Haswell kommt. Da kommt noch was davor.

 

[Threshold]

Ich weiß jetzt nicht, ob sich dazu schon mal geäußert wurde, aber SB-E bleibt nicht bis Haswell kommt. Da kommt noch was davor.

Ja. Ivy E kommt. Also Desktop 8 Kerner. Aber nach meiner Vermutung wird es nur einen geben und den wird Intel als Extreme Edition vermarkten. Für 1000€. Also das was sie anfangs auch beim Gulftown gemacht haben.
Vielleicht kommt noch ein Ivy 6 Kerner aber der Leistungsunterschied ist viel zu gering als dass sich da ein Wechsel lohnen wird.

 

[Skysnake]

Und was hat das jetzt damit zu tun, das noch etwas kommt?

 

[ruyven_macaran]

Naja, es gibt ja schon länger eine Erweiterungskarte.

Mir wären keine auf dem freien Markt bekannt. Geschweige denn welche, die sich größerer Beliebtheit erfreuen würden.

Bzgl. Larrabee, war das Ding ja schon immer als GPU geplant, nur das man halt vieles in Software machen wollte. Ich habe ja auch ganz bewusst "iGPU" geschrieben. Ich weiß jetzt aber auch nicht, was man allgemein bzgl. MIC so weiß, zumal ich ja nichts weiß.

MIC ist auf jeden Fall nicht Larrabee...

keine Ahnung, wann und wo Intel von dem einen auf den anderen Begriff umgewechselt ist. Fakt ist, dass die ersten ""Larrabee""-Gerüchte noch eine komplette Palette mit Grafik- und gpGPU-Karten und sogar Co-Prozessoren versprechen; dass die Kernarchitektur sich nicht sonderlich unterscheidet (nicht mehr, als im Rahmen normaler Entwicklung zu erwarten) und dass Larrabee als reine Grafikkarte schon immer den Eindruck eines Notbehelfes machen würde, der eigentlich eher eine gpGPU-Karte mit DirectX-Emulation darstellte.

OH JA! Da haste absolut Recht. Wenn aber mal MemoryCube kommt, wirst du diese Doppelstrategie nicht fahren können.

Dazu weiß ich zuwenig über die Ansteuerung. Was so durch die Medien geisterte, beschränkte sich ja auf den physischen Aufbau - und dem Speichercontroller ist es wurscht, ob man die Speicherchips nebeneinander auf ein Modul packt oder in einem Package DIE auf DIE stapelt. Da zählt nur das Speicherbus-Protokoll und das muss man nicht zwingend in so großem Maße ändern, dass es inkompatibel wird. In Anbetracht der direkten Interaktion zwischen Intel und den Speicherherstellern und der recht schnellen erwarteten Markteinführung dieses (vermeintlich?) neuen Konzeptes würde es mich nicht einmal wundern, wenn man die aktuellen Prototypen mit wenig modifzierten DDR3-Controllern anspricht. Alles komplexere würde eine längere Entwicklungsphase mit Vorführung erster Laborsamples lange vor der Markteinführung erwarten.

Sag doch so was nicht, sonst kommen gleich irgendwelche Leute dahergelaufen

Falls du Hardcore-AMD-Fanboys meinst: Die haben keine Lust, sich auf eine "Intel ist spät dran"-"aber immer noch schneller "-Diskussion einzulassen

Ich weiß jetzt nicht, ob sich dazu schon mal geäußert wurde, aber SB-E bleibt nicht bis Haswell kommt. Da kommt noch was davor.

Das IB-E kommt, wurde in diesem Thread afaik schon mehrfach erwähnt, auch ohne dich

Aber recht hat er trotzdem: Nach aktuellem Stand der Gerüchte dürfte der Haswell-DT-Launch vor vollständiger Ablösung der SB-E-Modelle liegen. Schließlich bleibt die Plattform erhalten und die Leistungswerte passen zu einer "on-top"-Einführung, bei der SB-Es noch längere die Zeit als unteres Ende der Plattform im Program bleiben.

 

[Threshold]

Und was hat das jetzt damit zu tun, das noch etwas kommt?

Was soll denn sonst kommen außer Ivy E?

 

[Skysnake]

Was soll denn sonst kommen außer Ivy E?

Ich glaub wir reden gerade aneinander vorbei

Ja, IB-E sollte halt noch vor den kleinen Haswells kommen, oder eben kurz danach, aber in dem Zeitrahmen.

Mir wären keine auf dem freien Markt bekannt. Geschweige denn welche, die sich größerer Beliebtheit erfreuen würden.

Na frei verfügbar ist da nichts, da haste recht, aber die Larrabees, KnightsKorners, FerryKnights und MICs wuseln ja schon ne ganze Weile rum. Man weiß ja auch, auf was die Dinger aufbauen. Dem Pentium (4?) halt. Damit verrät man ja jetzt auch nichts unbekanntes. Das ist schon lange bekannt, da das ja auch ein Vorzug von "MIC" ist. Das Ding kann x86 Code ausführen. Du brauchst also gar kein OpenCL. DAS ist ja mit ein entscheidender Faktor, wo "MIC" einen Vorzug gegenüber GPUs hat. Du braucht halt kein OpenCL oder gar das propritäre CUDA. Du nimmst deinen x86 Code, der schon mit XY parallelisiert ist, machst noch ein paar Anpassungen und haust es durch den Compiler. That´s it. Das ist zwar nicht optimal, aber man soll schon einiges an Mehrleistung rausholen mit verdammt wenig Aufwand, und genau DAS ist der Knackpunkt, wo "MIC" AMD und nVidia echte Kopfschmerzen bereiten könnte. Bei denen brauchste nämlich viel Zeit, Geld UND Leute, die sich damit auskennen, um was zu reisen. "MIC" ist dem ähnlicher, was die Leute auch früher schon gemacht haben. Man muss nur schauen wie sich die Perf/W entwickelt/darstellt. "MIC" Soll ja aber mehr als 1 DP-TFlop/s in DGEMM schaffen, und dabei wohl einfacher zu programmieren sein als GPUs, wobei sich das erst noch in freier Wildbahn zeigen muss. Wenn die Crecks meinen das Ding wäre easy zu programmieren, muss das nicht für die Allgemeinheit gelten.

Btw. geht AMD ja auch in diese Richtung mit HSA und der immer stärkeren Verschmelzung von CPU und iGPU inkl so Sachen wie kohärenter (gemeinsamer) Adressraum, Preemtive Sheduling für die iGPU und sogar Task-Switching zwischen CPU und iGPU. Das nur so am Rande. Die Marschrichtung ist für Intel und AMD die Gleiche, auch wenn nach meinem Dafürhalten Intel erst etwas später die Marschrichtung von AMD verfolgt hat. Das ist mir jetzt aber auch erst Rückblickend klar, wenn man sich die Sachen so anschaut (keiner hat einen Internen blick auf beide Firmen, daher kann man es nicht 100% sicher sagen, wer zuerst welche Marschrichtung eingeschlagen hat).

Es kommen auf jeden Fall noch spannende Zeiten auf uns zu, auch wenn hier wohl den wenigsten die Entwicklungen am Anfang schmecken werden, wobei ich eher sogar von langfristig ausgehe.

Dazu weiß ich zuwenig über die Ansteuerung. Was so durch die Medien geisterte, beschränkte sich ja auf den physischen Aufbau - und dem Speichercontroller ist es wurscht, ob man die Speicherchips nebeneinander auf ein Modul packt oder in einem Package DIE auf DIE stapelt. Da zählt nur das Speicherbus-Protokoll und das muss man nicht zwingend in so großem Maße ändern, dass es inkompatibel wird. In Anbetracht der direkten Interaktion zwischen Intel und den Speicherherstellern und der recht schnellen erwarteten Markteinführung dieses (vermeintlich?) neuen Konzeptes würde es mich nicht einmal wundern, wenn man die aktuellen Prototypen mit wenig modifzierten DDR3-Controllern anspricht. Alles komplexere würde eine längere Entwicklungsphase mit Vorführung erster Laborsamples lange vor der Markteinführung erwarten.

Dazu kann ich eigentlich nur das Video hier verlinken, außer halt der Memory-Cube HP, wo auch ein gutes! Video zu sehen ist.

https://www.youtube.com/watch?v=tO6yLunfdjA

Da wird doch einiges erzählt, insbesondere an Hintergründen usw., was den Leuten durchaus die Beweggründe klar machen sollten, warum man gewisse Sachen macht, und wohin die Reise geht, bzw. wohin Sie gehen muss.

Den DDR3 Memory-Controller solltest du komplett wegschmeisen können. Die zugrunde liegende Technik ist vollständig anders, bzw. sollte Sie meinem Verständnis nach vollständig anders sein. Tahiti soll ja aber auch angeblich XDRAM unterstützen... Also unmöglich ist es nicht, das man beides parallel drin hat, einfach um mehr flexibilität zu haben in der Übergangszeit. Das sind halt rein politische Entscheidungen.

PS: Das Ende vom Video ist lustig, auch wenn er damit HOFFENTLICH jeden gelangweilt hat, der da gesessen hat.....

Aber recht hat er trotzdem: Nach aktuellem Stand der Gerüchte dürfte der Haswell-DT-Launch vor vollständiger Ablösung der SB-E-Modelle liegen. Schließlich bleibt die Plattform erhalten und die Leistungswerte passen zu einer "on-top"-Einführung, bei der SB-Es noch längere die Zeit als unteres Ende der Plattform im Program bleiben.

Ich gehe schon von einem kompletten Austausch aus, zumindest bei den Xeons.

 

[ruyven_macaran]

Na frei verfügbar ist da nichts, da haste recht, aber die Larrabees, KnightsKorners, FerryKnights und MICs wuseln ja schon ne ganze Weile rum. Man weiß ja auch, auf was die Dinger aufbauen. Dem Pentium (4?) halt.

Die x86 Kerne sind, das hat Intel afaik offiziell bekanntgegeben, Pentium1-Ableitungen. Ergänzt allerdings um sehr mächtige SIMD (oder war es sogar MIMD?) Einheiten - die die eigentliche Rechenleistung aufbringen. Deswegen ist die "x86-Kompatibilität" imho auch kein so großer Vorteil, wie es auf den ersten Blick erscheint: Zwar läuft deine bestehende Software - aber um von dem zusätzlichen Potential zu profitieren, muss das ganze trotzdem massiv an die andere Ausführungsstruktur (vom Caching ganz zu schweigen) angepasst werden. Mit einer normalen CPU hat das in etwa soviel zu tun, wie eine AES2-Einheit mit einem 80286. Nur mit dem Unterschied, das erstere wenigstens in CPUs zu finden ist, die auch basalen IA16-Code schneller ausführen können. Larrabees Erben dagegen dürften in Sachen IA64-Leistung spürbar langsamer (sowohl pro Watt, vor allem aber pro Thread) sein, als z.B. ein Xeon.
Es bleibt abzuwarten, wie gut Intels Entwicklerwerkzeuge ansprechen, sprich wieviel der Compiler selbsständig auf die SIMDs auslagern kann. Aber imho dürfte es bei heutiger, gut optimierter Software (und wen interessiert Software, die man schon heute nicht optimieren muss?) schon allein an der Parallelität scheitern. Wer längt sein Programm schon auf 80 Kerne aus, wenn eh nur 16 in einer Workstation verfügbar sind? Und das ist nur eine Karte. Idealerweise sollte es "morgen" auf 4 mal 80 Kernen (angebunden via lahmen PCIe und mit vergleichsweise kleinem, nicht aufrüstbaren lokalen, schnellen Speicher) laufen? Unter Nutzung eines neuen Befehlssatzes?
Ich bin kein Experte, aber für mich klingt das nach Arbeit und der Hauptunterschied zu CUDA besteht nur noch darin, dass sie in gewohnten Entwicklungsumgebungen ablaufen kann.

Btw. geht AMD ja auch in diese Richtung mit HSA und der immer stärkeren Verschmelzung von CPU und iGPU inkl so Sachen wie kohärenter (gemeinsamer) Adressraum, Preemtive Sheduling für die iGPU und sogar Task-Switching zwischen CPU und iGPU. Das nur so am Rande. Die Marschrichtung ist für Intel und AMD die Gleiche, auch wenn nach meinem Dafürhalten Intel erst etwas später die Marschrichtung von AMD verfolgt hat. Das ist mir jetzt aber auch erst Rückblickend klar, wenn man sich die Sachen so anschaut (keiner hat einen Internen blick auf beide Firmen, daher kann man es nicht 100% sicher sagen, wer zuerst welche Marschrichtung eingeschlagen hat).

AMD zumindest schon sehr früh (genauer: Seit der ATI-Übernahme) darüber spekuliert. Aber imho ist das in der Praxis auch egal. Wenn man sich die Energie- und Platzeffizienz von immer mächtigeren gpGPUs anguckt (die ersten Firestreams > die ersten Teslas > GCN > Knights Corner) und im Gegenzug die von immer paralleleren CPU-Konzepten (Netburst > Sledgehammer > Core i -EX > Bulldozer > Atom-Cluster > hypothetischer Larrabee-Co-Prozessor), dann wird für mich eines klar:
Es geht nicht um die Vereinigung zweier verschiedener Ansätze zu einer Einheit, sondern um den Ersatz beider durch eine Zwischenstufe. Es ist nunmal weder die eine noch die andere Technik prinzipiell besser, sondern sie waren traditionell für zwei grundverschiedene Aufgabenstellungen optimiert - und mittlerweile schwindet dieser Unterschied auf Softwareebene ("CPU"-Code wird paralleler, "GPU"-Code komplexer) und das spiegelt sich in den Architekturen wieder.

Da wird doch einiges erzählt, insbesondere an Hintergründen usw., was den Leuten durchaus die Beweggründe klar machen sollten, warum man gewisse Sachen macht, und wohin die Reise geht, bzw. wohin Sie gehen muss.

Den DDR3 Memory-Controller solltest du komplett wegschmeisen können.

Ich hab das Video zwar stellenweise übersprungen - aber zu HMC konnte ich nur die eine allgemein Vorstellung ~Anfang letztes Drittel finden. Da wird gar nichts zur Ansteuerungslogik gesagt, sondern stattdessen das Interposter-Konzept vorgestellt (das mit Haswell wohl ziemlich sicher nicht als RAM kommt - und imho auch danach so schnell nicht, weil es einfach zu unflexibel ist).
Zur Ansteurungslogik wird kein Wort verloren.

PS: Das Ende vom Video ist lustig, auch wenn er damit HOFFENTLICH jeden gelangweilt hat, der da gesessen hat.....

Er hätte wenigsten etwas weniger banala Zahlen nehmen können
Ganz abgesehen davon, dass eine aktuelle x86-Office-Kombination schon z.T. schon bei einer Substraktion von zwei Zahlen mit drei zählenden Stellen Fehler produziert

Ich gehe schon von einem kompletten Austausch aus, zumindest bei den Xeons.

Wir werden sehen. Bei Bloomfield/Gulftown hat er sich jedenfalls ewig hingezogen.

 

[Skysnake]

Die x86 Kerne sind, das hat Intel afaik offiziell bekanntgegeben, Pentium1-Ableitungen. Ergänzt allerdings um sehr mächtige SIMD (oder war es sogar MIMD?) Einheiten - die die eigentliche Rechenleistung aufbringen. Deswegen ist die "x86-Kompatibilität" imho auch kein so großer Vorteil, wie es auf den ersten Blick erscheint: Zwar läuft deine bestehende Software - aber um von dem zusätzlichen Potential zu profitieren, muss das ganze trotzdem massiv an die andere Ausführungsstruktur (vom Caching ganz zu schweigen) angepasst werden. Mit einer normalen CPU hat das in etwa soviel zu tun, wie eine AES2-Einheit mit einem 80286. Nur mit dem Unterschied, das erstere wenigstens in CPUs zu finden ist, die auch basalen IA16-Code schneller ausführen können. Larrabees Erben dagegen dürften in Sachen IA64-Leistung spürbar langsamer (sowohl pro Watt, vor allem aber pro Thread) sein, als z.B. ein Xeon.

Es ist trotzdem ein gewichtiger Grund, denn du kannst damit eben ganz banalen x86 Code ausführen. Das geht im einen extrem in die Richtung von Atom-Mini-Clustern, wenn du einfach die Kerne nutzt, und bei Kernen + SIMD (MIMD ist es meines Wissens nach nicht pro Kern, aber jeder Kern kann anderen Code ausführen) kannste dann halt den CPU-SSE/AVX-Style verwenden. Ich empfinde die Dinger schon ähnlicher einer normalen CPU als du das einschätzt. Zudem soll Intels Compiler wirklich gut funktionieren. Man hat ja auch sehr viel Erfahrung im Compilerbau.

Es bleibt abzuwarten, wie gut Intels Entwicklerwerkzeuge ansprechen, sprich wieviel der Compiler selbsständig auf die SIMDs auslagern kann. Aber imho dürfte es bei heutiger, gut optimierter Software (und wen interessiert Software, die man schon heute nicht optimieren muss?) schon allein an der Parallelität scheitern. Wer längt sein Programm schon auf 80 Kerne aus, wenn eh nur 16 in einer Workstation verfügbar sind? Und das ist nur eine Karte. Idealerweise sollte es "morgen" auf 4 mal 80 Kernen (angebunden via lahmen PCIe und mit vergleichsweise kleinem, nicht aufrüstbaren lokalen, schnellen Speicher) laufen? Unter Nutzung eines neuen Befehlssatzes?
Ich bin kein Experte, aber für mich klingt das nach Arbeit und der Hauptunterschied zu CUDA besteht nur noch darin, dass sie in gewohnten Entwicklungsumgebungen ablaufen kann.

Besser als das was man von CUDA her kennt wohl recht sicher, und auch besser als das OpenCL Zeugs. Allein, das man die normale Entwicklungsumgebung und die normalen seit langem getesteten und entwickelten Tools nutzen kann ist halt WIRKLICH ein Segen. Geh dabei auch weg vom Workstation-Denken. Bei "MIC" sollte man eher direkt an Cluster denken, also MPI-Umgebungen. Da ist die Parallelität eh schon da und wird auch genutzt. Allgemein sollte man wenn man über GPU/"MIC" Einsätz spricht immer davon ausgehen, das man hochgrad parallelisierbaren Code hat, und der nicht nur auf 10 oder 20 Cores vernünftig performt, sondenr auch auf 500, tausenden oder hundertausenden von Cores läuft.

Jetzt noch was aus Entwicklersicht bzgl. den Tools und dem Vorteil von x86:
Ich hab jetzt erst neulich mit jemanden ca. 20h zusammen vor nem Problem gesessen, um eine GPU-Anwendung zu debuggen. Ich sags dir, die Debugging-Möglichkeiten einer CPU sind gewaltig besser als das was man mit CUDA oder OpenCL hat. Das ist absolut nicht zu vergleichen. Wäre das reiner CPU-Code gewesen, wären wir sicherlich in 5h fertig gewesen, wenn überhaupt, da wahrscheinlich die Probleme nie aufgetaucht wären. GPU-Programme debuggen ist ein GRAUSS!
Ich sag daher immer, wenns um GPU-Programme geht, und ein Fehler auftaucht der debugt werden muss und wie lange das dauert:"Kann in ner Stunde behoben sein, kann aber auch sein dass ich in 3 Tagen noch dran sitze und den Fehler nicht gefunden habe, das Debuggen ist halt einfach hässlich, weil man nicht direkt an die Daten ran kommt, und die APIs teilweise halt extrem hinderlich sind bzgl der Fehlersuche sind, so Marke: "Es ist ein Fehler aufgetaucht"", tja... irgndwann, irgendwo, geh mal suchen..."
Ich seh daher diesen x86 Ansatz als unglaublich schwergewichtigen Vorteil. Was bringts dir, wenn du 20% mehr Performence/Watt rauskitzeln kannst aus den GPUs von AMD und nVidia, du aber 4 mal so lange dran entwickeln musst, und dich dann noch um die Leute, die das gut können, schlagen musst, und auf der anderen Seite halt nahezu jeder Wald und Wiesen Programmierer (ja ich weiß überspitzt) zumindest lauffähigen Code generieren kann, der dann auch noch relativ einfach zu optimieren ist.

AMD zumindest schon sehr früh (genauer: Seit der ATI-Übernahme) darüber spekuliert. Aber imho ist das in der Praxis auch egal. Wenn man sich die Energie- und Platzeffizienz von immer mächtigeren gpGPUs anguckt (die ersten Firestreams > die ersten Teslas > GCN > Knights Corner) und im Gegenzug die von immer paralleleren CPU-Konzepten (Netburst > Sledgehammer > Core i -EX > Bulldozer > Atom-Cluster > hypothetischer Larrabee-Co-Prozessor), dann wird für mich eines klar:
Es geht nicht um die Vereinigung zweier verschiedener Ansätze zu einer Einheit, sondern um den Ersatz beider durch eine Zwischenstufe. Es ist nunmal weder die eine noch die andere Technik prinzipiell besser, sondern sie waren traditionell für zwei grundverschiedene Aufgabenstellungen optimiert - und mittlerweile schwindet dieser Unterschied auf Softwareebene ("CPU"-Code wird paralleler, "GPU"-Code komplexer) und das spiegelt sich in den Architekturen wieder.

Naja, da muss man sehr aufpassen, wie das ausgelegt wird. Du sprichst es ja schon absolut richtig an. CPUs können Dinge effizient! erledigen, die GPUs nicht effizient können und umgekehrt. Daher will/muss man leider beides nutzen, um die Effizienz zu steigern. Das Problem dabei ist halt, dass das Einbinden der GPU imo noch sehr viel Overhead produziert, und daher viele Aufgaben gar nicht auf GPUs laufen können, weil einfach der Overhead schon alles kaputt macht. Wenn halt allein der Overhead der GPU mehr Energie verbraucht, oder länger dauert, als es einfach auf der CPU laufen zu lassen, ist es halt einfach sinnfrei, da die GPU zu verwenden. Daher muss man schon beides zu "einer" Einheit verbinden. Halt Contextswitch ermöglichen, damit die CPU und iGPU/GPU eben so zusammen arbeiten können, wie das heutzutage eben Int-Cores und FPU in der CPU tun.

Daher ist es schon die "vereinigung zweier Ansätze in einer Einheit" nur bleiben eben gewisse Differenzierungen erhalten, wie bei den Int-Cores und den FPUs. Heute würde aber auch keiner mehr sagen, Int-Core und FPU wären zwei getrennte Einheiten. Weißte was ich meine?

Ich hab das Video zwar stellenweise übersprungen - aber zu HMC konnte ich nur die eine allgemein Vorstellung ~Anfang letztes Drittel finden. Da wird gar nichts zur Ansteuerungslogik gesagt, sondern stattdessen das Interposter-Konzept vorgestellt (das mit Haswell wohl ziemlich sicher nicht als RAM kommt - und imho auch danach so schnell nicht, weil es einfach zu unflexibel ist).
Zur Ansteurungslogik wird kein Wort verloren.

Ja, schau mal noch hier rein: Hybrid Memory Cube Consortium - The Technology Ab 2:20.
Ist aber trotzdem gut, wenn du dir das andere Video großteils angeschaut hast, dann verstehst du, was so toll an HMC ist.

Ich versteh allerdings auch nicht, was du mit "einfach zu unflexibel" meinst. Interposer kannst du nehmen, musst du aber nicht. Du hast halt nur immer den Logic-Layer und drüber den Speicher, die Anbindung steht dir apriori erstmal frei, wobei man eben eine differenzielle Punkt zu Punkt Verbindung setzt wie bei PCI-E, wenn ich das richtig verstanden habe. DDRx ist halt noch ein Bus. Das ist eine signifikante Änderung. Ganz abgesehen davon, das man eben mit HMC ein zichfaches der Bandbreite je "Channel" bekommt als bei DDR3/4.

 

[ruyven_macaran]

Was bringts dir, wenn du 20% mehr Performence/Watt rauskitzeln kannst aus den GPUs von AMD und nVidia, du aber 4 mal so lange dran entwickeln musst, und dich dann noch um die Leute, die das gut können, schlagen musst, und auf der anderen Seite halt nahezu jeder Wald und Wiesen Programmierer (ja ich weiß überspitzt) zumindest lauffähigen Code generieren kann, der dann auch noch relativ einfach zu optimieren ist.

Programmierermangel ist etwas, dass sich in Zeiträumen beheben lässt, die kürzer sind, als die Zeit, die Intel offensichtlich braucht, um was fertigzustellen - und Entwicklungszeitaufwand vs. Betriebsaufwand ist bei kommerzieller Software ein extrem empfindlicher Punkt. 20% mehr Leistung für ein bißchen mehr Bugfixing (das eh arme Inder machen müssen)? Sonst arbeitet man da drei major Releases dran und muss den halben Kerncode umschreiben!
Wenn sich die Programmierer selsbt nicht querstellen (stehen ja so ein bißchen im Ruf, unflexibel zu sein ), sehe ich hier keinen unüberwindbaren Nachteil. Man darf vor allen Dingen eins nicht vergessen: Die eine Firma, die in einem Segment einmal diesen Aufwand tätigt, ist danach dauerhaft die Firma, die 20% besser ist. Und "20% besser im Schnitt" bedeutet meistens "auch im Worst Case noch einen Tick besser". Und "immer die beste Wahl" bedeutet ganz schnell eine Marktabdeckung, die nur noch einstellige Reste lässt.

Daher ist es schon die "vereinigung zweier Ansätze in einer Einheit" nur bleiben eben gewisse Differenzierungen erhalten, wie bei den Int-Cores und den FPUs. Heute würde aber auch keiner mehr sagen, Int-Core und FPU wären zwei getrennte Einheiten. Weißte was ich meine?

Bei AMD macht man das bekanntermaßen
Und das, obwohl beide über den gleichen Befehlssatz, Decoder und Scheduler angesteuert werden und die gleichen Caches nutzen und wir fast alles, was der int-Core macht, auch mit den SIMDs machen könnten. Und davon sind wir mit heutigen GPUs aber meilenweit entfernt, denn die haben vollkommen andere Laufzeiten, andere Befehlsstrukturen, etc. - glaube nicht, dass man da einen Scheduler bauen kann, der beides effizient ansteuern kann (vom Decoding, dass bei GPUs primär der Treiber erledigt, ganz zu schweigen. Das könnte allenfalls in ein Itanium-System passen).

Ja, schau mal noch hier rein: Hybrid Memory Cube Consortium - The Technology Ab 2:20.

Hmm - nicht neues. Ich will wissen, ob sich beim Verbindungsprotokoll großartig was tut. Was sie beschreiben sagt ja nur: "HMC kann eng und locker angebunden werden". Das kann DDR bekanntermaßen auch - siehe Grafikkarten und Mainboards. Nichts neues.

Ich versteh allerdings auch nicht, was du mit "einfach zu unflexibel" meinst. Interposer kannst du nehmen, musst du aber nicht.

Intel hat es nur mit Interposer präsentiert. Daraus resultieren natürlich einige Vorteile, weil du sehr breite Verbindungen recht effektiv umsetzen kannst. Aber das löst nicht alle Probleme und es ist eben unflexibel: Die RAM-Größe wird fest an die CPU gekoppelt. Da gibt es aber derzeit enorme Unterschiede in den verkauften Systemen, wieviel Speicher der einzelne Nutzer denn haben will/braucht. Diese Flexibilität ist für attratkive Angebote zwingend nötig, du kannst nicht von jeder CPU ein halbes Dutzend verschiedene Varianten mit unterschiedlichem Speicherausbau fertigen.

Du hast halt nur immer den Logic-Layer und drüber den Speicher, die Anbindung steht dir apriori erstmal frei, wobei man eben eine differenzielle Punkt zu Punkt Verbindung setzt wie bei PCI-E, wenn ich das richtig verstanden habe. DDRx ist halt noch ein Bus. Das ist eine signifikante Änderung. Ganz abgesehen davon, das man eben mit HMC ein zichfaches der Bandbreite je "Channel" bekommt als bei DDR3/4.

"Je Channel" ist wurscht. Was zählt, ist "je Leitung" und "bei welcher Latenz". Wenn ich ein 256 Bit XDR-Modul baue, habe ich trotz Bus auch Bandbreite ohne Ende - aber keinen Kosten/Nutzen-Vorteil. Wie HMC da etwas verbessern will, habe ich noch nicht gehört, sieht man mal von der Punkt-zu-Punkt-Verbindung und der Termination durch einen zwischengeschalteten, integrierten Controller ab.
Aber ersteres ist zweischneidig, denn es bedeutet wiederum eine drastische Einschränkung des Ausbaus, weil ich nur noch eine Speichereinheit pro Kanal verbauen kann. Kein Aufrüsten, keine extra großen Speicherbestückungen mehr - das werden weder Enduser noch Serveranbieter als Vorteil gegenüber heutigem 1-bis-3-DIMM-Plattformen empfinden. Und letzteres ist nur eine leichte Verbesserung gegenüber FB-DIMMs und es ist brandgefährlich, was Latenzen angeht. Und da gibts derzeit imho sogar mehr Optimierungsbedarf, als bei der Bandbreite.

 

[Skysnake]

Programmierermangel ist etwas, dass sich in Zeiträumen beheben lässt, die kürzer sind, als die Zeit, die Intel offensichtlich braucht, um was fertigzustellen - und Entwicklungszeitaufwand vs. Betriebsaufwand ist bei kommerzieller Software ein extrem empfindlicher Punkt. 20% mehr Leistung für ein bißchen mehr Bugfixing (das eh arme Inder machen müssen)? Sonst arbeitet man da drei major Releases dran und muss den halben Kerncode umschreiben!
Wenn sich die Programmierer selsbt nicht querstellen (stehen ja so ein bißchen im Ruf, unflexibel zu sein ), sehe ich hier keinen unüberwindbaren Nachteil. Man darf vor allen Dingen eins nicht vergessen: Die eine Firma, die in einem Segment einmal diesen Aufwand tätigt, ist danach dauerhaft die Firma, die 20% besser ist. Und "20% besser im Schnitt" bedeutet meistens "auch im Worst Case noch einen Tick besser". Und "immer die beste Wahl" bedeutet ganz schnell eine Marktabdeckung, die nur noch einstellige Reste lässt.

Das hat weniger mit "nicht wollen" als mit "nicht können" zu tun. GPU-Programmierung ist echt ätzend, und verlangt ein starkes umdenken, und auch VIEL gespür für Probleme und Lösungen. Oft macht GPGPU halt einfach gar keinen Sinn, weil man schon vorher absehen kann, dass das einfach nicht funktionieren kann. Diese Flaschenhälse aber zu erkennen ist gar nicht einfach. Da braucht es echt viel Erfahrung für. Ganz abgesehen davon, das es so abartig viel zu beachten gibt um effizienten Code zu schreiben, das es echt nicht mehr feierlich ist.
Wenn ich z.B. 5 Stunden GPUs programmier, dann bin ich danach einfach platt und hab wahrscheinlich noch Kopfschmerzen. Du zerfirsst dir da halt echt das Hirn. Single-Thread programmier ich dir auch 10h und bin nicht so fertig wie nahc 5h GPU-Programmierung, ganz zu schweigen davon, wie viel x86-SingleThread Code ich dir hin knall der funktioniert und wieviel GPU-Code. Selbst MultiThread ist deutlich angenehmer. Haut man bei PThreads halt seine Mutexes rein, kontrolliert mal noch und gut ist. Bei OpenMP hat man seine Pragmas und gut ist, und bei MPI muss man sich halt gescheite Kommunikationsmuster überlegen, und wie man die Latenz versteckt, das wars dann aber auch. Das sind Standard-"Kochrezepte" die man da draufknallt und abarbeitet. Da bekommt man auch schon ganz ordentlich Programme bei raus. Klar, die Optimierungen am Ende brauchen auch wieder eine Unmenge an Zeit, aber du hast schon mal einen Performance-Vorteil, und über den kannste dir VOR dem Beginn sehr sicher sein.

Bei GPUs sagst:"Das sollte eigentlich einen Performance-Vorteil bringen" ja wenn du nicht irgendwas übersehen hast, was dir ganz schnell das Genick bricht. Auch musst du schauen, dass du das Ding überhaupt mal zum laufen bekommst. Ganz zu schweigen davon, dass du ja auch schon mal schneller sein musst als die CPU-Lösung, und genau das bringt einen in echte Nöte. Man MUSS schneller sein, und zwar merklich, sonst lohnt sich die Extra-Entwicklung/Kosten ja nicht.

Du kannst bei GPU-Programmierung halt aber schon gleich am Anfang ziemlich viel falsch machen, und deine Performance damit über den Jordan schicken. Bei CPUs ist das auch so, z.B. Spaltenweiser Zugriff auf Matrizen, aber die Sachen sind viel viel viel leichter zu überblicken als bei GPUs, einfach weil dort sehr sehr viel parallel abläuft, und man nicht beliebig synchronisieren kann, und die Overheads halt auch sehr groß sind (zumindest bis jetzt). GPUs sind einfach viel anfälliger für Fehler. Auch unten rum ist die Performance viel Anfälliger auf "schlechten" Code als bei CPUs. Man muss ja schon x-fach besser sein als CPUs. Ich hab z.B. auch schon oft genug nochmal komplett neu anfangen können mit nem Problem, weil ich was nicht bedacht habe, und die Änderung mir dann andere Sachen zerschossen hat, und so gings dann halt grad weiter, bis ich den Kernel und das Gesamte Grundgerüste erst mal in die Tonne treten und neu anfangen konnte.

Naja, und es gibt halt wie gesagt nicht viele Leute, die es halt auch wirklich können. Wenn ich mir das so bei uns anschaue. Da hate im Semester vielleicht 200 Leute, die die Vorlesungen zum Programmieren sich reinziehen, und vielleicht 30 die sich GPGPU reinziehen. Von den 30 sind dann aber sagen wir mal 10 noch Leute die in Instituten arbeiten und sich das mal anschauen wollen für die Grundlagen. So und von den 30 sind dann halt auch 10-20 dabei, wo man wohl sagen muss, dass die nicht wirklich effizienten Code in absehbarer Zeit produzieren werden, einfach weil zu viel fehlt, auch wie die Hardware wirklich funktioniert und zusammen spielt. GPU-Programmierung ohne Hardwareverständnis ist halt nicht so knalle. Man hat aber halt oft entweder die Software Menschen (die überwiegende Zahl der Leute) oder die HArdware Menschen, da brauchste aber beides.

Bei AMD macht man das bekanntermaßen
Und das, obwohl beide über den gleichen Befehlssatz, Decoder und Scheduler angesteuert werden und die gleichen Caches nutzen und wir fast alles, was der int-Core macht, auch mit den SIMDs machen könnten. Und davon sind wir mit heutigen GPUs aber meilenweit entfernt, denn die haben vollkommen andere Laufzeiten, andere Befehlsstrukturen, etc. - glaube nicht, dass man da einen Scheduler bauen kann, der beides effizient ansteuern kann (vom Decoding, dass bei GPUs primär der Treiber erledigt, ganz zu schweigen. Das könnte allenfalls in ein Itanium-System passen).

Hör mir auf mit AMD diesbezüglich
Bzgl dem Rest, dann schau dir mal die Zeitplanung vom FDS12 an. 2015 sollte obiges am Markt verfügbar sein.

Hmm - nicht neues. Ich will wissen, ob sich beim Verbindungsprotokoll großartig was tut. Was sie beschreiben sagt ja nur: "HMC kann eng und locker angebunden werden". Das kann DDR bekanntermaßen auch - siehe Grafikkarten und Mainboards. Nichts neues.

Naja, wie das genau geht wirst du auch nicht erfahren, aber die Kernzahlen, also >> höhere Bandbreite pro Verbindung, und hier kannst du das als wire betrachten reicht eigentlich auch aus. Kurz gesagt, du bekommst halt über die gleiche ANzahl an Verbindungen viel viel mehr Bandbreite. k?

Intel hat es nur mit Interposer präsentiert. Daraus resultieren natürlich einige Vorteile, weil du sehr breite Verbindungen recht effektiv umsetzen kannst. Aber das löst nicht alle Probleme und es ist eben unflexibel: Die RAM-Größe wird fest an die CPU gekoppelt. Da gibt es aber derzeit enorme Unterschiede in den verkauften Systemen, wieviel Speicher der einzelne Nutzer denn haben will/braucht. Diese Flexibilität ist für attratkive Angebote zwingend nötig, du kannst nicht von jeder CPU ein halbes Dutzend verschiedene Varianten mit unterschiedlichem Speicherausbau fertigen.

Geh von den breiten Verbindungen etwas weg. Die Grundidee ist es, keine breiten Verbindungen zu benötigen, was dich natürlich nicht daran hindert, dann doch wieder breit zu werden. Das ist dann der Interposer-Ansatz, das nicht breit werden ist der Far Memory-Ansatz, man kann aber beides machen und miteinander kombinieren. Die "Flexibilität" bekommst du auch beim "Far-Memory" Schau dir die Abbildung dazu im Video nochmals genau an. Da sind Module abgebildet, auch wenn ich den Modulgedanken für kontraproduktiv halte, aber das ist ein andere Thema.

"Je Channel" ist wurscht. Was zählt, ist "je Leitung" und "bei welcher Latenz". Wenn ich ein 256 Bit XDR-Modul baue, habe ich trotz Bus auch Bandbreite ohne Ende - aber keinen Kosten/Nutzen-Vorteil. Wie HMC da etwas verbessern will, habe ich noch nicht gehört, sieht man mal von der Punkt-zu-Punkt-Verbindung und der Termination durch einen zwischengeschalteten, integrierten Controller ab.
Aber ersteres ist zweischneidig, denn es bedeutet wiederum eine drastische Einschränkung des Ausbaus, weil ich nur noch eine Speichereinheit pro Kanal verbauen kann. Kein Aufrüsten, keine extra großen Speicherbestückungen mehr - das werden weder Enduser noch Serveranbieter als Vorteil gegenüber heutigem 1-bis-3-DIMM-Plattformen empfinden. Und letzteres ist nur eine leichte Verbesserung gegenüber FB-DIMMs und es ist brandgefährlich, was Latenzen angeht. Und da gibts derzeit imho sogar mehr Optimierungsbedarf, als bei der Bandbreite.

Sorry, Channels==#Leitungen bei mir. Das eine ist ja überführbar in das andere.

 

[Threshold]

Ich glaub wir reden gerade aneinander vorbei

Ja, IB-E sollte halt noch vor den kleinen Haswells kommen, oder eben kurz danach, aber in dem Zeitrahmen.

Ja das glaube ich auch.

Ich erzähle meine Sichtweise. Korrigiere mich wenn ich falsch liege.
Haswell DT kommt im Sommer 2013 mit Sockel 1150. Also die neue Architektur von Intel mit neuen Befehlssätzen.
Ivy E für Sockel 2011 kommt irgendwann auch im Sommer 2013 oder erst im Herbst 2013. Dann nur als Shrink. Keine neue Architektur und keine neuen Befehlssätze.
Irgendwann 2014 oder sogar 2015 kommt Haswell EP heraus. Neuer Sockel, neue Architektur und neue Befehlssätze.
Für Sockel 1150 gibt es aber schon 2014 den Shrink von Rockwell und für 2015 ist Skylake angekündigt. Also wieder eine neue Architektur.

Daher habe ich jetzt das Gefühl dass die High End Plattform immer weiter ins Hintertreffen gerät wenn es um Shrinks und neue Architekturen geht.

 

[Skysnake]

Na, eher 1 Jahr hinten dran, das hat sich wahrscheinlich jetzt relativ gut eingependelt.

 

[Threshold]

Mir scheint es aber dass es bei dem 1 Jahr nicht bleiben wird und die Differenz immer größer wird.

 

[ruyven_macaran]

Sehe ich ähnlich. Ivy-E könnte schon Mühe haben, "1 Jahr" zu halten - dagegen war Westmere-E nur wenige Monate nach Westmere-DT(low) und unendlich vor Westmere-DT(high) und Nehalem-E hatte sogar über ein halbes Jahr Vorsprung vor Nehalem-DT(high, undendlich vor -low). Noch Sandy Bridge in die Mitte mit einem Dreivierteljahr Rückstand von -E auf -DT und sogar über einem Jahr für -EN und es ergibt sich imho kein "Einpendeln", sondern eine massive Steigerung.

Das hat weniger mit "nicht wollen" als mit "nicht können" zu tun. GPU-Programmierung ist echt ätzend, und verlangt ein starkes umdenken, und auch VIEL gespür für Probleme und Lösungen.
...

Dir fällt schon auf, dass quasi deine gesamte Liste sich auf die Probleme, die man beim Programmieren mit einem hochparalleln Co-Prozessor im Vergleich zu einer Single-/Low-Thread-Haupt-CPU hat, bezieht und kein einziger Punkt auf x86 vs. CUDA? Also nur auf Probleme, die du mit einer Larrabee basierten Erweiterung genauso haben kannst, wie mit Maxwell?
Nur weil man seine gewohnten x86 Tools weiter verwenden kann, ändert sich ja nichts an den spezifischen Eigenschaften einer anders optimierten Recheneinheit (und genau die will man ja haben). Deswegen "Bequemlichkeit". Neuen Fragestellungen müssens ich die Entwickler so oder so stellen. Die Frage ist: Sind sie auch bereit, sie in einem neuen Dialekt zu beantworten? Und machen sie einen abrupten Sprung mit? Im Endergebniss gibt es keinen großen Unterschied (Unzulässlichkeiten bei individuellen, kommenden Implementationen mal außen vor), nur beim Weg dahin hat Intel einen psychologischen Vorteil.

Naja, wie das genau geht wirst du auch nicht erfahren, aber die Kernzahlen, also >> höhere Bandbreite pro Verbindung, und hier kannst du das als wire betrachten reicht eigentlich auch aus. Kurz gesagt, du bekommst halt über die gleiche ANzahl an Verbindungen viel viel mehr Bandbreite. k?

Und genau dazu hätte ich gern mehr Informationen - oder das auch nur überhaupt von offizieller Seite gesagt. Denn bislang habe ich nur "mehr Bandbreite"-Versprechen gehört und das bevorzugt neben Hardwaresamples, auf deren Rückseite andere problemlos ein 512 Bit Interface unterbringen würden.

 

[Skysnake]

Dir fällt schon auf, dass quasi deine gesamte Liste sich auf die Probleme, die man beim Programmieren mit einem hochparalleln Co-Prozessor im Vergleich zu einer Single-/Low-Thread-Haupt-CPU hat, bezieht und kein einziger Punkt auf x86 vs. CUDA? Also nur auf Probleme, die du mit einer Larrabee basierten Erweiterung genauso haben kannst, wie mit Maxwell?
Nur weil man seine gewohnten x86 Tools weiter verwenden kann, ändert sich ja nichts an den spezifischen Eigenschaften einer anders optimierten Recheneinheit (und genau die will man ja haben). Deswegen "Bequemlichkeit". Neuen Fragestellungen müssens ich die Entwickler so oder so stellen. Die Frage ist: Sind sie auch bereit, sie in einem neuen Dialekt zu beantworten? Und machen sie einen abrupten Sprung mit? Im Endergebniss gibt es keinen großen Unterschied (Unzulässlichkeiten bei individuellen, kommenden Implementationen mal außen vor), nur beim Weg dahin hat Intel einen psychologischen Vorteil.

Das mein ich auch nicht. Es ist einfach die Art und Weise, wie man mit GPUs programmiert. Egal ob mit CUDA oder OpenCL. Wenn irgendwas im Kernel schief geht, ist dein Programm am Arsch, und du kannst nicht so locker flockig nachschauen, wo denn das Problem ist. Allein, das Printf nur scheise zu handhaben sind ist schon Kacke. Ganz abgesehen davon, dass die ständige Speicher rumkopiererei und die nicht mögliche Synchronisation zwischen den Threads unterschiedlicher Workgroups einem auch nicht gerade dabei hilft etwas zu debuggen.

Es gibt einfach zu viele Auslöser, wo CUDA und OpenCL Programme einfach relativ nichtssagend aussteigen, und man auch keine Zeilenangabe bekommt, wos denn jetzt schief geht. Da kommt dann einfach nur ERROR.. und das wars, und das AUCH NUR! Wenn du jede drecks Eingabe manuell abfängst... Deswegen programmier ich z.B. OpenCL unter Windows wegen dem VS2011 PlugIn von AMD, welches mir die Arbeit komplett abnimmt. DAS ist unglaublich nützlich!

Und genau dazu hätte ich gern mehr Informationen - oder das auch nur überhaupt von offizieller Seite gesagt. Denn bislang habe ich nur "mehr Bandbreite"-Versprechen gehört und das bevorzugt neben Hardwaresamples, auf deren Rückseite andere problemlos ein 512 Bit Interface unterbringen würden.

Ich würde sagen, mit dem 30x so schnell wie DDR3 bei nur 70% des Energieverbrauchs kommste gut hin, wenn du das auf die einzelnen wires beziehst.

 

[ruyven_macaran]

Noch fehlende Debugging-Tools werden kein langfristige Hinderniss bleiben (ganz abgesehen davon, dass die Hälfte deiner Kritik auf die Verwendung unterschiedlicher Speicherräume zurückgeht - und damit der Vergangenheit angehört).

Bei "30 fach pro Wire" bin ich mal gespannt, wann näheres veröffentlicht wird. (Mein Tipp: Haswell-EP könnte früher da sein) Eine Datenrate von beinahe 100 Gbit/s über Kupfer und idealerweise gesockelt und bezahlbar wäre jedenfalls eine Ansage. Afaik schafft das selbst (nicht-WDM-)Glasfaser nur unter Laborbedingungen und -kosten.