Alle CPUs nutzen friert Rechner ein
-
oder einfach den UI thread hoeher prioritisieren, done.
-
Also ich las, dass der Erzeuger-Thread auch die Priorität für die OpenMP-Threads festlegt. Wenn ich seine Priorität also runtersetze, dürften die durch OpenMP erzeugten Threads auch niedriger priorisiert sein.
Ich habe bislang omp_get_max_threads() genutzt. Auf meinem DualCore mit Hyperthreading, ergibt das vier. Ungeprüft und vermutet: Jetzt liegt wohl der UI-Thread auf Kern1 und die OpenMP-Threads verteilen sich wieder auf alle Kerne. Mit niedrigerer Priorität scheint es jetzt stabiler zu laufen. Alle vier Kerne sind stets zu 100% ausgelastet. Das stört ohne niedrigere Priorität das GUI und scheint eben auch andere Prozesse von Windows lahmzulegen, die gar nichts mit meiner Software zu tun haben (sehe ich erstmal als BS-Scheduling-Fail, aber gut). Testsystem war hier Windows 7. Ich selbst kann das gar nicht reproduzieren.
Ich versuche den Tester auch gerade zu erreichen, um festzustellen, ob er mit dem Update, welches die Prioritäten runtersetzt, besser fährt. Es bleibt spannend.
-
ich glaube du hast keinen einfluss darauf, wann der worker pool erstellt wird. du kannst im thread-view vom VS debugger dir die priorities anschauen fuer deinen fall. die threads werden vermutlich auch dynamisch verteilt, kannst also nicht von einem spezifischen kern ausgehen.
aber solange du es irgendwie hinbekommst dass der UI thread ueber den anderen ist, sollte es laufen wie du moechtest.
ja, windows 7 ist bescheiden, hab hier 32cores und wenn ich clang auf allen laufen lasse, dann kann ich nichts mehr machen (mauszeiger springt auf dem schirm sporadisch). hatte dasselbe problem auf dem laptop, seit win10 ist es besser.
ich weiss nicht, ob das ein scheduling fail ist, oder event handling in windows, oder vielleicht vom cursor-update prozess. aber sowas in einem produkt zu verkaufen ist echt arm. linux und osx zeigen dass es besser geht.