Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

31

28.11.2012, 10:00

Zitat

Was genau verstehst du unter "linearen Operationen"?

sowas wie + - * /
nicht sqrt oder ^2.

Nun, in dem Fall ist die GPU natürlich der ideale Ort für deine Simulation, zumindest wenn du genug Partikel hast, dass der Kopieraufwand sich amortisiert.
Aber egal, offenbar läuft im Moment ja alles... ;)

32

28.11.2012, 10:10

Zitat

Aber egal, offenbar läuft im Moment ja alles...

Jahaha, aber jetzt werde ich es erstmal testen.

Momentan staune ich eher dass die GPU da schneller sein soll. Da staune ich enorm. Das macht für mich keinen Sinn. Ich werde nachlesen müssen :D
Ich hoffe über 50K Partikel (30K hatte ich in C#).
Kannst du einschätzen wieviel C++ AMP schneller ist? Eher 2-3% oder 100% schneller?
Hängt das nicht auch stark von der Hardware ab?
Ob es schwierig wird nachträglich auf C++ AMP zu gehen?
?(

LG
Bilder zu meinem Projekt: ParSim

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

33

28.11.2012, 10:14

Momentan staune ich eher dass die GPU da schneller sein soll. Da staune ich enorm. Das macht für mich keinen Sinn.

Wieso genau wundert dich das? Die eine große Stärke von GPUs ist Numbercrunching. Aber die GPU macht erst ab einer gewissen Problemgröße Sinn, da der Aufwand die Daten von der CPU zur GPU zu bringen und wieder zurück sich sonst nicht rentiert.

Kannst du einschätzen wieviel C++ AMP schneller ist? Eher 2-3% oder 100% schneller?

Ohne zu wissen wie deine Simulation im Detail funktioniert nur schwer

Hängt das nicht auch stark von der Hardware ab?

klar

Ob es schwierig wird nachträglich auf C++ AMP zu gehen?

Das ist vermutlich nicht so ein großes Problem.

34

28.11.2012, 10:15

c++ gefällt mir richtig gut! :thumbup:
Bilder zu meinem Projekt: ParSim

35

28.11.2012, 10:54

Diese schleifen machen doch das gleiche..?

C-/C++-Quelltext

1
2
3
4
5
parallel_for(0, particleMaximum, [&](int i)
{
    particleProvider.particle[i].x=particleProvider.particle[i].x+0.00001;
    particleProvider.particle[i].y=particleProvider.particle[i].y+0.00001f;
});



C-/C++-Quelltext

1
2
3
4
5
for (int i = 0; i < particleMaximum; i++)
{
    particleProvider.particle[i].x=particleProvider.particle[i].x+0.00001;
    particleProvider.particle[i].y=particleProvider.particle[i].y+0.00001f;
}


Wie kann es da sein, dass die parallel_for nur mit 2.200 FPS, die for mit 120.000 FPS läuft.
Kann es sein das eine parallel_for nur bei in Relation zu ihrer Anzahl großen aufgaben sinnvoll ist?

EDIT: Wenn die Schleifen leer sind laufen sie mir 500k bzw 5k Fps :D Oh nein!
Egal wie ich es drehe, parallel_for ist kaum schneller als for :/
Bilder zu meinem Projekt: ParSim

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Horus« (28.11.2012, 12:56)


Sacaldur

Community-Fossil

Beiträge: 2 301

Wohnort: Berlin

Beruf: FIAE

  • Private Nachricht senden

36

28.11.2012, 10:57

der Unterschied zwischen der CPU und der GPU ist, dass die CPU ein paar wenige Kerne hat, die die verschiedensten Dinge gleichzeitig erledigen können, während die GPU enorm viele Kerne hat, die "nur das Gleiche" machen können (also die gleichen Berechnungen mit verschiedenen Parametern)
um wie vieles es schneller ist, hängt also von der Menge der Partiel, der Implementierung und der Hardware ab

und so ganz nebnbei:
es ist ganz interessant, das hier zu lesen, da mir vor einer Weile erst eine Idee für Multithreading in meinem eigenen Spiel gekommen ist, wo sich wohl der hier genannte Threadpool eignen würde =)
Spieleentwickler in Berlin? (Thema in diesem Forum)
---
Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].

