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

22

27.11.2012, 15:00

Aber vom Stromverbrauch her nicht gerade etwas, was ich in einen Laptop packen würde und afaik auch kein Hyperthreading... ;)

23

27.11.2012, 17:46

NachoMan hat die Ursache meines Problems gefunden. :)

Ich habe das sfml 20 nicht für VS11 compiliert.

Ich habe leider auch keine Version für Vc11 gefunden. Hat jemand eine oder so zufällig und shickt sie mir :this: :D
Bin vorerst zurück auf vc10. Also kein std::thread.


Zitat

Was du willst ist, beim Programmstart für jeden Core einen Thread zu erzeugen und diese Threads dann über Work Queues zu füttern. Dafür ist aber ein solides Verständnis von paralleler Programmierung nötig. Wenn ich dann sehe, wie du per sf::sleep() auf deine threads "wartest", ist klar, dass es dir in dem Bereich noch massiv an Grundlagen mangelt.
In dem Fall würde dir schwerstens empfehlen, die PPL oder so zu nutzen, die all diese Dinge automatisch für dich macht.


Ja ich bin gerade dabei^^ Habe praktisch vor einer Woche mit c++ angefangen. Threading kenne ich von c# etwas. :wacko:
Ich werde dann alles etwas Umdesignen. Also threads nicht neu erzeugen sondern eine Thread Quque verwenden.
Dazu werde ich ein Testprogramme schreiben müssen denke ich. Hoffentlich daran lernen.

Dazu brauch ich aber immer noch einen Array von Threads.

Oder bin ich zu blöde hier

C-/C++-Quelltext

1
std::vector<std::unique_ptr<sf::Thread>> threads;

auf die Threads mittels Index zu zu greifen?

Müsste ja z.B.:

C-/C++-Quelltext

1
threads[1].sleep 

aufrufen.
?(


Zitat

Aber vom Stromverbrauch her nicht gerade etwas, was ich in einen Laptop packen würde und afaik auch kein Hyperthreading...

LOL JA! Wenn ich es so laufen lassen rauscht der Lüfter extrem, der Akku wird innerhalb von Minuten leer :thumbsup:

LG
Bilder zu meinem Projekt: ParSim

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

24

27.11.2012, 17:56

Ja ich bin gerade dabei^^ Habe praktisch vor einer Woche mit c++ angefangen. Threading kenne ich von c# etwas.

Tu dir bitte selbst einen Gefallen und lass das erstmal ein Weilchen ruhen. C++ ist keine Sprache die man einfach mal so in einer Woche lernt. Auch nicht wenn man noch so gut C# kann. C++ und C# unterscheiden sich fundamental, auch wenn sie auf den ersten Blick vielleicht noch so ähnlich aussehen. Wenn du C++ lernen willst, dann tu das ordentlich und von Grund auf. Mit anderen Worten: Lies ein gutes Buch. Wenn es an Dingen scheitert wie eben z.B. dem hier: threads[1].sleep, dann ist klar, dass es für dich einfach noch zu früh ist, in derartige Sphären vorzustoßen. Lern erst die Grundlagen...

Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von »dot« (27.11.2012, 18:13)


eXpl0it3r

Treue Seele

Beiträge: 386

Wohnort: Schweiz

Beruf: Professional Software Engineer

  • Private Nachricht senden

25

27.11.2012, 18:34

Ich habe leider auch keine Version für Vc11 gefunden. Hat jemand eine oder so zufällig und shickt sie mir
Bin vorerst zurück auf vc10. Also kein std::thread.
Kompilier es einfach selber, ist nicht schwer und wenn du mit C++ weiter programmieren willst, dann ist das eine Fähigkeit die man einfach beherrschen muss... ;)
Als Alternative gibt es dann da noch meine Nightly Builds.

Dazu brauch ich aber immer noch einen Array von Threads.
std::vector<std::unique_ptr<sf::Thread>> threads;
auf die Threads mittels Index zu zu greifen?
Müsste ja z.B.: threads[1].sleep
Wo ist das Problem?
unique_ptr verhält sich wie ein Pointer, also müsste das threads[1]->sleep() heissen.
Blog: https://dev.my-gate.net/
—————————————————————————
SFML: https://www.sfml-dev.org/
Thor: http://www.bromeon.ch/libraries/thor/
SFGUI: https://github.com/TankOs/SFGUI/

