News Intel kündigt Details zum Zehn-Kern-Prozessor an

[bmbl]

Wie sieht es derzeit eigentlich bei Real Time Ray Tracing? Es gibt ja OpenRT die mit der einen Uni da Quake 3 als RT umgesetzt hatten (und 4 wenn ich mich recht entsinne auch).

Damit wären doch solche CPUs doch auch für die jammernden Zocker gebräuchlich

 

[Pickebuh]

@Wattebaellchen,

Keine Angst der kommt bestimmt noch Sockel 1365

Zum Thema.
Ich denke das ist einfach die Antwort auf die kommenden 8 und 12 Kerner von AMD die für den Servermarkt erscheinen sollen.
Mit dem werbeträchtigen 20 Threads wird halt die Käuferschicht angeheizt, weiter nichts.

Würde ja im privaten Bereich überhaupt keinen Sinn machen außer bei ein paar Benchmarkrekordjägern die sich gleich zwei dieser CPUs + 4xGTX485 unter Stickstoffkühlung auf ein Board klatschen und sonst nicht wissen was sie mit ihrem vielen Geld noch so alles machen könnten.

 

[grensen]

Das Problem ist bei Spielen nicht, dass die unterschiedlichen Schritte nicht parallel ablaufen könnten, sondern dass sich die einzelnen Schritte (vor allem die Spiellogik selbst) nicht einfach parallelisieren lassen.
Die Ursache dafür ist, dass man beim berechnen der Spiellogik sowohl nahezu willkürlich schreibende als auch willkürlich lesende Zugriffe auf die Datenstrukturen des Spiels hat, was bei Parallelisierung im Allgemeinen schnell zu vielen Problemen führen kann, wenn man als Programmierer nicht geschickt arbeitet.
ZB: Figur schiesst und ruft Methode Schuss mit der Figur auf. Diese wird vom Scheduler unterbrochen und es kommt der nächste Thread dran der die Methode Figur stirbt ausführt und die Figur löscht. Wird nun der erste Thread fortgesetzt stürtzt das Programm ab, weil die Figur nicht mehr existiert.

wernn man danach geht müsste also eine spiele-cpu ganz anders aufgebaut sein? wieso wird eigentlich kein 5 kerner gebaut, 4 kleine kerne für alles mögliche und ein hauptkern der sich allein um intensive anwendungen kümmert? wenn sogar grafikchips in einer cpu platz finden sollte das doch zu machen sein.

 

[ata2core]

Wer hier der Meinung ist, dass die Entwicklung falsch ist und sich Intel/AMD mit anderen Techniken zur Leistungsverbesserung kümmern sollten, der sollte sich mal an die Zeit erinnern, als die 32 Bit Technik von den Prozessorherstellern bereitgestellt wurde. Da war es ähnlich, der erste 32 Bit Prozessoren i386DX wurde am 17. Oktober 1985 eingeführt. Das erste 32 Bit Windows, nämlich Windows 95, gab es ab 15. August 1995. Damals hat es also extrem lange gedauert die verfügbare Hardware auszunutzen.
Wenn ich heute sehe, das praktisch alle neuen Spiele multithreading unterstützen hat sich der Zeitraum bis die Hardwareentwicklung in die Softwareentwicklung Einzug gehalten hat sehr verkürzt. Sieht man sich die Applikationen im Bereich Videoschnitt und -encoding an, standen kurz nach Einführung der Multicore-CPUs die Software bereit. Wer heute mit Adobe Premiere Full-HD Videoschnitt betreiben will braucht heute schon diese CPU. Ich jedenfalls freue mich auf den Zeitpunkt, wo diese Prozessoren im Mainstream angekommen sind.

Aber ich habe den Eindruck, hier dreht sich alles nur um Spiele. Fakt ist es nun mal, das die Computertechnik nicht zum Spielen da ist, sondern für andere sinnvolle Anwendungen. Wenn darüber hinaus auch noch auf diesen Geräten gespielt werden kann, so ist dieses schön, die Computertechnik wird aber nicht die Anforderung der Spielewelt zum Maßstab für neue Entwicklungen machen.

 

