FastMM grotten langsam ?!

[md_mse]

Hm, kaum zu glauben...

@Hagen: da musst du mir mal erklären warum RecyclerMM sowas nicht können sollte, die anderen jedoch schon ^^...
Naja und wie gesagt, bisher hat sich RecyclerMM bewährt, performance-technisch der schnellere zu sein!

[mschaefer]

Moin zusammen,

Habe die Probeweise gestern mal in ein größeres Projekt eingebunden. Im Projekt werden komplexe Formulare dynamisch erzeugt. Mit RecycleMM lief der Formularwechsel (dynamischer Abbau und Aufbau des nächsten Forms) sichtbar (!) schneller. Leider gab es auch Fehlermeldungen bei Programmende, sodass ich davon ausgehe, dass es da doch noch Pointerprobleme gibt.

Grüße // Martin

[negaH]

Zitat:

@Hagen: da musst du mir mal erklären warum RecyclerMM sowas nicht können sollte, die anderen jedoch schon ^^

Nö, die Anderen können es genauso wenig wie RecyclerMM, und ohne tiefe OS Tricks wirds auch keinen MM geben können der es kann, so einfach ist die Sache.

Ich versuch das Problam nochmal zu verdeutlichen:

Du schreibst eine DLL die RecyclerMM benutzt. Diese DLL exportiert Funktion XYZ und in dieser führst du umfangreiche Berchnungen druch die sehr viele Speicherblöcke alloziert und dealloziert.
Die DLL bindest du in einer neuen Anwendung ein und rufst nun die Funktion XYZ innerhalb eines Threads auf.

Was passiert nun in RecyclerMM == R und in einem normalen MM = N ?

1.) Thread wird erzeugt

2.) Funktion XYZ wird aufgerufen

3.) Speicher wird alloziert
- R alloziert viel mehr Speicher als nötig und erzeugt beim ersten Aufruf für diesen Thread einen komplett eigenständigen Memory Manager
- N hat schon einen MM für alle Threads und alloziert Speicher geschützt per RTL Critical Sections für alle Threda vom selben Pool

4.) Speicher wird freigeben und wieder neu alloziert
- R gibt niemals den freien Speicher zurück ans das OS, im WorstCase belegt also R immer mehr virtuellen aber real ungenutzen Speicher
- N ging gegebenfalls beim überschreiten gewisser Größen den Speicher mit VirtualFree() wieder an das OS zurück

5.) alle Speicherbereich in Funktion XYZ werden freigegeben da XYZ terminieren möchte
- R legt diese freien Speicherbereich in seinem Threadeigenen Pool ab, gibt sie aber nicht an das OS zurück
- N legt diese Speicherbereich in seinen gemeinsammen Pool ab, andere Threads könnensie wiederbenutzen oder beim überschreiten eines Thresholds gibt N sie mit VirtualFree() sofort an das OS zurück

6.) Funktion XYZ kehrt zurück, Prozess terminiert Thread
- R hat nun einen rießigen Block von Speicherleiche übrig gelassen da R nicht auf die Terminierung des Thread reagieren kann
- N hat ebenfalls ungenutzen virtuellen Speicherliegen, der aber durch andere Thread erneut benutzt werden kann und beim Beenden des Prozesses == entladen der DLL auch sauber per Vitual Free freigegeben werden kann.

Wiederholt man nun sehr schnell den Prozess des Threads erzeugen, Funktion XYZ ausführen und Thread zerstören so entstehen immer neuere Speicherleichen in R.

Man könnte nun argumentieren das die DLL in der R, N enthalten ist per Code Hooks auf die Beendigung eines Thread reagieren könnte. Ja das wäre möglich aber ist nur scheinbar eine Lösung. Denn bei eigenen Programmen geht dies noch zu machen aber nicht mehr bei zb. COM, ActiveX Servern. Dies können nicht ermitteln ob und wann ein Thread terminiert wird, dies geht einfach nicht da es auf API Ebene des OS keinen Signaling Mechanismus dafür gibt.

