Probleme mit Performance (Berechnungen und Grafik)

Hallo ihr,

zur Zeit belege ich einen LabView-Kurs. Als Teil des Leistungsnachweises sollen wir ein beliebiges Projekt umsetzten. Der Dozent sieht hier gerne Spiele. In meinem Spiel steuert man ein kleines spritziges "ferngesteurtes" Modellluftkissenboot aus der Vogelperspektive und muss gegen die Zeit Punkte einsammeln.

Die Rotation realisiere ich mit 360 einzelnen Bilddateien in einem Array. Die Berechnungen für Kräfte und Bewegung ist relativ aufwändig. Die Hauptschleife wird im 15ms-Takt ausgeführt... Jedenfalls komme ich bereits an die Grenzen, was LabView performancemäßig diesbezüglich so bringt.

Die Darstellung des Frontpanels in den Eigenschaften auf "Dialog" zu stellen, hat sehr viel gebracht (Datei->VI-Einstellungen->Fenstererscheinungsbild->Dialog). Das Fahrzeeug lässt sich nun flüssig steuern. Allerdings darf ich parallel nicht noch verschiedene Werte, wie Geschwindigkeit, Winkel usw. auf Rundinstrumenten darstellen. Dann ruckelt es schon wieder.

Habt ihr vielleicht Tipps für mich, wie ich mehr aus LabViw rausholen könnte, was Rechenleistung angeht? Oder muss ich akzeptieren, dass LV für sowas nicht gemacht ist und auf weitere performancehungrige Features verzichten muss?

Was leider nicht in Frage kommt ist, mit C/C++ dlls zu schreiben und einzubinden, da es ein reiner LV-Kurs ist und nur bewertet werden kann, was ich mit LV gemacht habe.

Am Rande wollte ich euch nich fragen, on ihr wisst, weshalb die Dialog-Darstellung so viel mehr Leistung bringt? Habe das zufällig herausgefunden. Es wundert mich. Es macht wirklich einen sehr großen Unterschied, aber woher soll das denn kommen?

Vielen Dank schonmal!

Hallo catbull,

willkommen im Forum!

- dein Hauptproblem dürfte die Grafik-Performance sein: musst du wirklich mit knapp 70Hz ein UI updaten?
- wenn du mehr als 15ms benötigst, um einen Bewegungsvektor zu berechnen, stimmt irgendwas nicht...

P.s.: ich kann Spielchen wie Tetris, Snake oder 2048 zum Programmieren empfehlen...

(19.07.2018 21:42 )catbull schrieb:  Die Rotation realisiere ich mit 360 einzelnen Bilddateien in einem Array.

Ohne das VI gesehen zu haben, tippe auch ich, dass das die meiste Zeit beansprucht.

Zitat:Die Berechnungen für Kräfte und Bewegung ist relativ aufwändig.

Wenn du von aufwändig sprichst, meinst du dann eine punktweise Integration zweiten Grades oder eine kontinuierliche Integration über ein Array? Selbst das wäre wahrscheinlich schneller als Graphik.

Beachte, dass du die Berechnung auslagern könntest in einen parallelen Prozess ...

Was sagt denn der Taskmanager über die Prozessorauslastung?

Danke für eure Antworten!

(19.07.2018 21:52 )GerdW schrieb:  - dein Hauptproblem dürfte die Grafik-Performance sein: musst du wirklich mit knapp 70Hz ein UI updaten?
- wenn du mehr als 15ms benötigst, um einen Bewegungsvektor zu berechnen, stimmt irgendwas nicht...

Da geb ich dir allerdings recht. Das wird das erste sein, was ich (wieder) ändern werde. Auf die schnelle geht das aber nicht, weil ich viele Parameter anpassen, also viel herumprobieren muss. "Wieder ändern", weil ich das anfangs schon versucht habe, es aber keinen Effekt hatte. Ich habe die Frequenz dann wieder erhöht, weil ich dann auch mal gedacht habe, dass die vielleicht zu niedrig wäre. Das Dialog-Dingens hats dann gebracht. Aber Dialog-Modus UND kleinere Frequenz, ja, das ist allerdings einen Versuch wert.

(20.07.2018 08:12 )IchSelbst schrieb:  

(19.07.2018 21:42 )catbull schrieb:  Die Rotation realisiere ich mit 360 einzelnen Bilddateien in einem Array.

Ohne das VI gesehen zu haben, tippe auch ich, dass das die meiste Zeit beansprucht.

Meinst du? Die werden ja alle geladen bevor es losgeht...

(20.07.2018 08:12 )IchSelbst schrieb:  

Zitat:Die Berechnungen für Kräfte und Bewegung ist relativ aufwändig.

Wenn du von aufwändig sprichst, meinst du dann eine punktweise Integration zweiten Grades oder eine kontinuierliche Integration über ein Array? Selbst das wäre wahrscheinlich schneller als Graphik.

Beachte, dass du die Berechnung auslagern könntest in einen parallelen Prozess ...

Nein nein. Deswegen ja "relativ" . Es gibt garkeine Integration. Die "Physik" realisiere ich nur näherungsweise. Es gibt einen Vektor für die Geschwindigkeit und zur gleichen Zeit maximal 2 Kraftvekoren, die auf die Geschwindigkeit einwirken. Dann noch Übersteuerung usw.

