News CPU-Unterstützung von Spielen wird wichtiger

[Realsmasher]

Kannst du mir mal bitte sagen was du studiert hast, oder studierst

Falls das noch nicht offensichtlich ist, Informatik.
Schwerpunkte : Parallele Systeme und Hardwareentwurf.

Allerdings beschäftige ich mich eher mit einem Bereich der direkte Parallelität zulässt, z.b. FPGAs, als mit klassischen Rechnern.

Es gibt als Beispiel numerische Verfahren, die Werte nicht berechnen sondern schätzen

ich weiß worauf du hinaus willst. Das man mit Approximation auch P-Vollständige Probleme parallelisieren kann ist mir schon klar.

Die Sache ist nur das dies in der Praxis doch fast nie eingesetzt wird, da es
a) schwierig ist eine solche Lösung zu finden
b) sie ungenau ist

Das kann man vielleicht bei einer Google Suchanfrage in Kauf nehmen, jedoch nicht überall.

Du kannst ja z.b. mal versuchen für das oben von mir genannte Problem eine solche Lösung zu finden.

Ausserdem würde mich interessieren wo du diesen Wert von 10 Taktzyklen für die Kommunikation zwischen den einzelnen Cores hergeholt hast.

hier mal für den i7 : KLICK

Die Zeit zur Kommunikation mit dem l2 Cache wird mit 10 Taktzyklen angegeben.
Der l3 cache zur Kommunikation wird dementsprechend sogar noch mehr zeit benötigen.

Nach deiner Ansicht wäre jeder aktuelle Superrechner garnicht möglich, weil dort zum Teil die Kommunikation zwischen den Kernen wesentlich länger dauert.

Nö, du musst schon richtig lesen. Instruktionsnahe Parallelität ist nicht möglich, das schließt jedoch andere Dinge nicht aus.

Immer wenn es unabhängige Arbeit gibt die aggregiert werden kann, dann kann man auch mit dem Kommunikationsdefizit leben.

Ah schön, selbst jemand der keine Ahnung von dem Thema hat, hat schonmal was von Ageia gehört.

schön das du scheinbar nichtmal den Thread gelesen hast.

Für dich nochmal : kuck dir bitte die Titel an die mit Physx erschienen sind. Und dann suche jene raus die nicht nur hunderte objekte bewegen, sondern auch sauber kollidieren lassen. Viel Spaß bei der Suche.

In der Regel sieht das nämlich so aus : http://games.au-ja.com/bilder/2007/cellfactor-2.jpg


Die Kollision wird parallel berechnet, deswegen hängen alle Objekte gerne mal mehrere Frames ineinander.

Wer das gut findet, ok, ich halte es für eine Physikberechnung für inakzeptabel.


Hier haben wir übrigens wieder das oben erwähnte : ein sequenzielles Problem durch eine schlechtere Lösung parallelisiert.

 

[noskill]

@Realsmasher

Wozu sollte man dieses spez. Additionsproblem bitte auf mehrere Kerne parallelisieren?
Da kannst du genauso fordern, dass ich dir eine Addition von zwei Zahlen parallelisieren soll.
Diese Argument, dass der Datentransport zwischen den Kernen noch zu lange dauert ist zwar berechtigt, aber auch einseitig, weil auch eine einzelne CPU Daten zwischenspeichern und wieder abrufen muss.
Ausserdem braucht die Berechnung ja auch ein paar Takte (die Pipeline eben).

Die Kollision wird parallel berechnet, deswegen hängen alle Objekte gerne mal mehrere Frames ineinander.

Es ist eine hinreichende Lösung des Problems, auch wenn eventuell die Umsetzung etwas ungünstig ist.
Wenn das gleiche Problem von nur einer ALU berechnet wird, hängen die Objekte gleich mal deutlich mehr Frames ineinander (nicht wegen der Näherung, sondern wegen der Rechenzeit) und der kollisionsfreie Flug würde viel länger in der Berechnung auf nur einer ALU brauchen.

Da nur die einzelnen Stöße zueinander deterministisch sind, bedeutet das wenn insgesamt 40 Kugeln mit jeweils einer kollidieren min. 20 ALUs beschäftigt sind bzw. eine einzelne ALU min. 20 mal länger brauchen würde.
Wenn alle 40 gleichzeitig miteinander kollidieren, kann man das Problem z.B. aufteilen in jeweils Kollisionen von zwei Kugeln, also auch 20 ALUs.
Für die Impulsberechnung muss dann der Gesamtimpuls genähert werden, damit die inneren Elemente sich nicht mehrmals gegenseitig anstoßen und der Block scheinbar ineinander klebt.
Je mehr Dimensionen zu dem Problem kommen, desto mehr ALUs benötigt man dann.

Eine phyiskalisch 100% korrekte Simulation gibt es nunmal nicht in Echtzeit.
Aber je mehr ALUs, desto besser die Näherung.

Ausserdem ist es ja nun nicht gerade so, als würde die Numerik stillstehen und nicht verbessert werden und ich bezweifel, dass du keinen Numeriker an deiner Uni hast, aber gut das wird mir zu sehr Offtopic.

PS: Damit du mich nicht wieder falsch verstehst, ich weiß sehr wohl, dass es Rechnungen gibt die absolut nicht parallel verarbeitet werden können, aber das ist eben nicht die Mehrzahl.

 

[Realsmasher]

Die Addition war lediglich ein simples Beispiel.
Wird z.b. benötigt bei der Mpeg Codierung (allerdings dort zusammen mit einer Muliplikation)

Diese Argument, dass der Datentransport zwischen den Kernen noch zu lange dauert ist zwar berechtigt, aber auch einseitig, weil auch eine einzelne CPU Daten zwischenspeichern und wieder abrufen muss.

Die Pipeline ist jedoch dabei nicht ein zwingendes Hindernis. Bereits ermittelte Ergebnisse z.b. von einer anderen, skalaren Einheit innerhalb des Kerns werden durchaus vor dem writeback bereits als Operand wieder genutzt.

Das kannst du ganz leicht ausprobieren, indem du obiges Beispiel von mir einmal in out of order verträglicher weise programmierst ( erst 4 dann 2 dann 1 summe) und einmal normal aufaddiert mit nur einem Akkumulator.

Hier zeigt sich das man den vollen Vorteil erhält und das bei direkt aufeinanderfolgenden Befehlen.

So muss das funktionieren wenn man sinnvoll damit arbeiten will.



Wegen der Kollision :

klar benötigt das mehr Rechenzeit wenn man es korrekt machen will, das hab ich nie bezweifelt.

Aber wenn man es korrekt machen will hilft eben diese fehlerbehaftete Parallelphysik nichts.

In Wirklichkeit werden dabei doch nur mehr Objekte erzeugt die für sich gesehen sich physikalisch unkorrekt verhalten. Den Namen Physik halte ich da für fehl am Platz, Effekthascherei passt eher.

ich weiß sehr wohl, dass es Rechnungen gibt die absolut nicht parallel verarbeitet werden können, aber das ist eben nicht die Mehrzahl.

Hab ja nicht behauptet das dies die Mehrzahl ist, sondern lediglich das der Anteil dieser zwingend sequentiellen Programmabschnitte letztendlich die Performance bestimmen wird und das teilweise heute schon tut.


Würde man eine direkte Kommunikation zwischen den Kernen von maximal 2-3 Takzyklen haben, dann könnte man den verfügbaren Pool an parallelen Möglichkeiten wenigstens noch viel weiter ausschöpfen.

Derzeit sind viele schöne Algorithmen für parallele Berechnungen doch hinfällig und werden nur in Spezielchips eingesetzt.