26

27.11.2012, 19:59

Ich bin mir absolut bewusst das c++ sehr Umfagreich ist. Aber an einem tag fängt man eben an. Das war letzten Samstag oder so. ^^
Ich werde natürlich den Hinweis befolgen mich weiter in Grundlagen von c++ einzulesen. Mit Threads rumzuprobieren, kann man mir allerdings nicht ausreden. :|

Zitat

unique_ptr verhält sich wie ein Pointer, also müsste das threads[1]->sleep() heissen.

Ok danke für den Tipp ich gucke mal ob ich das hinbekomme.

LG
Bilder zu meinem Projekt: ParSim

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

27

27.11.2012, 20:03

Mit Threads rumzuprobieren, kann man mir allerdings nicht ausreden. :|

Das war zu befürchten. Schau dir in dem Fall zumindest mal gut an, was man unter einer Race Condition bzw. Data Race versteht, was ein Mutex bzw. eine Critical Section ist und wofür man std::thread::join() braucht...

Und ich wiederhole auch nochmal meine Empfehlung: Verwend einfach die Parallel Patterns Library. Dein Problem ist ein Musterbeispiel einer Anwendung der PPL, die sich um das Multithreading dann komplett automatisch kümmert, ohne dass du auch nur irgendwo das Wörtchen thread erwähnen musst. Wenn du schon dabei bist, könntest du auch gleich einen Schritt weiter gehen und C++ AMP verwenden, dann würde deine Partikelsimulation wie von selbst auf der GPU laufen...

Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von »dot« (27.11.2012, 20:17)


28

28.11.2012, 09:30

So!

Zitat

Und ich wiederhole auch nochmal meine Empfehlung: Verwend einfach die Parallel Patterns Library.


Das habe ich getan! :thumbsup: Ich habe jetzt 2 Threads, einen für den Client, und einen für die Engine. In dem Engine-Thread verwende ich parallel_for, funktioniert anscheinend prima. :D
Hoffe ich bekomme keine race conditions, aber ich greife ja mittels Index auf versch. Datensätze zu...



Ich habe jetzt vor erstmal eine FPS klasse zu schreiben, um verschiedene Methoden bzgl. zur parallelen Partikelsimulation vergleichen zu können.



Zitat

Wenn du schon dabei bist, könntest du auch gleich einen Schritt weiter gehen und C++ AMP verwenden, dann würde deine Partikelsimulation wie von selbst auf der GPU laufen...

warum sollte sich das lohnen aud die GPU zu gehen?
Ich werde in der Engine 3 Passus haben.
1. viele float additionen und substraktionen.
2. float vergleiche, sqrt und linerare operationen.
3. float vergleiche, und lineare operationen.



Gleichzeitig zeichnet der Client Thread sf::shapes und so und arbeitet den Input ab usw...
Oder sollte ich die gesamte Architektur so nicht machen?

LG
Bilder zu meinem Projekt: ParSim

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

29

28.11.2012, 09:47

Seh ich das richtig, dass sowohl dein "Client Thread" als auch dein "Engine Thread" rendern? Was genau ist da der Sinn dahinter? Wieso überhaupt diese zwei Threads? Musst du nicht sowieso immer erst updaten und dann rendern? Wie genau synchronisierst du diese zwei Threads im Moment?

Was genau verstehst du unter "linearen Operationen"?

30

28.11.2012, 09:54

Zitat

Seh ich das richtig, dass sowohl dein "Client Thread" als auch dein "Engine Thread" rendern?

Gerendert wird ausschließlich von Client-thread, mit einer festen Framerate von X.
Der Client thread ließt dazu aus der Partikelliste. Wenn er sich "verließt" ist es egal.

Der Engine thread läuft so schnell er kann. ^^ Er berechnet die Partikelinteraktion usw. Er ließt und verändert die Partkelliste.


Zitat

Was genau verstehst du unter "linearen Operationen"?

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

LG
Bilder zu meinem Projekt: ParSim

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Horus« (28.11.2012, 10:00)


Werbeanzeige