3. Alle CPUs nutzen friert Rechner ein

Alle CPUs nutzen friert Rechner ein

  • E

    Hi,

    hustbaer: Richtig erkannt, ich nutze Windows. 🙂

    Da OpenMP ein high-level Threadingframework ist, sollte es eigentlich genug sein, einfach die Priorität des ganzen Prozesses (oder was auch immer das Äquivalent eines Unix-Prozesses bei deinem Betriebssystem ist) zu senken.

    Also wenn ich das hier nicht falsch verstehe, habe ich eigentlich einen Hauptthread, der auch die UI-Eventloop verwaltet, und der ruft OpenMP auf... wäre jetzt ziemlich sinnlos dessen Priorität zu senken, dann haben die OpenMP-Threads ja wieder dieselbe Priorität wie der Mainthread. UI ist QT, falls das was ändern sollte.

    Kannst du mal gucken wie die Default-Priorität der OpenMP Threads ist?

    Geschaut, haben alle THREAD_PRIORITY_NORMAL (0)

    Meine Threads nutzen kein I/O, jedenfalls nicht die, die ich zurzeit parallelisiert habe. Würde ich mit den anderen aber auch noch machen wollen.

    0
  • R

    Eisflamme schrieb:

    Hi,

    hustbaer: Richtig erkannt, ich nutze Windows. 🙂

    Da OpenMP ein high-level Threadingframework ist, sollte es eigentlich genug sein, einfach die Priorität des ganzen Prozesses (oder was auch immer das Äquivalent eines Unix-Prozesses bei deinem Betriebssystem ist) zu senken.

    Also wenn ich das hier nicht falsch verstehe, habe ich eigentlich einen Hauptthread, der auch die UI-Eventloop verwaltet, und der ruft OpenMP auf... wäre jetzt ziemlich sinnlos dessen Priorität zu senken, dann haben die OpenMP-Threads ja wieder dieselbe Priorität wie der Mainthread. UI ist QT, falls das was ändern sollte.

    du sprachst weiter oben davon dass du einen eigenen UI prozess hast

    dass auch mein UI-Prozess sehr langsam

    falls du nur einen thread hast der nicht mehr UI events verarbeitet weil er mit OpenMP berechnungen ausfuehrt, ist das eine ganz andere situation.

    0
  • E

    Hi,

    also das UI läuft im selben Prozess wie auch der Rest des Programms. Wollte damit nicht sagen, dass das Hauptprogramm einen Prozess erzeugt, welcher das UI verarbeitet, das geschieht hier nicht.

    OpenMP wird also aus demselben Prozess gestartet, der auch die Eventloop beinhaltet.

    0

  • Dir ist aber schon klar dass OpenMP in dem Sinn synchron ist dass der Thread der auf OpenMP Konstrukte wie parallel for trifft erst weiter läuft wenn diese Konstrukte vollständig abgearbeitet wurden?

    0
  • R

    Eisflamme schrieb:

    OpenMP wird also aus demselben Prozess gestartet, der auch die Eventloop beinhaltet.

    was wuerde dann sowas bringen:

    Eisflamme schrieb:

    Setzt man einfach ein Sleep(1) oder so was in die Threads, um 100% Auslastung zu vermeiden?

    das ist ein wenig verwirrend.

    wenn openmp aus ist (also single threaded), funktioniert dann alles wie gewollt?

    0
  • E

    Ach sorry, ich hab einfach Mist erzählt... OpenMP läuft natürlich doch in einem ausgelagerten Thread, sonst wär ja ständig alles eingefroren. Soweit ich das verstehe habe ich dennoch nur einen Prozess, wenn man jetzt mal zwischen Thread und Prozess unterscheidet. Man sieht also im Taskmanager bei Windows unter Details nur einen Eintrag.

    Wenn ich den Prozess also langsamer machen würde, wäre das sinnlos, aber den Thread, der OpenMP ausführt, das wäre wohl sinnvoll. Und stimmt, das könnte ich dann tatsächlich einfach vor der OMP-Ausführung machen statt das jedem Thread einzeln anzutun. 🙂

    0

  • Eisflamme schrieb:

    aber den Thread, der OpenMP ausführt, das wäre wohl sinnvoll. Und stimmt, das könnte ich dann tatsächlich einfach vor der OMP-Ausführung machen statt das jedem Thread einzeln anzutun. 🙂

    Naja OpenMP erzeugt ja haufenweise Worker.

    Und die erben vermutlich die Priorität nicht von irgendwo sondern werden eben vermutlich per Default Priorität 0 bekommen.

    Wie viele OpenMP Threads erzeugst du denn? Kann mir nämlich immer noch nicht ganz vorstellen warum OpenMP so reinhauen sollte dass die GUI kaum mehr erträglich funktioniert -- vorausgesetzt eben du machst nicht mehr OpenMP Threads als du Hardware-Threads hast.

    0
  • R

    oder einfach den UI thread hoeher prioritisieren, done.

    0
  • E

    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.

    0
  • R

    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.

    0
Anmelden zum Antworten