Speicherbedarf FGV

(12.01.2012 14:59 )abrissbirne schrieb:  Natürlich darf das FP nicht geöffnet sein und es gibt einen Unterschied zw. LV 2011 und der hochgeladenen LV 8.6. Da ist der Compiler noch nicht so schlau wie heute.

Natürlich gemessen mit FP geschlossen...

Selbst mit FGV als Subroutine und unter LV 8.6.1 ergibt sich kein anderes Bild.

Auch damals wusste der Compiler schon, daß er die Daten beim FGV-Ausgang kopieren muss.

Anzeige

Man sollte auch mal das bedenken:
Das Wesen der Erzeuger- Verbraucher-Struktur ist die Entkopplung von Erzeugung und Verbrauch durch einen Zwischenpuffer. Erzeugung und Verbrauch müssen dann nicht mehr exakt synchron zueinander laufen.
Ich habe jahrelang gebraucht, bis ich diesen Lichblick hatte: Die Datenerfassung mit NI Messkarten und auch über die Soundkarte ist wegen der gepufferten Übergabe bereits ein Erzeugersysten mit eigenem Puffer. Die übliche Erzeuger-Verbraucher - Struktur ist in Wirklichkeit eine Erzeuger-Erzeuger-Verbraucher-Struktur mit doppelter Zwischenpufferung und überflüssig wie ein Kropf.
Das nur mal als Einwurf, müsst ja nicht hinhören und könnt weitermachen.

Hallo Lucki,

Ich find es super, wenn du uns an deiner Erfahrung teilhaben lässt! Nur versuche ich momentan noch die Tragweite deiner Aussage zu ergründen. Meinst du das ausschließlich für die Messdatenerfassung über Hardware? Oder noch genereller? Klang für mich zunächst, wie "Producer/Consumer-Struktur ist ein Kropf", aber dann dachte ich mir: Es gibt ja auch noch andere Anwendungsfälle (Events, Commands, States, Communication, ...).
Also meine Aufmerksamkeit hast du geweckt, immer her mit den Einwürfen!

Gruß

(12.01.2012 15:24 )macmarvin schrieb:  

(12.01.2012 14:59 )abrissbirne schrieb:  Natürlich darf das FP nicht geöffnet sein und es gibt einen Unterschied zw. LV 2011 und der hochgeladenen LV 8.6. Da ist der Compiler noch nicht so schlau wie heute.

Natürlich gemessen mit FP geschlossen...

Selbst mit FGV als Subroutine und unter LV 8.6.1 ergibt sich kein anderes Bild.

Auch damals wusste der Compiler schon, daß er die Daten beim FGV-Ausgang kopieren muss.

Allerdings nur wenn das FP geöffnet ist. Wenn die Controls und Indicator auf der BD Root liegen wird der Speicher des aufrufenden VIs verwendet.

(12.01.2012 16:06 )abrissbirne schrieb:  Allerdings nur wenn das FP geöffnet ist. Wenn die Controls und Indicator auf der BD Root liegen wird der Speicher des aufrufenden VIs verwendet.

1. Selbst wenn physikalisch der Speicherbereich des Aufrufers verwendet wird, müssen die Daten der FGV SR erst noch da rein _kopiert_ werden.
2. Zeig mir den Testcode in dem bei der Verwendungen der zweiten FGV weniger Speicher verbraucht wird als bei der Ersten?
3. Bzgl. des FP... deshalb mein Einwand vorher bzgl. subroutine... damit ist's unerheblich ob das Ding offen ist oder nicht.
4. Wenn ich mich Recht entsinne haben wir so eine fruchtlose Diskussion ergebnislos geführt.

(12.01.2012 18:40 )macmarvin schrieb:  4. Wenn ich mich Recht entsinne haben wir so eine fruchtlose Diskussion ergebnislos geführt.

Von daher lassen wirs einfach.

Um das mal kurz zusammenzufassen und nachzuvollziehen:

FGV: Speicherverbrauch für Anzeige auf FP (nehme mal an, das wäre dann das was sich bei geschlossenem FP ändert (?).
Außerdem Speicherverbraucht für Daten im Schieberegistereingang.

Read Case:
1. Es geht nichts in die FGV rein ---> kein zusätzlicher Verbrauch.

2.
Fall 1. : Im Case wird abgezweigt - Erzeugung einer Kopie bzw. da nur lesend eventuell auch nicht
Fall 2. : Im Case ist durchverdrahtet - kein zusätzlicher Speicherverbrauch bisher

3.
Fall 1. : Es wird ins Schieberegister geschrieben - das ist existierender Speicher (der vom Eingang) - kein zusätzlicher Speicherverbrauch.
Fall 2. : Auch hier wird nur ins Schieberegister geschrieben.

4.
Fall 1. : Die Daten werden ans aufrufende VI weitergereicht. Da ein neuer Speicherbereich bereits erzeugt wurde werden die also wie sie sind weitergegeben (quasi als Referenz) (?) Wurde bei 2. noch kein Speicher alloziert dann spätestens jetzt (siehe Fall 2).
Fall 2. : Die Daten stehen immer noch nur im Schieberegister. Es muss zwingend eine Datenkopie erzeugt werden, da nicht gewährleistet werden kann, das die Daten im Schieberegister sich nicht enden bzw. das auslesende Programm damit weiterarbeitet und sie verändert.

Ergebnis:

Letztlich hängt sich alles an 2. und 4. auf. Wird in 2. kein Speicher neu alloziert (da kein Schreibvorgang auf den Daten stattfindet) unterscheiden sich beide Varianten nicht. Wird hingegen in 2. Speicher alloziert (bei Fall 1), dann wäre entscheidend das Verfahren am Programmende. Wird neuer Speicher immer bei der Übergabe angefordert oder nur kontextsensitiv - daher nur wenn dies das nicht initialisierte Schieberegister zwingend erfordert. Nur wenn immer Speicher neu alloziert wird bei Übergabe ist Variante 1 weniger effektiv (durch 2 Allozierungen gegenüber einer). Ansonsten macht Sie die Allozierung lediglich woanders (nämlich innerhalb der FGV und nicht erst bei der Übergabe).

Sollte man sogar testen können (auch wenn ich nicht weis ob der Test das Verhalten ändern würde). Man nehme eine FGV mit beiden Wegen. Die gibt nun einmal ganz normal jeweils den Wert aus. Zusätzlich holt man sich eine Referenz innerhalb der FGV kurz vor der Übergabe "nach aussen". Die auch ausgegeben wird (es reicht die Referenz auf Variante 1 mit Abzweig). Je nachdem ob eine weitere Kopie erzeugt wurde sollte man damit dann programmatisch auf die an den Aufrufer übergebene Variable zugreifen können - oder eben auch nicht (da die entweder noch im gleichen Speicherbereich steht oder eben nicht).

Mal so als vorschlag ^^

Gruß Kiesch

P.S: Hoffe ich hab das richtig zusammengefasst.