Kurze frage zu einem Spielprogramier problem

[Supercomputer]

Danke für den Tipp, das hört sich sehr gut an

Da kommt mir jedoch eine Frage auf, kann ich (meine Engine) irgendwie herausbekommen, wie viele Threads die aktuell verwendete CPU gleichzeitig bearbeiten?
Oder muss ich vom User eingeben lassen: "Wie viele Threads bearbeitet ihre CPU gleichzeitig (echte und virtuelle Kerne)"

Um so eine perfekte Auslastung der Vorhandenen Ressourcen zu bekommen.

 

[Bunny_Joe]

Habe mal das hier gefunden:
c++ - Programatically detect number of physical processors/cores or if hyper-threading is active on Windows, Mac and Linux - Stack Overflow


Das gibt dir die Anzahl der Threads aus(nicht der echten Kerne).

#include <iostream>
#include <boost/thread.hpp>

int main()
{
    std::cout << boost::thread::hardware_concurrency();
    return 0;
}

In C++11
http://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency

 

[Supercomputer]

Danke, da die Betriebssystem die Threads eh auf echte so wie virtuelle Kerne verteilt, ist eigentlich nur die Zahl der Threads wichtig.


Danke für den Code, der wird mir helfen.
Es ist halt so, legt man zu viele Threads an kann das Programm ruckeln, da die alle nach einander ausgeführt werden. Legt man zu wenige an, kann die CPU nicht komplett genutzt werden.

 

[bingo88]

Danke, da die Betriebssystem die Threads eh auf echte so wie virtuelle Kerne verteilt, ist eigentlich nur die Zahl der Threads wichtig.

Jaein, das hängt von der Art der Anwendung ab. SMT, wie Intels HT, sind keine echten Kerne. Bei ungünstiger Verteilung kann das durchaus Performancenachteile mit sich bringen. Aber das ist wieder diese "Vorzeitige Optimierungsgeschichte". Solange du nicht weißt, dass das ein Problem ist, musst du dir da auch keine Sorgen drum machen.

 

[Keksdose12]

Wie baut man denn software die mit einer variablen anzahl an threads ungehen kann ? Muss man dann bei der entwicklung dann das zusammenlegen von threads programmieren ? Oh gott ist das alles kompliziert mich freut, dass java in der hinsicht nicht allzu kompliziert ist.

 

[Bunny_Joe]

Wie baut man denn software die mit einer variablen anzahl an threads ungehen kann ? Muss man dann bei der entwicklung dann das zusammenlegen von threads programmieren ? Oh gott ist das alles kompliziert mich freut, dass java in der hinsicht nicht allzu kompliziert ist.

Bei Java ist Multithreading sogar ein elementarer Bestandteil.

 

[Supercomputer]

Ich wüsste auch nicht, dass eine Engine mit Java programmiert wurde.


Da hast du wieder recht bingo88

Ich werde jetzt erst mal weiter planen und dann warten bis das Buch in Deutschland verfügbar ist (Wahrscheinlich 25. August)

 

[Bunny_Joe]

Ich wüsste auch nicht, dass eine Engine mit Java programmiert wurde.

Minecraft läuft mit Java.....siehst ja an der Performance. xD


Ich denke c++ ist schon mit die beste Wahl für ne Engine.

 

[Supercomputer]

Die einzigen Möglichkeiten, die vllt schneller laufen (die ich kenne), aber bei weitem nicht übersichtlich sind, währen reines C oder Assembler

 

[Bunny_Joe]

Die einzigen Möglichkeiten, die vllt schneller laufen (die ich kenne), aber bei weitem nicht übersichtlich sind, währen reines C oder Assembler

C ist etwas blöd dafür, da nicht objektorientiert und NUR Assembler zu benutzen? Da wirste nie fertig xD

In der Industrie wirds wohl oft so sein:
99℅ C++ und 1% des Codes Assembler für die sehr zeitkritischen Sachen.


Und vergiss nicht die simple 80/20 Regel: Zu 80℅ der Zeit laufen nur 20℅ des Codes.
Natürlich nur zur Orientierung wegen der Performance.

 

[Supercomputer]

Ich weiß, rein von der Geschwindigkeit sind es Assembler, C und dann C++.

Wie ich schon geschrieben habe, wird es in C oder Assembler hässlich.

