' 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