[floq0r]

Das Problem ist bei Spielen nicht, dass die unterschiedlichen Schritte nicht parallel ablaufen könnten, sondern dass sich die einzelnen Schritte (vor allem die Spiellogik selbst) nicht einfach parallelisieren lassen.
Die Ursache dafür ist, dass man beim berechnen der Spiellogik sowohl nahezu willkürlich schreibende als auch willkürlich lesende Zugriffe auf die Datenstrukturen des Spiels hat, was bei Parallelisierung im Allgemeinen schnell zu vielen Problemen führen kann, wenn man als Programmierer nicht geschickt arbeitet.
ZB: Figur schiesst und ruft Methode Schuss mit der Figur auf. Diese wird vom Scheduler unterbrochen und es kommt der nächste Thread dran der die Methode Figur stirbt ausführt und die Figur löscht. Wird nun der erste Thread fortgesetzt stürtzt das Programm ab, weil die Figur nicht mehr existiert.

ganz so einfach is das auch wieder nicht
eine berechnung besteht ja nicht aus einzelnen schritten ala "figur stirbt" sondern aus vielen einzelnen befehlen, die ja auch pro einzelnem kern zum teil parallelisiert werden. die problematik bei der nutzung mehrerer kerne liegt dabei, dass die koordination der einzelnen befehlsverarbeitungen (threads in diesem fall) seitens des programmes durchgeführt werden muss, was einen enormen zusätzlichen aufwand in der programmstruktur bedeutet. es gibt ja multi-thread-fähige engines nur glaube ich, dass sich einfach niemand damit befassen will solang es nicht unbedingt notwendig ist.
ideal wäre es, wenn die prozessorhersteller es fertig bringen würden, einzelne berechnungen CPU-INTERN auf mehrere cores aufzuteilen während diese für das OS zu einem einzelnen logischen kern konsolidiert werden.

 

[gruffi]

Ich wünschte mir, Intel und AMD würden mal wieder mehr in der Realität entwickeln...Statt immer nur den einfachen Weg zu gehen und mehr Kerne aufs DIE zu klatschen, sollten die versuchen Leistung pro Takt zu erhöhen.

Was Intel in den kommenden Jahren an echten Neuerungen vorhat, ist bisher noch recht vage. AMD geht aber mit Sicherheit nicht den einfachen Weg, Stichwort Bulldozer und Fusion. Performance pro Takt ist mittlerweile ziemlich ausgereizt. Da wirst du in Zukunft keine signifikanten Sprünge mehr sehen, bezogen auf x86. Es ist zudem genauso wenig ein Allheilmittel wie Kerne. Was entscheidender als Performance pro Takt ist, ist die Performance pro logischem Prozessor bzw pro Thread. Und das lässt sich auch mit mehr Takt realisieren. Hier gibt es sicherlich noch Potenzial für Verbesserungen. Das liegt aber weniger an der Prozessorlogik, sondern vielmehr am Fertigungsprozess. Und darauf haben Intel und AMD nur begrenzten Einfluss. Im Endeffekt steht aber nur eines über allem anderen, und das ist die Effizienz.

Quatsch! Bisher hat jeder Prozzi, der angeblich für den Pro-Bereich konzipiert war, einen Weg ins normale Heimsystem gefunden.

Tatsächlich? Dann zeig mir mal ein Heimsystem mit Beckton. Denn das hier ist der Nachfolger davon.

Keine Angst der kommt bestimmt noch Sockel 1365

Das müsste dann aber eher LGA 1566 sein.

 

[GuaRdiaN]

ideal wäre es, wenn die prozessorhersteller es fertig bringen würden, einzelne berechnungen CPU-INTERN auf mehrere cores aufzuteilen während diese für das OS zu einem einzelnen logischen kern konsolidiert werden.

