os x stehen geblieben

Original von hns
Und ob die Seiten zusammenhängend im Speicher liegen spielt keine Rolle. Das kann ja die MMU umsortieren.

Wenn der Kernel das beherrscht funktioniert das auch. Tut er's?

Und noch eine Limitierung: Dur hast 32bit für Adressen, also 4GByte Adressraum. Der ist nicht vollständig verfgbar, sondern nur ca. 2GB.

Das ist nicht richtig. Du kannst 3,5GB Adreßraum für Deine Applikation nutzen, davon ist ein Block maximal 2GB groß der andere 1,5GB. 0,5GB sind für den Programmcode, Symbole etc. reserviert. Ich habe das schon ausprobiert, inklusive Speicher beschreiben, es geht wirklich.
Einfach vergessen, da habe ich die OS verdreht, trotzdem kann man maximal einen 2GB Block allozieren, in plain C geht's jedenfalls. Dann ist es jedenfalls ein Problem des Arbeitsspeichers und dürfte sich einfach lösen lassen.

Die Größe, die man Collections mitteilt, hat damit gar nichts zu tun.

a) Die Collection speichert Zeiger, nicht Objekte.
b) Die Größe ist nur ein Hint.

Du überschreibst einfach +alloc oder -init und gibst jeweils einen Zeiger auf deinem Block zurück, anstelle des Zeigers aus dem Heap. Wo liegt das Problem?

Die Größe erhältst du mittels sizeof( Klasse ).

Original von Tom9811
Du überschreibst einfach +alloc oder -init und gibst jeweils einen Zeiger auf deinem Block zurück

Habt Ihr Euch schon mal +allocWithZone und NSZone angeschaut? Das ist zwar seit Jahrzehnten nicht mehr wirklich notwendig (es war eine Speicheroptimierung von NextSTEP damit es mit glaube ich 8MByte RAM läuft), aber immer noch vorhanden.

-- hns

Hmmm, gute Idee!

hmm also mit diesen speicherblöcken bin ich jetzt überfordert. wie meint ihr das?

Das kommt davon, wenn man NSArray als Test nimmt, da kommt 4 raus und das erinniert mich im 32Bit Modus fatal an Zeiger.

Was mich aber verwundet, wenn ich folgendes Programm laufen lasse.


Dann kann man 2GB allozieren und benutzen, ohne daß es Problem gibt. Allerdings wenn man einzelne Blöck von 4k allozieren will, dann scheitert es am Block 450.558 was ca. 1,7GB entspricht. Was passiert mit dem restlichen Speicher? Die einzige sinnvolle Erklärung für mich ist es, daß malloc das im Userspace verwaltet und so ziemlich viel vom Adreßraum aufbraucht. Anders ergibt das für mich keinen Sinn. Allerdings 300MB für eine popelige Liste von 450.000 Speicherblöcken? Das ist schon arg heftig.

Wenn man zusätzlich statischen Speicher belegt, dann wird der Block von 2GB nicht angefaßt solange man unter 256MB statischen Speicher bleibt, wird er größer, wird der Heap eingeschränkt. Allerdings liefert getrlimit dann keinen korrekten Wert mehr zurück. Die Shell gibt den Wert auch nicht vor.

Original von Tom9811
Die Größe, die man Collections mitteilt, hat damit gar nichts zu tun.
...
b) Die Größe ist nur ein Hint.

Es optimiert die Speicherallokation. Jedes malloc insbesondere im Multithreaded Prozessen kostet Zeit und die reallocs erspart man sich auch, wenn man Collections vorher mitteilt wie viele Daten man reinschreibt. Der Speicherfragmentation beugt man auch vor. Es ist daher sinnvoll es zu tun, wenn man viele Datensätze ablegen will, notwendig ist es nicht.

Ja, das weiß ich selbst. Wenn es darum gegangen wäre, hättte ich es auch geschrieben.

Nur hat das nichts mit den von dir geäußerten Zweifeln zum Placement new zu tun. Dazu hatte ich geschrieben. Und hier gilt: Mit Placement new hat das soviel zu tun wie ein ein Waschkkorb voller Damenunterwäsche.

Original von Tom9811
Wo liegt das Problem?

Das Problem liegt darin, daß es mir nicht klar ist, wie ich einer Collection vermitle, wie sie bitte den Speicher für von ihre verwaltete Objekte verwalten soll. Ich sehe in der Doku keine Callbacks, Handles, etc. die mir so etwas auf die einfache Tour erlauben würden.

Wie bringe ich eine Collection dazu, für die interne Struktur (Key-Objektzeiger und Value-Objektzeiger müssen in einer dynamischen Struktur verwaltet werden), die Key-Objekte und die Value-Objekte vorher allozierte Speicherblöcke zu benutzen. Simple Frage wie macht man das?

Jedesmal, wenn Du in Cocoa eine alloc Meldung verschickst, dann wird ein Speicherblock angefordert. Dasselbe passiert auch, wenn das eine Collection macht. Es scheint so zu sein, daß die Verwaltung dieser Blöcke nicht unerheblich Speicher verbraucht und daher schon vorher als vor Erreichen der 2GB Mark der Arbeitsspeicher zu neige geht. Du mußt Dir darüber Gedanken machen, wie Du mit weniger Arbeitsspeicher zu recht kommst. Probeweise kannst Du Deiner Applikation weniger virtuellen Adreßraum zu weisen (das hat den Vorteil das Programm braucht nicht so viel RAM), so daß Du in der Lage bist Dein Programm auf Situationen anzupassen, in denen der Arbeitsspeicher knapp wird. Siehe Doku zum Shell Befehle ulimit bzw. die man pages zu den Funktionen getrlimit bzw. setrlimit.