Ich möchte hier auch nicht weiter darüber diskutieren. Meine Emofehlung lautet RecyclerMM nicht zu benutzen. Der Author ist sich dieses Problemes sehr wohl bewusst da ich mit ihm darüber korrespondiert habe. Desweiteren wurde deises Problem ebenfalls in den Borland NewsGroup diskutiert. Zweitens ist dies schon wieder ein par Jahre her ! und es erfolgte keine Reaktion darauf indem man zumindestens im RecyclerMM darauf hinwies. Ich bin aber nicht für die korekte Funktion andere Sourcen verantwortlich.
Ergo: er ihn nutzen möhcte soll es tuen, sich aber dann nicht wundern wenn er Fehler bekommt die er nicht im mindestens einzuodrnen weis. Denn Fehler in einem Speichermanager führen zu fehlern die man so nicht debuggen geschweige denn einzuordnen weis. Man sucht dann wochenlang in seinen eigenen Sourcen ohne Erfolg.

Gruß Hagen

[edit]
PS: Ich habe keinen eigenen MM programmiert und verkaufe auch kein irgendwie geartetes Produkt in dieser Richtung. Soll heissen ich habe nicht das geringste Interesse RecyclerMM zu diskretitieren noch die Arbeit des Authors schlecht zu machen. Das einzisgte was ich mache ist euch zu warnen das mit RecyclerMM designtechnisch begründete Fehler auftreten müssen !
[/edit]

[negaH]

In der damaligen Diskussion in den NewsGroups stellten sich zwei mögliche Lösungen:

1.) RecyclerMM exportiert eine Funktion zb. DoneMM() die der Programmierung am Ende eines Threads aufzurufen hat.
2.) RecyclerMM exportiert eine Funjtion zb. CleanupMM() die der Programmierer periodisch aufzurufen hat oder aber innerhalb vom RecyclerMM() periodsich per Timer aufgerufen wird.

Nun analysieren wir das mal:

1.) falls wir einen COM/ActiveX Service oder eine DLL programmieren dann kann diese durch externe Prozesse aufgerufen werden die NICHT durch uns selber programiert wurden, sondern zb. in VB, C oder sonstwas. Ergo: DoneMM() kann und wird garnicht aufgerufen. Diese Lösung fehlt also ins Wasser.

2.) falls wir einen COM/ActiveX Service oder eine DLL programmieren dann kann diese durch externe Prozesse aufgerufen werden die NICHT durch uns selber programmiert wurden, sondern zb. in VB, C oder sonstwas Ergo: CleanupMM() wird nicht aufgerufen.
Selbst aber ein Timer basiertes Aufrufen von CleanupMM() muß scheitern da RecyclerMM innerhlab dieser Funktion garnicht unterscheiden kann ob ein Thread noch läuft, nur gestoppt wurde oder aber tatsächlich terminiert wurde. Man kann zwar per Trial&Error versuchen herauszubekommen ob ein Thread-Handle oder Thread-ID ungültig ist aber dies würde nur funktionieren wenn das OS dokumentiert sicherstellen würde das ein einmal benutzte Thread ID oder Thread Handle nicht mehr wiederbenutzt wird. Nun, Windows garantiert eine solche Vorgehensweise aber nicht !!

Ergo: es entstehen viel zu viele Unwägbarkeiten, bis hin zu "fehlerhaften" Benutzung des MMs durch uns selber. Ein guter MM muß aber in solchen Sachen wirklich Bullet Proof konstruiert sein. D.h. das Konzept muß so konstruiert werden das es keine Möglichkeit für eine "Fehlbenutzung" durch andere Programmierer kommen kann.