Daher werde ich alles in C++ machen und dann die kritischen Teile durch Assembler austauschen, sofern es Performance Probleme gibt.

EDIT: Lisp ist aber auch recht schnell, gerade bei Schleifen..

 

[XPrototypeX]

Die einzigen Möglichkeiten, die vllt schneller laufen (die ich kenne), aber bei weitem nicht übersichtlich sind, währen reines C oder Assembler

Ist es nicht eh so das die heutigen Compiler eigentlich "schneller" Assembler Code erzeugt, da er den kompletten Code und deren Abhängigkeiten analysieren kann bzw Plattform spezifische Optimierungen durchführen kann, die der Mensch so gar nicht kennt? Der Hauptgrund warum Java nicht in der Spieleentwicklung benutzt wird ist das man auf OpenGl bzw. DirectX nicht nativ zugreifen kann. Da wird viel mit JNI gearbeitet das relativ langsam ist. Ansonsten hängt Java C++ durch HotSpot und JIT Compiler gar nicht mehr so hinterher, ist sogar in manchen Gebieten um einiges schneller.

 

[Bunny_Joe]

Daher werde ich alles in C++ machen und dann die kritischen Teile durch Assembler austauschen, sofern es Performance Probleme gibt.

Das sagst du jetzt so....dafür brauchst du dann ziemlich viel Erfahrung über die CPU Architektur....ansonsten wirds dann im schlimmsten Fall noch langsamer xD

 

[Supercomputer]

Das weiß ich nicht genau.

Ich werde Hauptsächlich auf Linux mit Qt Programmieren.


EDIT:
Ich weiß, im schlimmsten Fall muss ich den Assemblercode auch mehrfach für die einzelnen Architekturen schreiben :/

 

[Bunny_Joe]

Das weiß ich nicht genau.

Ich werde Hauptsächlich auf Linux mit Qt Programmieren.

Auch auf Linux bleibt x86 dann x86.

 

[DarkMo]

EDIT: Lisp ist aber auch recht schnell, gerade bei Schleifen..

dann biste aber ganz weit weg von c und konsorten ^^ und ob man mit lisp nen spiel bauen kann... also mit grafik und so. ich weis nur, wenn ich ned zwingend muss, halt ich mich fern davon sin mir zuviele klammern xD

 

[XPrototypeX]

Das weiß ich nicht genau.

EDIT:
Ich weiß, im schlimmsten Fall muss ich den Assemblercode auch mehrfach für die einzelnen Architekturen schreiben :/

Und du kennst die einzelnen Architekturen besser als ein Compiler? :S Ich meine da sitzen Wissenschaftler von Intel bzw. AMD dran, die zum Teil die entsprechende CPU Architektur mit entwickelt haben... Allerdings frage ich mich wieso du als mit Performance kommst zu mal du noch keine Grundstruktur hast. Sich über Performance Gedanken zu machen kommt eigentlich wenn man weiß wo konkrete leaks sind.

 

[Supercomputer]

dann biste aber ganz weit weg von c und konsorten ^^ und ob man mit lisp nen spiel bauen kann... also mit grafik und so. ich weis nur, wenn ich ned zwingend muss, halt ich mich fern davon sin mir zuviele klammern xD

Ja, das ist mit Lisp nicht so einfach, aber wegen der Vollständigkeit halber einmal genannt.
Aber ist es nicht theoretisch möglich C++ mit Lisp zu Kombinieren, also "C++L"

Natürlich ist das nicht in ein paar Jahren zu schaffen....


EDIT: Von AMD weiß ich, dass sie größten Teils auf die ARM Architektur setzen

 

[XPrototypeX]

Nö x86 bzw x64 für Desktop Anwendungen (mehr interessiert den Compiler erstmal nicht). Es gibt natürlich auch Compiler die auf entsprechende CPUs optimieren. Intel hat glaube ich einen eigenen Compiler.

 

[Supercomputer]

Nö x86 bzw x64 für Desktop Anwendungen (mehr interessiert den Compiler erstmal nicht). Es gibt natürlich auch Compiler die auf entsprechende CPUs optimieren. Intel hat glaube ich einen eigenen Compiler.

Wenn es auf die optimale Auslastung ankommt, sollte man schon auf jede einzelne in frage kommende CPU Architektur optimieren.