Das mit dem parallelen Prozess hört sich interessant an. Ich konnte auf die schnelle nicht herausfinden, was du damit meinst. Meinst du eine parallele While-Schleife? Würde das was bringen?

(20.07.2018 08:12 )IchSelbst schrieb:  Was sagt denn der Taskmanager über die Prozessorauslastung?

Wenn ich die verschiedenen Rundinstrumente weglasse und es komplett nur das Fahrzeug ist, das sich bewegt: maximal 13% -ruckelt aber auch nicht. Mit den Rundinstrumenten: um die 25%. Dann läuft es aber schon nichtmehr flüssig. Wenn ich die Darstellung wie beschrieben nicht auf Dialog sondern auf Standart stelle: ca. 45% und der Spielfluss wird unregelmäßig gebremst. Im Taskmanager die Priorität zu ändern bring nichts (Hat das schon jemals etwas gebracht?). Außerdem fällt auf, dass es ganz zu Beginn besser ist. Nach wenigen Sekunden läuft dann der CPU-Lüfter an und es fängt an zu bremsen. Trotzdem geht die CPU-Auslastung nicht hoch.

Weshalb werden denn nicht an die 100% verwendet? Kann es sein, dass die HD3000-Grafikeinheit nicht hinterher kommt? Kann ja auch fast nicht sein. Klar bringt die HD3000 nicht viel, aber das ist ja schon wesentlich weniger als viel. Weiß jemand, ob LV sein Grafikzeugs überhaupt auslagert?

Leider muss ich gleich schonmal sagen, dass ich bis Ende nächste Woche keine Zeit habe mich darum zu kümmern. Klausuren. Danach werde ich den Thread wieder herausziehen und eine, ich sag mal, uploadbare Version herrichten und mal herzeigen. Vielleicht hat jemand ja Lust mal kurz reinzuschauen und sieht vielleicht sofort, was da an der Leistung nagt. Es wäre sehr förderlich für das Spielchen, wenn ich performancemäßig nicht so eingeschränkt wäre.


Jedenfalls danke nochmal. Ich melde mich nächste Woche wieder.

(20.07.2018 20:41 )catbull schrieb:  Meinst du? Die werden ja alle geladen bevor es losgeht...

Ich meine ja auch nicht das Laden in den Speicher, sondern das Verschieben innerhalb des Speichers: Irgendwann muss ja mal das Bild vom Array raus auf den Bildschirm ....

Zitat:Meinst du eine parallele While-Schleife?

So ähnlich. Eher ein paralleles SubVI.

Zitat:Würde das was bringen?

Wenn es sich nur um einfache mathematische Operationen handelt, eher nicht.

Zitat:Wenn ich die verschiedenen Rundinstrumente weglasse und es komplett nur das Fahrzeug ist, das sich bewegt: maximal 13% -ruckelt aber auch nicht.

13% ist viel. Wie viele CPUs hat denn der Rechner. Ich hoffe mal vier oder mehr.

Zitat:Mit den Rundinstrumenten: um die 25%. Dann läuft es aber schon nicht mehr flüssig.

Ab 25% wird es kritisch: Auslastung eines Cores, ganz schlecht.

Zitat:Wenn ich die Darstellung wie beschrieben nicht auf Dialog sondern auf Standart stelle: ca. 45% und der Spielfluss wird unregelmäßig gebremst.

Ich glaube, du solltest an der richtigen Stelle im Programm eine Pause einfügen. Dein Datenfluss läuft kontinuierlich.

Achtung, es kommt ein Spässchen: Wenn der Dialog auf Standart steht, unterhalten wir uns mittels Flaggen in einer bulgarischen Zeitung. Wenn allerdings Standard eingestellt ist, ist das Fenster nicht modal. Warum aber zwischen modal und nicht modal so viel Unterschied sein soll, muss ich mir erst mal durch den Kopf gehen lassen.

Zitat:Im Taskmanager die Priorität zu ändern

Vergiss es.

Zitat:Nach wenigen Sekunden läuft dann der CPU-Lüfter an und es fängt an zu bremsen. Trotzdem geht die CPU-Auslastung nicht hoch.

Nach wenigen Sekunden wird der Core heißt und muss gekühlt werden ...

Zitat:Weshalb werden denn nicht an die 100% verwendet?

Du stellst Fragen. Wahrscheinlich weil mindestens ein Core nicht durch den selben Prozess belegt werden kann, wie die anderen drei. Das Betriebssystem wäre schön blöd würde es sowas zulassen. Dann kann es nämlich selbst nichts mehr arbeiten.

Zitat:Kann es sein, dass die HD3000-Grafikeinheit nicht hinterher kommt?

Jein.
An sich wäre die Graphikeinheit bestimmt geeignet, deine Wünsche (bewegte Graphik) darzustellen. Ich kann mir aber vorstellen, dass es zu Datenstau in der Graphikeinheit kommen kann, wenn du Daten zu schnell hineinschiebst.

Mir ist noch was eingefallen:

1. Ohne Sourcecode nur theoretischen Beratung ...

2. Wahrscheinlich ist es sinnvoller anstelle der Berechnung besser die Anzeige parallel auszulagern. Wenn du Bedienelemente am Frontpanel (ohne Eventstrukktur) und die Anzeige der Bilder in einem Blockdiagramm hast - da kann ich mir vorstellen kann es zu gegenseitigem Ausbremsen kommen.