Übrigens, ich rede hier nicht von theoretischen Dingen, sondern aus selber gemachten Erfahrungen. Eine TCP/IP Service der per COM Schnittstelle aufgerufen werden konnte wurde mit RecyclerMM ausgestattet. Eben weil sehr viele, große und häugfige Speicheranforderungen stattfanden und ich mir vom RecyclerMM einen Performanceboost erhoffte. Dies war auch in den Tests wunderbar der Fall, mit einem Schönheitsfehler: Die Tests wurden auf Grund der äußeren Umstände immer nur so durchgeführt das nur eine TCP/IP Clientverbindung stattfinden konnte. Dieser Test simulierte also NUR die technische Funktionaliät aber NICHT die praxisnahe reale Auslastung mit 1000'enden Clients innerhlab von Sekunden. Als es dann soweit war, Abnahme war gemacht, Kunde hattte bezahlt und ging in den Echtbetrieb kackte der Server ständig schon teilweise nach Minuten komplett ab. So, die Suche konzentierte sich naturgemäß erstmal nur auf den Server, dessen TCP/IP Konfigurationen, auf die Router, neueste Patches etc. pp. Dies verschlang Wochen da es sehr schwer nachvollziehbar war und die Clientlast sich sehr unregelmäßig verteilte. Erst nachdem ich eine zusätzliche Anwendung programmierte die 1000'ende Clients simulierte konnten wir das Problem eingrenzen. Natürlich kam ich nicht sofort auf die Idee den fucking RecyclerMM zu deaktievieren sondern ging stur von einem Fehler in meinen Sourcen und später in Indy's Sourcen aus. Naja, nach 6 Wochen schmiß ich RecyclerMM auf Grund eines systematischen Vorgehens, also Routine, verdchatsweise raus. Danach ging alles wie gehabt. Also nochmal 1 Woche programmiert um alle Sourcen wieder auf ihren Auslieferungszustand zu versetzenund schlußendlich habe ich länger daran gesessen diesen Fehler zu entfernen als das eigentlichen Projekt zu seiner Fertigstellung an Zeit erfodert hatte !! Die Entwicklungszeit verlängerte sich also von 5 Wochen auf +7 Wochen. Meine finanzielle Kalkulation war fürn Popo.

Gruß Hagen

[negaH]

So nun konzepionell:

Es gibt mehrere Wege einen MM zu "optimieren".

1.) man alloziert ständig mehr Speicher auf Verdacht um im eventuell späteren Falle einer Reallokation sofort diese Anforderung erfüllen zu können.
2.) man ändert die Strategie der Verwaltung der freien Speicherblöcke um später dann gezileter und schneller eine Speicheranforderung erfüllen zu können.
3.) man optimiert den Sourcecode indem man schneller Assemblerfunktionen benutzt.

Nur Punkt 2.) ist eine echte Altrnative und in FastMM4 auch das primäre Optimierungsziel gewesen. Nur 2.) optimiert den Algorithmus ansich und bietet somit das meiste Potential.

Punkt 3.) kann nur ein Fein-Tuning darstellen.

Punkt 1.) ist eher gefährlich als nützlich. Aber gerade Punkt 1.) wird bei den meisten sogannenten "besseren" MM's benutzt. Was ist daran aber so gefährlich ?

Ok, RecyclerMM: dieser übertreibst mit Punkt 1.) und im WorstCase betrachtet bedeutet dies: Allozieren für jede Speicheranforderung immer wieder komplett neuen Speicher. Bei der Deallokation dieser Speicher spare die komplette Zeit ein indem du diesen Speicher garnicht mehr freigibst !!! Man kann sich nun leicht ausrechnen was passieren muß.

Aber exakt so geht RecyclerMM vor. Ok, er optimiert indem er übergroße Speicherblöcke alloziert, quasi die Speicheranforderung höher auslegt als benötigt. Die Wahrscheinlichkeit diese preallozierten Überhangs im vergleich zu dann tatsächlichen Auslastung wird immer schlechter je größer dieser Überhang ist.

Jetzt stellen wir uns mal vor ALLE Programme würden solche MMs benutzen !? Dann würden nur 3 Prozesse immer mehr an Speicher verbrauchen diesen aber eben nicht effektiv nutzen.

Ergo: ein guter Speichermanager wird nicht nur schnell Speicher allozieren können, nein, viel wichtiger ist es das er auch diesen Speicher immer wieder auch an das OS freigibt wenn er nicht mehr benötigt wird. Denn nur so eine Strategie kann dazu führen das nicht die eigenen Anwendung nur deshalb schneller wird weil sie den anderen Anwendungen den Speicher wegnimmt/blockiert.

