Performance-Frage: Große Arrays in Cluster-Schieberegister

' schrieb:@abrissbirne: Hm, das könnte sein. Wobei SeBas Lösung genau das macht, wenn ich das richtig sehe.

Stimmt schon. Hab aber auch nicht behauptet, dass die Lösung das Non+Ultra ist.

Ich hab nur "dynamic Array Size" zwischen deinen Zeilen gelesen... und neugierig wie ich bin, wollt ich halt wissen ob/wie's funktionieren kann.
Und da ich solche Dinge gerne Teile, hab ichs halt auch hochgeladen.


Also lass den Quatsch lieber und benutz nur den Index Counter, das Replace Array und beleg dein maximal großes Array vorher mit NaN.
Das erste NaN kannst du ja mit 1D-Array durchsuchen finden.


Wobei ich mich dann frage, wenn das Array so groß ist, dass der RAM nicht mehr reicht... klappts ja sowieso nicht. Laufzeit hin oder her.
Natürlich vorrausgesetzt, LV/WinDoof w/e entsorgt die ungebrauchten Teile und räumt ab und zu mal auf? Macht es das? k.A.


Gruß SeBa

Fürn Fixed Sized Puffer würde ich Named Queues mit fester Größe und Vorallozierung nehmen. Sind flexibel und schnell. Je nach gusto auch Unnamed Queues mit eigener Referenzverwaltung. Durch die Queuefunktionen bekommt man Anhängen, Pufferfüllstand, Überschreibschutz und Flush am Ende quasi für umme.

' schrieb:Fürn Fixed Sized Puffer würde ich Named Queues mit fester Größe und Vorallozierung nehmen. Sind flexibel und schnell. Je nach gusto auch Unnamed Queues mit eigener Referenzverwaltung. Durch die Queuefunktionen bekommt man Anhängen, Pufferfüllstand, Überschreibschutz und Flush am Ende quasi für umme.

Yup, so mach ich es auch immer

Ich dachte mir, falls eine Messung doch mal länger dauern sollte oder der Puffer zu klein vorbelegt wird, dass dann kein Fehler auftritt und das Array automatisch vergrößert wird.
Wobei ich die max. Array-Größe wie folgt berechnen kann: Rate [Hz] * Timeout[s]

Ob Windows aufräumt, weiß ich nicht. Später sollte das ganze auch auf einem cRIO lauffähig sein.

Named Queues muss ich mir erst mal ansehen. Damit habe ich noch nichts gemacht.
Soll der Queue-Puffer dann für die Messwertspeicherung sein, also die Arrays ersetzen oder wie ist das gemeint?

Ja die Messwerte sind dann die Elemente in der Queue. Ohne die Anwendung genau zu kennen, würde ich als Datentyp der Queue DBL (skalar) vorsehen und dann ggf. mehrmals Enqueue aufrufen um das Array reinzuschreiben.
Musst halt aufpassen, daß du nicht versuchst mit -1 timeout in die Queue reinzuschreiben wenn sie voll läuft.

' schrieb:Ja die Messwerte sind dann die Elemente in der Queue. Ohne die Anwendung genau zu kennen, würde ich als Datentyp der Queue DBL (skalar) vorsehen und dann ggf. mehrmals Enqueue aufrufen um das Array reinzuschreiben.

Mal ne Frage: Der Vorteil am BuildArray ist ja der, dass man sich um irgendwelche Speichergrößen keinen Kopf machen muss, LV allokiert von alleine. Klar, die Nachteile sind bekannt...(Array-Kopien).

Wenn ich aber ein wirklich großes Array habe (ich hab hier ne kontinuierliche Abtastung mit 1,25 MS/s für mindestens mal 2-3 Sekunden, aber eben zeitlich nicht genau spezifizierbar, dass hängt ein bisschen von den Umgebungsbedingungen am Prüfstand ab...bis halt ein "Trigger" kommt!)...wie geht man da dann mit Queues um? Wenn ich da jeden Wert einzeln mit "Enqueue" schreibe...das frisst mir doch meine Anwendung auf, oder?

Wie würdet ihr vorgehen?

A.

Hallo Achim,

man muss ja nicht jeden Wert einzeln in die Queue schieben - 32k-Blöcke tun's doch auch

Seitdem ich festgestellt habe, daß die Funktion "In 1D-Array rotieren" sauschnell ist (- im Gegenatz zu dem, was man da mutmaßen könnte -), sind bei mir komplizierte Ringpufferstrukturen mit Indexzeigern usw. ad acta gelegt. Ebenso auch die hier vorgeschlagene Verwendung von Queues als Rinpuffer-Konstrukt.
Einfaches, ausbaubares Beispiel:

  Ringpuffer.vi (Größe: 25,96 KB / Downloads: 283)

' schrieb:die Funktion "In 1D-Array rotieren" sauschnell ist

Schnell ist die Funktion schon, nur wo liegt der Speicher der damit rotiert wird?
FGVs oder nackte SR sind von der Skalierbarkeit halt recht eingeschränkt.
Flach durchverdrahtet bzw. in größere Datenstrukturen gepackt, ist mitunter schwierig ohne unnötige Kopien zu realisieren.

' schrieb:Schnell ist die Funktion schon, nur wo liegt der Speicher der damit rotiert wird?
FGVs oder nackte SR sind von der Skalierbarkeit halt recht eingeschränkt.
Flach durchverdrahtet bzw. in größere Datenstrukturen gepackt, ist mitunter schwierig ohne unnötige Kopien zu realisieren.

Mag alles sein, nur benutze ich die Funktion als Rinpuffer für graphische Anzeigen. Da habe ich es nicht mit so großen Datnstrukturen zu tun, und deshalb interessiert mich die Speicherverwendung nicht sonderlich. Ein Diagramm hat typischwereise 1000 Pixel, mehr Datenpunkte sind nicht darstellbar. Wer riesenhafte Datenmengen nicht vor der Visualisierunge entsprechend reduziert, ist selbst schuld wenn er Probleme bekommt. (Hier kann man manches entgegenhalten, z.B. wenn man das Diag hinterher stark zoomen will. Na dann mal los)