Zitat:

Wenn du lediglich das Hängen der Anwendung vermeiden willst, reicht es ja schon, wenn du die Berechnung insgesamt in einen eigenen Thread verlagerst.

Hab ich ja schon..
Einen der nur für die berechnungen zuständig ist.

Ich verstehe nicht warum ein System nicht in der lage ist zu erkennen wenn ein core ausgelastet ist
um dann diesen auf die übrigen zu verteilen.
Was für einen Sinn hat sonst ein 4 Kern prozessor wenn er nicht dynamisch vom system verwaltet wird
um eventuelle auslastungen eines Kerns zu verhindern.

gruss

Thread sind doch gerade das Werkzeug, um einen MultiCore Prozessor auszunutzen!

Ein Thread ist quasi ein Ablauf, wo der Programmierer gesagt hat: "So, das Zeug muss schön sequenziell ablaufen."
Wenn du jetzt mehrere Threads erzeugst, sagst du ja genau "Diese Code-Abschnitte müssen jeder für sich sequenziell ablaufen, aber die Abschnitte sind voneinander unabhängig"

Daraus folgt auch, dass es nicht sinnvoll ist, einen Thread auf mehrere Kerne zu verteilen: da die Anweisungen streng sequenziell ablaufen müssen, hat ein zweiter Kern einfach nichts zu tun. Sie könnten sich natürlich einfach ständig abwechseln. Dann hättest du 50% Auslastung auf jedem Kern. (Passiert in der Praxis auch oft)

Zitat:

Ich verstehe nicht warum ein System nicht in der lage ist zu erkennen wenn ein core ausgelastet ist
um dann diesen auf die übrigen zu verteilen.

Das Betriebssystem kann da eigentlich nicht mehr parallelisieren was der Programmierer verschlafen hat. Was es selbstverständlich macht: Zwei Threads, die beide Rechnen wollen, auf zwei verschiedene Kerne aufteilen.

Vielleicht kannst Du Dir mal OmniThread anschauen.

Zitat:

Zwei Threads, die beide Rechnen wollen, auf zwei verschiedene Kerne aufteilen.

Das tue ich ja..
Mein problem ist aber das der RenderThread für die Visualisierung bei ca. 13% gesamter CPU auslastung
einen Kern zu 100% auslastet.

Kann doch nicht einen Thread in 5 Threads aufsplitten um das zu umgehen.
Zumindest habe ich dazu wenn es möglich wäre nicht die erfahrung.

Hmm.. sehe da im moment keine lösung um mein problem zu beheben.

Zitat:

Bitte versteh das jetzt nicht falsch, aber mir scheint Dir fehlen ein bisschen die Grundlagen beim Multithreading.

Keines falls bin ja froh über Ratschläge.
Und ja die fehlen mir etwas.

Zitat:

Seine Aufgaben SO auf mehrere Threads aufzuteilen, dass diese Sperren (Locks) so selten wie möglich genutzt werden müssen und

Ne dumme frage hinterher!
Kann es sein das mein Problem darin besteht das beide Threads über den gleichen Messagehandler verwaltet werden
oder hat das keinen einfluss darauf.

gruss

Zitat von EWeiss:

Mein problem ist aber das der RenderThread für die Visualisierung bei ca. 13% gesamter CPU auslastung einen Kern zu 100% auslastet.

Zitat:

Your CPU meter shows a problem. One core is running at 100 percent, but all the other cores are idle. Your application is CPU-bound, but you are using only a fraction of the computing power of your multicore system. Is there a way to get better performance?

Merkst du was ?

Das zweite Zitat ist von hier
http://msdn.microsoft.com/en-us/library/gg675934.aspx
gibt auch eine C# Version, die finde ich gerade nicht.

Ignorier notfalls den C++ Code, aber lies mal, was da über Techniken zur Parallelisierung steht und versuch halt, das z.B. mit OmniThreads nachzubauen.

Zitat:

Your CPU meter shows a problem. One core is running at 100 percent, but all the other cores are idle. Your application is CPU-bound, but you are using only a fraction of the computing power of your multicore system. Is there a way to get better performance?

Ja und genau das war mein ziel diesen Beitrag zu schreiben da ich nach einer lösung
für eine bessere Leistung zu erzielen Suche

Parallele Programmierung..
Eine Funktion in mehrere Teile zerlegen wo diese doch zusammen gehört ?
So pauschal kann man das nicht sagen.
Und ich habe sie ja schon in 2 Teile Threads aufgeteilt.

Zitat:

das z.B. mit OmniThreads nachzubauen.

Werd mal schuan ob ich da einen lösungsansatz finden, verwirklichen kann.
Danke.

gruss

Zitat von EWeiss:

Kann doch nicht einen Thread in 5 Threads aufsplitten um das zu umgehen.
Zumindest habe ich dazu wenn es möglich wäre nicht die erfahrung.

Doch, genau das solltest du versuchen! (Und wenn du jetzt wie der Ochs vorm Berg stehst weist du warum automatische Parallelisierung nicht so der Renner ist)

zum Beispiel habe ich drüben in der EE mal was programmiert was eine lange Zahl mit X multiplizieren musste. Hat natürlich auch 100% CPU Last auf einem Kern gehabt. Dann habe ich das mal auf Papier überprüft und gesehen, dass man das durchaus parallelisieren kann: Man gibt teilt die Zahl einfach in 2 Teile in der Mitte duch. Jeweils ein Thread multipliziert nun eine Hälfte mit X. Was der "linke" herausbekommt ist das Ergebnis was ich wollte. Der Übertrag, den der "rechte" rausbekommt, muss anschließend auf die linke Hälfte draufaddiert werden.

Multiplikation lässt sich also parallelisieren. bei der FFT bin ich mir nicht sicher, aber es könnte schon sein dass das gar nicht geht. Leider gibt es eine Kategorie "einfach parallelisierbar" und eine "quasi nicht parallelisierbar" und nur selten was dazwischen.

@Phoenix: Wenn man hier upvoten könnte, dein Post wäre das wert

Zitat:

@Phoenix: Wenn man hier upvoten könnte, dein Post wäre das wert

Jo war sehr gut erklärt! danke nochmal dafür

gruss

Dazu müsste man jetzt erstmal wissen, wo genau die Zeit verbraucht wird - also am besten einen Profiler hernehmen.

Zum Beispiel ließen sich die 0..511 Schleifen am Anfang einfach parallelisieren, aber das ist vermutlich fruchtlos weil die eh nicht lange dauern.

Zitat von jfheins:

Dazu müsste man jetzt erstmal wissen, wo genau die Zeit verbraucht wird - also am besten einen Profiler hernehmen.

Zum Beispiel ließen sich die 0..511 Schleifen am Anfang einfach parallelisieren, aber das ist vermutlich fruchtlos weil die eh nicht lange dauern.

Die meiste power nimmt das rendern in der externen DLL(Plugin) in Anspruch..
Denke mal das ich da nicht viel machen kann.
Na ja dann müssen sich die User mit den verfügbaren Einstellungen begnügen und diese so anpassen
das ihr system das Rendern in erträglichen Ausmaß verkraften.

gruss