Schaut man sich FastMM4 genauer an so erkennt man wodurch er ca. 2 mal schneller als der Borland MM wird.
1.) viele Sourcen nutzen Assembler bzw. sind besser durch den Compiler optimierbar. Ein Umschreiben des Borland MMs nach dieser Taktik wird den Borland MM auch ca. 50-60% beschleunigen können.
2.) der Rest des Performancegewinnes liegt darin begründet das die Granulatät des FastMM4 höher ist als die ses Borland MMs. D.h. FastMM4 kann viel exakter entscheiden und geordeneter auf spezifische Speicheranforderungen reagieren als der BorlandMM. FastMM4 benutzt quasi ein leicht optimaleren Algorithmus.

Gruß Hagen

[negaH]

Was ist die effizientest Alternative aus unserer Sicht ?

1.) Optimierung an der Stelle wo der meiste Gewinn zu erwarten ist, in den eigenen Algorithmen.
2.) Vermeidung quasi Vorbeugung. D.h. man versucht die Aufrufe an den MM von Anfang an zu reduzieren.

Gerade im LongString-Bereich kann man da einiges verbesseren. Statt also LongString weiderholt additiv zusammenzubauen -> R := R + S; wird ein langer möglichst in seiner LÄnge exakt vorausberechneter String prealloziert und dann durch einfach Kopierungen zusammengebaut. In den meisten Fälle optimiert man damit nicht nur EIN Problem sondern gleich MEHERE auf einmal. Dementsprechen sieht der Performancgewinn im Nachinein auch aus. Nicht nur 50% schneller sondern bis zu 500-1000% schneller kann so eine Funktion werden. Diese Ratio ist einfach nicht mit einem besseren MM erraichbar, das geht einfach nicht.

Eine weitere Optimierung ist das informelle Wissen. D.h. man weis das spezielle gleichgroße Datenstrukturen im Programm benutzt werden und optimiert indem man deren dynamische Speicheranforderungen in statisch und preallozierte und postdeallozierte Speicheraufrufe umwandelt. Man baut quasi einen Cache nur für diese speziellen Datenstrukturen. Auch dies kann die Performance weit mehr als nur 30-50% erhöhen, öfters wird man weit mehr als 500%-1000% Steigerungen erreichen können !

Woran liegt das ?
Einerseits darin das man wesentlich schneller solche preallozioerten gelichgroßen Blöcke allozieren und freigeben kann. Aber auch andererseits weil man so definitiv 0% Fragmentierungen der Speicherblöcke erreichen kann. Und diese Fragmentierung des Speichers ist das as jeden MM zu schaffen machen wird.

Gruß Hagen

[himitsu]

Zu Hagen's Beitrag #13:
Bei RecyclerMM kann ich bestätigen, daß dieser mit verschiedenen Modulen (DLLs und Co.) nicht klar kommt.

Für FastMM trift dieser aber auch nur bedingt zu, denn dort muß die entsprechende Funktionalität erst aktiviert werden und selbt dann steht dieses nicht volltändig zur Verfügung, denn die Memory-Funktionen sind nicht vollständig für SharedMemory ausgelegt.
GetMem, FreeMem und ReallocMem können zwar vollständig für alle Threads/Module freigegeben werden, aber bei den Zusatzfunktionen wie z.B. für den UsageTracker sieht es anders aus, denn diese greifen nur auf den in ihrem Bereich liegenden MM zu, selbst wenn es nicht der global initialisierte MM ist, was zu netten Problemen führen kann/wird.

Mein MM ist da schon konsequenter und gibt alle nötigen Funktionen global frei.
Also jeder FastXMM schaut immer erstmal nach, ob es im Programm schon irgendwo einen weiteren FastXMM gibt und übergibt dann die kontrolle an diesen.
Ich muß allerdings zugeben, daß ich aber auch noch nicht zu 100% konsequent bin, denn es gibt "noch" ein kleines Problem, was aber extrem selten auftritt.
Also wenn z.B. in mehreren dynamisch geladenen Moduelen (DLLs...) der FastXMM enthalten ist und zusätzlich aber keiner in einem statisch geladenen Modul, oder im Hauptmodul (EXE), dann wird es zu Problemen kommen, sobald nicht das zuerst geladene Modul auch als letztes freigegeben wird. (bei den anderen ist die Reihenfolge egal)
Allerdings haben dieses Problem auch alle anderen Memory Manager, welche ich bisher gesehn hab und dazu kommt noch, daß dieses Problemchen in der nächsten Generation meinen FastXMM behoben wird.