37

28.11.2012, 19:09

Zitat von »Sacaldur«

es ist ganz interessant, das hier zu lesen, da mir vor einer Weile erst eine Idee für Multithreading in meinem eigenen Spiel gekommen ist, wo sich wohl der hier genannte Threadpool eignen würde =)
Einen Threadpool wie hier genannt habe ich getestet sowie auch parallel_for und normale for Schleife.

Am schnellsten war die parallel_for!
Es kommt auf die richtigen Einstellungen an.

Die parallel_for mach logicher weise soviele parallele Berechnungen wie phys. Cores da sind.
Das habe ich mit Konsolenprogrammen auf meinen beiden Rechnern mit verschieden vielen Cores empirisch überprüft. :crazy:

Am schnellsten ist es, wenn man die Daten in so viele Teile teilt wie phys core da sind und dann die parallel_for damit statet. Das sieht dann wie folgt aus:

C-/C++-Quelltext

1
2
3
4
parallel_for(0, physCores, [&](int i)
{
    task.part(i);
});


So zumindest mein Fazit ^^

LG
Bilder zu meinem Projekt: ParSim

Sacaldur

Community-Fossil

Beiträge: 2 301

Wohnort: Berlin

Beruf: FIAE

  • Private Nachricht senden

38

28.11.2012, 20:04

deinem Fazit glaube ich gerne, allerdings werde ich in meinem Fall keinen Threadpool verwenden können

die verschiedenen Threads würden in meinem derzeitigen Anwendungsfall alle einen Input erhalten und einen Output liefern
der Output ist allerdings nicht eine Zahl, eine Zeichenkette oder eine Liste mit "gleichwertigen" Einträgen (die einfach hintereinander gehangen werden können), sondern 4 Zahlen und 4 Listen (ggf. leer), von denen dann nur "die richtigen" übernommen werden würden
das ist allerdings nicht das Hauptproblem, da es bei der parallel_for bestimmt auch möglich ist, die Rückgaben der Threads zumindest kurzzeitig zusammen zu fassen und dann diese Liste auszuwerten
das eigentlich Problem ist, dass ich kein C++ (sondern C#) verwende und mir so die parallel_for gar nicht zur Verfügung steht ;)

so viele Kerne zu verwenden, wie vorhanden sind, ist ja auch das einzig sinnvolle ;)
allerdings bin ich mir noch nicht ganz sicher, in wie weit ich für meinen Fall auf alle Kerne zurückgreifen sollte, da nebenbei auch andere Threads aktiv sein könnten
mal ganz abgesehen davon, dass die durchzuführenden Berechnungen _eigentlich_ nicht zu Rechenaufwändig sein sollten...

aber mit etwas Glück bringt die Umstellung auf C# schon genug Performance, sodass das Multithreading dann nur das I-Tüpfelchen darstellt
Spieleentwickler in Berlin? (Thema in diesem Forum)
---
Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

39

28.11.2012, 20:08

[...] das eigentlich Problem ist, dass ich kein C++ (sondern C#) verwende und mir so die parallel_for gar nicht zur Verfügung steht ;)

Ist das so? ;)

Abgesehen davon verwendet parallel_for unter der Haube natürlich einen Thread Pool, nämlich den der Concurrency Runtime (ConcRT).

40

28.11.2012, 20:15

Zitat

so viele Kerne zu verwenden, wie vorhanden sind, ist ja auch das einzig sinnvolle


habe bei c#

C#-Quelltext

1
ThreadPool.UnsafeQueueUserWorkItem(new WaitCallback(Klasse.Function), (object)argument);

verwendet und damit gute Erfahrungen. :thumbup:

Komischer weise hatte ich mir mehr als 100 "winzigen" Threads beim c# ThreadPool die besten Ergebnisse. Auf Seite 8 ist ein Diagramm und eine Diskussion.
Quadtree und Fragen dazu
Das liegt mir bis heute bisschen quer im Kopf^^

LG
Bilder zu meinem Projekt: ParSim

Werbeanzeige