Das ist in der Tat wahr.
Gerade Nebenläufigkeitsprobleme treten bei der Parallelisierung auf, und wie ein Vorredner bereits beschrieben hat, sind gerade destruktive Schreibvorgänge ein großes Problem. Paralleles Lesen ist nie das Problem, das heißt, wenn teile des Szenarioaufbaus parallelisiert werden, oder aktionen die keinerlei Abhängigkeit parallelisiert werden ist das kein Problem, sobald aber irgendwelche, durch den Spieler getriggerten Funktionen, zeitgleich ausgelöst werden sollen, und diese unter Umständen auf andere Aktionen (und deren Resultate) gewarten werden muss, kann dies wieder zu einem slowdown kommen. Somit sieht man sich schlicht und ergreifend, einem erhöhten Programmieraufwand konfrontiert, und ich denke, dass das Arbeit sein wird, die einige Entwickler heute noch scheuen werden.

Sonst ist und bleibt diese Entwicklung sicher ein guter Schritt, denn gerade wenn wir uns Datenbanken ansehen, wo gigante SELECTs auf schnelle RAID Verbünde angewendet werden müssen, ist CPU Power durch nichts zu ersetzten als noch mehr CPU Power. Wichtig ist dabei nur, dass Stromsparmechanismen effektiv und schnell arbeiten, denn sonst kommen wir wieder in diese Strom-fress-Richtung, wie einst mit der NetBurst Technologie von Intel mit diesen horrenden Taktraten.

Beste Grüße.

 

[floq0r]

Wichtig ist dabei nur, dass Stromsparmechanismen effektiv und schnell arbeiten, denn sonst kommen wir wieder in diese Strom-fress-Richtung, wie einst mit der NetBurst Technologie von Intel mit diesen horrenden Taktraten.

richtig, und essentieller bestandteil davon ist, dass gängige abfolgen von instruktionen weitgehend in befehlssätzen integriert werden um unnötige herumrechnerei zu sparen => steigerung der effizienz statt ausschließliche steigerung der nominalleistung

 

[Wattebaellchen]

Zum Thema.
Ich denke das ist einfach die Antwort auf die kommenden 8 und 12 Kerner von AMD die für den Servermarkt erscheinen sollen.

http://geizhals.at/deutschland/?cat=cpuamdo64&xf=25_12

AMD war doch so schnell das man keine Motherboards dafür bekommt, aber die CPUs schon seit 2 Monaten in den Lagern der Händler liegen

http://geizhals.at/deutschland/?cat=mb940&xf=644_dual+Sockel-G34

da ist ein lieferbares

Intel muss hier aufholen, sicher werden die cores in 32nm etwas fixer takten können und weniger strom verbrauchen... aber das dauert noch

 

[FlauschigesPony]

@grensen
Gibt es doch schon in Form des Turbo Modes bei Intel und bei AMD für schlecht parallelisierbare Sachen. Evtl wird dieser Gedankengang in Zukunft ja auch noch weiter fortgesetzt werden und der Turbomode wird zu einem verbesserten Kern.



@floq0r
Ja dies war nur ein relativ "einfacher" Erklärungsversuch für die Probleme welche beim Recht umfangreichen Thema Prozessynchronisation auftreten können.
Das Programm selbstständig zur Laufzeit in einzelne Threads auf Prozessorseite aufzuteilen scheint mir nicht zu clever, da der Prozessor den gesamten Programmablauf kennen müsste um Deadlocks und ähnliche Probleme auszuschliessen.
Und sollte man die Parallelisierbarkeit nur in Form von Sprungvorhersagen und Pipelines vornehmen wird man auf die Probleme stossen, dass die Vorhersagen je länger sie in die Zukunft reichen zunehmend öfters falsch werden und dass die Prozessorkerne eine Latenz bei der Kommunikation haben, die dazu führt, dass eine Parallelisierbarkeit auf Befehlsebene sehr ineffizient ist.
Hier wäre es in meinen Augen eher sinnvoller an den Programmiersprachen zu arbeiten, damit Parallelisierbarkeit leichter zu handhaben wird beim Programmieren.

 