Original von Tom9811
Und hier gilt: Mit Placement new hat das soviel zu tun ...

std::vector nutzt placement new, wenn man vorher mit reserve Speicher reserviert hat. Ergo, das hat direkt etwas damit zu tun.

Üblicherweise werden in Framework nicht bei jeder Speicheranforderung an das Framework auch gleich Speicheranforderungen an das System geschickt. Wie es Cocoa macht, weiß ich nicht. Der Hintergrund ist, dass so der Speicher fragmentiert und außerdem der System-Overhead am Speicher schnell größer wird als der allozierte Speicher selbst.

Er muss isch das einfach mal bei Cocoa anschauen und ggefls. selbst größere Speicherblöcke anfordern, die er dann benutzt.

Ich kann dir nicht folgen:

Ob Objective-C so etwas kann, weiß ich nicht, aber ich habe so meine Zweifel.

Ok, die Doku sagt, man kann NSMutableDictionary die Speichergröße vorher mitteilen.

Wo ist der Zusammenhang zu std:vector?

Original von tjp
Jedesmal, wenn Du in Cocoa eine alloc Meldung verschickst, dann wird ein Speicherblock angefordert. Dasselbe passiert auch, wenn das eine Collection macht. Es scheint so zu sein, daß die Verwaltung dieser Blöcke nicht unerheblich Speicher verbraucht und daher schon vorher als vor Erreichen der 2GB Mark der Arbeitsspeicher zu neige geht. Du mußt Dir darüber Gedanken machen, wie Du mit weniger Arbeitsspeicher zu recht kommst. Probeweise kannst Du Deiner Applikation weniger virtuellen Adreßraum zu weisen (das hat den Vorteil das Programm braucht nicht so viel RAM), so daß Du in der Lage bist Dein Programm auf Situationen anzupassen, in denen der Arbeitsspeicher knapp wird. Siehe Doku zum Shell Befehle ulimit bzw. die man pages zu den Funktionen getrlimit bzw. setrlimit.

ok, danke! und ein möglicher ansatz wäre evtl meine Objekte im worker thread speicher aus einer NSZone zu verwenden und dann die NSZone zum main thread zu pushen?

gruss
j.

Original von Tom9811
Die Größe erhältst du mittels sizeof( Klasse ).

sizeof() liefert bei mir wenn ich es auf ein dict oder ein array anwende leider immer 4 zurueck.
also .

was mache ich da falsch?

Dass da immer 4 zurückgegeben wird liegt einfach daran, dass das alles Pointer sind und ein Pointer hat auf 32-Bit Macs nunmal 4 Byte (= 32 Bit).

Original von Neum
Dass da immer 4 zurückgegeben wird liegt einfach daran, dass das alles Pointer sind und ein Pointer hat auf 32-Bit Macs nunmal 4 Byte (= 32 Bit).

hmm wie kann ich dann einfach rausfinden wieviel bytes ein array verbraucht? nur mit den performance tools ?

Es verbraucht in der Regel vier Bytes. Allerdings wird am Array eine weitere Struktur mit Kacheln hängen. Schau dir das mal in den Step-Sourcen an.

Aber es ist die Frage, ob du das überhaupt so machen willst. Ich mutmaße, dass nicht der gesamte Speicehrverbrauch das Problem ist, sondern die Anzahl der Allozierungen. Grob erinnere ich mich da auch an was im Singh.

Hier kann man daran denken, dass du dir selbst einen Pool baust, aus dem du den Speicher holst. Dazu musst du an +alloc ran. Und selbst dann ist es viel Arbeit, weil du ja nicht der einzige bist, der Speicher holt.

Ich würde mich daher erst einmal der Sache wirklich genau auf den Grund gehen.

Collections speichern keine Objekte. Daher wird es da auch nichts geben.

Die Zeiger werden bei Immutables sofort angelegt. Bei Mutables auf Vorrat. Hier kannst du auch einfach das Mutable dazu "zwingen" (es ist sanfter Druck), einen gewissen Vorrat anzulegen. Da geht es aber nur um Zeiger, also jeweils 4 Byte.

Original von Tom9811
Üblicherweise werden in Framework nicht bei jeder Speicheranforderung an das Framework auch gleich Speicheranforderungen an das System geschickt.

Wenn wir mal stillschweigend davon ausgehen, daß Objective-C malloc und die verwandten Funktionen nutzt(die Objective-C Runtime Library ist jedenfalls gegen diese Funktionen gelinkt), dann macht das Caching die malloc Implementation und nicht das Framework. Wenn man eine alloc Meldung verschickt wird immer auch malloc oder verwandte aufgerufen, die aber nicht notwendigerweise immer eine Speicheranforderung an den Kernel ergibt.

Ich weiß nicht, ob die Objective-C Runtime Library Teil von Apples Darwin ist, sonst könnte man einfach mal einen Blick in den Sourcencode werfen. strace oder valgrind wären jetzt hilfreich, kennt jemand ein MacOS X Äquivalent?