Solche CleanUp-Funktionen (Beitrag #14) wären aber auch nicht nötig, wenn die Programmierer, so wie es auch eigentlich der Fall sein sollte, beim Beenden der verschiedenen Teile darauf achten würden, daß auch wirklich alles Nötige freigegeben wird, daher ist in Fast(X)MM derartiges erst garnicht implementiert. ^^
Es wird "nur" beim Programmende (sobald FastXMM freigegeben wird) geprüft, ob noch irgendwas allociert ist, welches ja eigentlich nicht de Fall sein dürfte, wenn alles ordnungsgemäß freigegeben wurde.



Und was nochmal den Speichermehrverbrauch bei Fast(X)MM angeht, so ist dieser beim Aufruf von GetMem/FreeMem nicht wesentlich anders, als bei BorlandMM.
Nur beim ReallocMem wird entweder nicht sofort, oder im vollständigen Maße verkleinert, ebenso wird beim Vergrößern halt etwas mehr gemacht, da hierbei für einen zukünftigen Aufruf von ReallocMem vorgesorgt wird. Und wenn man sich dazu noch den Benchmark (Anzahl der Aufrufe der einzelnen Memory-Funktionen) ansieht, dann wird deutlich, daß der größte Teil an Aufrufen nicht beim ReallocMem liegt, wodurch also viel öfters passend Allociert wird, und somit meißtens "kein" Mehrverbrauch zu erwarten ist.



Und wie Hagen schon sagte kann man nicht für alles den MM verantwortlich machen, denn man hat auf vieles selber Einfluß und kann selber an vielen Stellen verbesserungen innerhalb der eigenen Codes hervorrufen.

Und was die Fragmentierung anmgeht, so scheint BorlandMM wohl ganz schöne Probleme zu haben, welche bei anderen nicht so stark auftreten.



PS: @Hagen
In deinem letzten Beitrag (#16) sagtest du was von 'ner Art Cache ... was meinst du, wenn man etwas derartiges direkt in den MM mit einbauen könnte ... also z.B. spezielle GetMem/FreeMem, welche auf einen Cache mit vorher festgelegen Blockgrößen zugreift?


[add]
Manchmal ist man auch sowas von Blind
eine entsprechende Funktionalität für einen benutzerdefinierten Cachebereich existiert ja schon und wird fleißig für alle Speicherblöcke bis 2 KB - 4 Byte verwendet.

Im grunde genommen brauchte ich ja nur dieses erweitern und lediglich eine Procedur zum Initialisieren der einzelnen Cacheguppen erstellen.
Und könnte dann alles über die Standardfunktionen (GetMem/FreeMem) laufen lassen ... wobei ich dann dort wohl lieber noch Konstanten für den schnelleren Zugriff auf eine bestimme Cachegruppe einführen, welche dann statt der gewünschten Blockgröße (Size) angegeben wird ... wäre ja nicht gerade effektiv immer erst nachzusehen ob eine gewünschte Größe (Size) zufällig in einem der Cacheblöcke vorhanden ist

Also, wenn jemand sowas gebrauchen könnte/würde, dann bitte melden ... man muß sich ja nicht mehr Arbeit machen, also unbedingt nötig -.-''

[negaH]

Hm, die Idee solche "Caches" in den MM auszulagern halt ich für Zeitverschwendung.

1.) Die Art & Weise, also welchen Typus "Cache" man benutzen wird hängt sehr stark von der Aufgabe und sogar von späteren Tests ab. So gibt es zb. alleine bei der Art&Weise wie der Cache befüllt wird Unterschiede. Zb. LIFO oder FIFO Caches, random Access Caches etc. pp.

2.) Die Größe und Anforderungen an den Cache hängen von den Datenmengen ab. Ein Cache der mit minimalem Aufwand zb. 1024 Datenelemente verwalten kann wird bei 1024*1024 anderen Datenelementen eventuell viel inperformanter sein als eine andere "Cache" Struktur.