[MCITP]

#5
Alles gesagt ;-)

 

[dirky8]

@wattebällchen
umgekehrt wird ein Schuh draus
AMD muss im servermarkt aufholen nicht INtel.

 

[FlauschigesPony]

sorry doppelpost, statts edit :x

 

[floq0r]

@floq0r
Ja dies war nur ein relativ "einfacher" Erklärungsversuch für die Probleme welche beim Recht umfangreichen Thema Prozessynchronisation auftreten können.
Das Programm selbstständig zur Laufzeit in einzelne Threads auf Prozessorseite aufzuteilen scheint mir nicht zu clever, da der Prozessor den gesamten Programmablauf kennen müsste um Deadlocks und ähnliche Probleme auszuschliessen.
Und sollte man die Parallelisierbarkeit nur in Form von Sprungvorhersagen und Pipelines vornehmen wird man auf die Probleme stossen, dass die Vorhersagen je länger sie in die Zukunft reichen zunehmend öfters falsch werden und dass die Prozessorkerne eine Latenz bei der Kommunikation haben, die dazu führt, dass eine Parallelisierbarkeit auf Befehlsebene sehr ineffizient ist.
Hier wäre es in meinen Augen eher sinnvoller an den Programmiersprachen zu arbeiten, damit Parallelisierbarkeit leichter zu handhaben wird beim Programmieren.

das is allerdings richtig... und parallelisierung auf der basis von pipelines gibt es ja schon seit ewigkeiten. ich denke über diese fragen hat man sich wahrscheinlich eh schon vor 15 jahren den kopf zerbrochen wenn es bereits in der spracharchitektur oder zumindest in diversen frameworks eine entsprechende implementierung gäbe wäre das ein schritt in die richtige richtung.

 

[Wattebaellchen]

@wattebällchen
umgekehrt wird ein Schuh draus
AMD muss im servermarkt aufholen nicht INtel.

Nope, rein nach der Kernzahl und der Eignung für Virtuelle Server liegt AMD vorne und bei vielen Hostern machen sich wieder opteronsysteme breit, vorallem seit dem so viele Opterons in der Supercomputerliste ganz oben standen bzw, noch stehen.

P/L ist auch besser.

 

[gruffi]

AMD muss im servermarkt aufholen nicht INtel.

Falsch. Magny Cours in 45 nm ist ähnlich schnell (eigentlich sogar etwas schneller, speziell HPC) und dazu noch sparsamer als Westmere-EP in 32 nm. Hier hat AMD momentan die Nase vorn. Und das wird mit Bulldozer sicherlich nicht schlechter. Zwar bietet Intel mit Beckton eine 8P+ Plattform. Allerdings ist das ein Nischenmarkt und Beckton dazu noch wenig effizient.

 

[Kartenlehrling]

Ich kann mich noch an ein Video erinnern wo der Intel Fritze gesagt hat das es kein Sinn mach auf immer weiter Kern zu verteilen,
wenigsten für Ottonormalrechner.

 

[Lost_Byte]

@Kartenlehrling: in dem Video wurde aber glaub ich von 32 Kernen gesprochen bis wo hin es Sinn macht. Da sind wir noch weit von entfernt

 

[Mardy2802]

Schön und gut das Ganze. Nur wann kommen endlich mal bezahlbare 6-Kerner von Intel... so um die 300€, aber keine 1000€

 

[aemaeth]

die CPU-Hersteller könnten auch Hundert-Kern-Prozessoren raus bringen, so lange es keine Software gibt die damit was anfangen kann..
Aber hört sich schon gut an für das Marketing ala. wir haben den ersten zehn-Kerner!