10.08.2009, 11:20
(Dieser Beitrag wurde zuletzt bearbeitet: 10.08.2009 19:15 von jg.)
Beitrag #1
|
abrissbirne
LVF-Stammgast
Beiträge: 480
Registriert seit: Aug 2007
LV2009, LV2010
2007
EN
66123
Deutschland
|
Speicherallozierung - 1D/2D/3D-Arrays
EDIT Jens G:
Innerhalb des Beitrages:
http://www.LabVIEWforum.de/index.php?showtopic=13731
hatte sich eine zweite Diskussion um 1D-/2D- und 3D-Arrays entwickelt. Nachdem das im Originalthread etwas verwirrend wurde, habe ich die entsprechenden Beiträge hierher verschoben.
Hier also:
' schrieb:Mir fällt jetzt spontan kein Grund ein, warum ich auf Array mit mehr als 2 Dimensionen verzichten sollte. Darf ich deshalb fragen, wieso du sie vermeidest?
Ich habe schon Probleme mehr als 250 Bilder mit einer Kamera der Auflösung 320x256 Pixel mit 3D-Arrays aufzunehmen (Speicherüberlauf). LV handled alles was über 1 Dimension hinaus geht einfach "schlecht". Im Prinzip weiß kaum jemand das er damit Speicher allokiert. LV macht es einem also leicht Speicher zu reserviren, aber lässt einem diesen nicht wieder einfach so freigeben. Ich arbeite also immer mit 1D Arrays in LV.
|
|
|
10.08.2009, 11:55
Beitrag #5
|
abrissbirne
LVF-Stammgast
Beiträge: 480
Registriert seit: Aug 2007
LV2009, LV2010
2007
EN
66123
Deutschland
|
Speicherallozierung - 1D/2D/3D-Arrays
' schrieb:Beim Rücksprung aus einem SubVI kann man von LV eine Speicherfreigabe anfordern: Application control > Memory Control > Request Deallocation.vi
Bei mir hat er auch damit nie den Speicher freigegeben. Das ist nur eine höfliche Bitte an LV Speicher frei zu geben. Ob es das macht ist eine andere Sache.
' schrieb:Mit 32 Bit pro Pixel wären es knapp 80 MB. Da dürfte es selbst mit der übelsten Speicherverwaltung keine Probleme geben.
Probier es doch einfach mal. Ich kann dir nur sagen das es bei mehr als 250 Bilder (nur 16Bit pro Pixel) zu besagtem Überlauf kommt.
' schrieb:Nur mit 1D-Array zu arbeiten ist in LV gar nicht möglich und in manchen Fällen sind durch den Verzicht auf 2D-Array mehr Ressourcen notwendig als mit. Wenn ich beispielsweise 8 Kanäle auf die HD streamen will läuft das auf jeden Fall mit einem 2D-Array schneller als mit 8 1D-Arrays und 8 Aufrufen der Speicherfunktion.
Sicher ist es möglich. Sag mir mal was ich in einem 1D array nicht eblegen kann was ich in einem 2 oder 3D Array ablegen kann? Ich würde nicht 8 1D-Arrays sondern ein 1D-Array mit genügent Elementen alnegen.
' schrieb:Dass LV den Speicher nicht gerade auf die eleganteste Art und Weise handelt ist mir bekannt. So sollte ja auch auf Cluster mit Array mit Clustern verzichtet werden. Dass aber LV so schlecht ist wie du sagst, kann ich mir nicht so recht vorstellen. Meiner Erfahrung ist die, dass LV in der Lage ist, große Array einigermaßen zu handeln, viele Nutzer aber ständig Kopien anlegen und dadurch den Speicher zumüllen.
Den Nutzer lass ich einfach mal aus dem Spiel, da er nichts dafür kann. Er möchte nur eine Software die macht was sie soll. Ich habe bisher nur schlechte Erfahrungen mit den LV-Eigenen Methoden mit großen Datenmengen umzugehen gemacht.
|
|
|
10.08.2009, 12:07
Beitrag #6
|
schrotti
LVF-Freak
Beiträge: 842
Registriert seit: Feb 2008
2009 - 2011
2006
kA
70180
Deutschland
|
Speicherallozierung - 1D/2D/3D-Arrays
' schrieb:Probier es doch einfach mal. Ich kann dir nur sagen das es bei mehr als 250 Bilder (nur 16Bit pro Pixel) zu besagtem Überlauf kommt.
Habs gerade mit 32 Bit ausprobiert und kein Problem erkennen können.
' schrieb:Sicher ist es möglich. Sag mir mal was ich in einem 1D array nicht eblegen kann was ich in einem 2 oder 3D Array ablegen kann? Ich würde nicht 8 1D-Arrays sondern ein 1D-Array mit genügent Elementen alnegen.
Die Konsequenz wäre nur ein Kanal in der Datei, den ich später aufwendig aufdrösseln muss. Natürlich kann ich das machen, aber Vorteile habe ich damit nicht.
' schrieb:Den Nutzer lass ich einfach mal aus dem Spiel, da er nichts dafür kann.
Ich meinte damit den Nutzer der LabVIEW Entwicklungsumgebung.
|
|
|
10.08.2009, 12:23
Beitrag #7
|
|
|
10.08.2009, 12:54
Beitrag #8
|
|
|
11.08.2009, 11:14
(Dieser Beitrag wurde zuletzt bearbeitet: 11.08.2009 11:28 von rolfk.)
|
rolfk
LVF-Guru
Beiträge: 2.306
Registriert seit: Jun 2007
alle seit 6.0
1992
EN
2901GG
Niederlande
|
Speicherallozierung - 1D/2D/3D-Arrays
' schrieb:Irgendwo habe ich gelesen, dass LV Speicher nur am Stück allokieren kann. Wie LV darin den Speicher verwaltet weiß ich glaube dir, dass die von dir genannte Methode besser klappt. Eigentlich auch logische, denn die Array innerhalb der Clusterelemente können unterschiedlich groß sein. LV kann somit keinen aneinanderhängenden Speicher belegen sondern setzt nur einen Pointer auf das Array rein. Wie LV dann vorgeht, um dieses Array zu speichern, weiß ich nicht. Es kann allerdings nicht irgendwo im Speicher liegen, da LV wie gesagt nur einen Bereich verwalten kann.
Das war Windows 3.1.
Seit Windows wirklich 32 Bit ist bekommt eine Applikation grundsätzlich einen 2GB (3GB mit speziellem boot.ini Eintrag, aber es ist keine gute Idee diesen Switch grundsätzlich zu verwenden, da er denn Speicher für den Kernel auf 1GB begrenzt und damit den Kernel ziemlich stark einschränkt) virtuellen Adressbereich zugewiesen.
Ob der auch alloziert werden kann hängt natürlich vom wirklich vorhandenen Speicher ab. LabVIEW fragt jeden Speicher ganz einfach beim OS an, und ja ein einzelnes Array muss ganz in einem einzigen aneinanderliegenden Block abgespeichert werden. Windows wählt irgendeinen Block im Speicherraum der gross genug ist und gibt diesen zurück. Die virtuelle Speicherverwaltung von x86 Prozessoren hat aber ihre Beschränkungen und kann nicht beliebig viele einzelne Speicherblöcke im virtuellen Speicherraum verwalten, da jeder Block auch wieder entsprechende Verwaltungsresourcen erfordert. Irgenwann mal gibt es entweder nicht mehr genug Speicherdeskriptoren für solche Blöcke oder aber der Speicher wurde inzwischen so fragmentiert dass Windows nicht mehr einfach einen genügendgrossen aneinanderhängenden Speicherblock allozieren kann. Beides resultiert in einem Out of Memory error.
LabVIEW könnte versuchen einen eigenen Memory Manger zu verwenden so wie es das in Windows 3.1 tat und wäre damit vielleicht im Stande in gewissen Grenzfällen eine bessere Verwendung der 2GB zu machen aber das käme mit extra Kosten da es auch wieder Speicher benötigte um die Speicherblöcke selber zu verwalten, was sowohl vom Speicher abginge als extra Laufzeit fragen würde. Windows kann das mindestens so schnell resp. dank der direkten Verwendung der x86 MMU Hardware sogar schneller aber ist nicht unbedingt optimalisiert für Applikationen die eventuel riesige kontinuierliche Speicherblöcke anlegen möchten.
Rolf Kalbermatter
|
|
|
| |