Ich meine also das der Programmierer eines MM's nicht hellsehen und schon garnicht es allen möglichen zukünftigen Anforderungen recht machen kann.

In meinen IIntegers wird dieser sogenannte Pool = Cache als FIFO mit konfigurierbarer Tiefe ausgelegt. Zuerst hatte ich einen LIFO=Stack benutzt und musste dann aber feststellen das kontrahär zum eigenen Gefühl der FIFO wesentlich effizienter war.

Interessant an der Sache war der Punkt der dynamisch einstellbaren FIFO Speichertiefe. Diese ermöglichte nämlich später in den Performancetests mit sehr sehr unterschiedlichen mathematischen Formeln, aber immer der gleichen underlaying Math Library, einige statistische Gegenüberstellungen durchzuführen.

Obwohl nun die math. Library identisch ist, und in vielen Bereichen sogar vergleichbar und in der Anzahl ähnliche math. Funktinen benutzt wurden, gab es bei all dieses Algorithmen sehr unterschiedliche FIFO Speichertiefen die zur maximalen Performance führten. Es war sogar meisten so das gleich mehrer unterschiedliche Speichertiefe maximale Performance lieferten. D.h. die Performancekurve relativ zur gewählten Speichertiefe war niemals linear noch stetig. Der Glaube "viel hilft viel" wurde eindeutig wiederlegt.

Soll heissen: Obwohl die Aufgaben für diesen "Speichermanager" sehr sehr ähnlich waren gab es keine FIFO Speichertiefe die bei allen Aufgaben immer ein optimales Ergebnis lieferte. Genau der gleichen Situation sehen sich Programierer eines allgemeingültigen MMs gegenübergestellt. Da aber die Menge aller möglichen Algorithmen unendlich groß ist wird es niemals DEN Speichermamanger geben können.

Gruß Hagen

[negaH]

Das einzigste was mich an der Entwicklung eines eigenen MMs reizen würde ist folgender Gedanke:

Oben beschrieb ich ja schon das es niemals einen MM-Algorithmus geben kann der durchschnittlich allen möglichen Anforderungen gerecht werden kann. Diese Aussage stimmt nur bedingt wenn man sich vom Konzept eines "statischen" MMs verabschiedet. Das Konzept eines "dynamischen" MMs wäre es nun die Anforderungen an den MM selber statistisch zu analysieren und darauf hin seine Taktiken dynamsich anzupassen. Sogesehen würde ich einen solchen MM als strategisch intelligent bezeichnen. Die Challange dabei wäre es einerseits einen celveren Algo. zu entwicklen und andererseits die zusätzlich nötige statistische Auswertung und Speicherverbrauch optimiert hinzubekommen.

Gruß Hagen

[mschaefer]

Moin, Spätmoin,

also Hagen, bei Deinem Monolog habe ich doch andächtig gelauscht und kann dem doch widerstehen einen Speichermanager selbst zu programmieren, auch wenn ich vor Optimierungsalgorrihtmen nicht wirklich zurückschrecke. Zudem ist mir beim Test doch aufgefallen, dass mehr Speicher Geschwindigkeit bringt, auch mit einem Teil der Folgen, die Du beschrieben hast.

1.) Wäre es überhaupt denkbar einen Speichermanager so anzupassen, dass er bei Com und OLE Objekten keinen größeren Speicherbereich anfordert, also nur auf normale Objekte mit seiner Optimierung reagiert.

2.) Endet das letztlich in einer Art zeitgesteuerten Garbage-Collection. Dein Speichermanager müßte ja in den Idle-Zeiten genauer Untersuchen welche Speicherlücken er noch freigeben kann.

3.) Ist das nicht eher die Aufgabe eines Programm unabhängigen Dienstes?


Viele Grüße // Martin