Freigeben von Listen durch Threads beschleunigen

[BUG]

Zitat:

Zitat von Blup (Beitrag 1291402)

Dafür könnten diese Methoden der Klasse TMoep überschieben werden:

Ah, also bietet Delphi da auch Schnittstellen an :thumb:

Zitat:

Zitat von Blup (Beitrag 1291402)

Benötigt wird eine globale Liste für verfügbare TMoep-Objekte.

Wenn du eine globale Liste hast, dann baust du dir vermutlich wieder einen Flaschenhals ein; möglicherweise selbst wenn du lockfreie Datenstrukturen verwenden solltest. Ein Pool pro Thread ist vermutlich günstiger.

Zitat:

Zitat von Daniel (Beitrag 1291407)

Ich werde das am Wochenende aus Interesse mal ausprobieren, wenngleich ich noch Zweifel habe, ob das der Wartbarkeit des Gesamtprojekts entgegenkommt.

Wo hast du da vorbehalte? Im Prinzip ändert sich an der Schnittstelle der Objekte nichts.

Wenn man wirklich ein Muster hat, in der man eine große Datenstruktur erzeugt, dann zerstört und wieder neu aufbaut, dann kann man mit mehr Aufwand noch einiges machen ... z.B. braucht man Objekte nicht einzeln freigeben, sondern verwendet einen Block einfach wieder. Dadurch das der dann wieder leer ist, sind selbst Allokationen supergünstig. Das hat dann natürlich mehr Einfluss auf die Wartbarkeit :mrgreen:

[Namenloser]

Du kannst ja mal ScaleMM ausprobieren. Skalierte zumindest in einem Projekt von mir deutlich besser als FastMM (letzterer skalierte genauer gesagt überhaupt nicht).

Aber ich frage mich, ob es überhaupt Sinn machen kann, das Freigeben durch mehrere Threads zu beschleunigen, da der Arbeitsspeicher der Flaschenhals sein sollte und nicht die CPU. Du kannst noch so viele Threads auf das Problem ansetzen, der Durchsatz des Arbeitsspeichers erhöht sich dadurch ja nicht. Selbst mit einem perfekt skalierenden Speichermanager wird da vermutlich kaum etwas rauszuholen sein, wenn überhaupt.

[himitsu]

Zitat:

Zitat von Namenloser (Beitrag 1291465)

Aber ich frage mich, ob es überhaupt Sinn machen kann,

Kommt drauf an ... theoretisch können mehrere Kerne gleichzeitig auf unterschiedliche Speicherseiten/-bänke/Riegel des RAM zugreifen.
Und dann spielt eventuell noch die eine oder andere Cache mit.

[Bernhard Geyer]

Zitat:

Zitat von Namenloser (Beitrag 1291465)

Du kannst ja mal ScaleMM ausprobieren. Skalierte zumindest in einem Projekt von mir deutlich besser als FastMM (letzterer skalierte genauer gesagt überhaupt nicht).

Oder mal nach "fastmm multithread" googlen. Es gibt einige Diskussionen über alternative Memory-Manager die im Multithread-Bereich viel besser skalieren (bzw. überhaupt skalieren). Auch mit schönen Graphiken wie sich FastMM, ScaleMM und Co. verhalten.

[Namenloser]

Zitat:

Zitat von himitsu (Beitrag 1291476)

Und dann spielt eventuell noch die eine oder andere Cache mit.

Bei quer über den Heap verstreuten Objekten sollte Cache aber eher keine Rolle spielen.

Zitat:

Zitat von himitsu (Beitrag 1291476)

Kommt drauf an ... theoretisch können mehrere Kerne gleichzeitig auf unterschiedliche Speicherseiten/-bänke/Riegel des RAM zugreifen.

Geht das? Ich hätte jetzt angenommen, das läuft alles über den gleichen „Bus“ oder wie auch immer (mit der Hardware kenn ich mich nicht so aus). Im Dual-/Triple-Channel-Mode ist der Speicher ja außerdem wohl eh so eine Art RAID-0.

[Daniel]

Die Datenmange kann es kaum sein.
Konkrete Zahlen aus meinem System / Testprojekt:

Das Abbauen der Liste dauert rund 300ms - für einen Rechner als eine durchaus nennenswerte Zeit. Der Taskmanager listet mir für die Anwendung einen Speicherverbrauch von 360 MBytes. Ich weiß, dass der Task-Manager nicht besonders präzise ist, aber für eine grobe Schätzung sollte der Wert langen. Selbst wenn sich das alles in einer VM abspielt, müsste doch mehr an Daten durch den Bus passen. Zudem wird doch gar nicht das komplette Speicher-Abbild durch den Bus gepresst, oder? Ich überschreibe die Bereiche ja nicht mit Nullen oder dgl.

[Namenloser]

Aber außer Speicherzugriffen dürfte doch kaum etwas passieren. Ich wüsste zumindest nicht was. Außer du machst irgendwelche komplizierten Dinge im Destruktor.

[Stevie]

Zitat:

Zitat von Daniel (Beitrag 1291363)

Mir dünkt, dass FastMM das Problem ist.

Das ist absolut richtig.

[jaenicke]

Ich habe gerade mal ScaleMM getestet. Der reserviert deutlich mehr RAM dabei, so dass es ein Out of Memory gibt und ist langsamer...
sapmm z.B. reserviert auch mehr, aber nicht so viel mehr, ist aber auch langsamer, insbesondere mit zwei Threads deutlich.

Ich bekomme so langsam das Gefühl, dass FastMM doch nicht so schlecht ist. ;-)

[himitsu]

FastMM hat von den kleineren Blöcken extra mehrere, so daß bis zu 3 Threads gleichzeitig RAM "bestellen" können,

aber beim Freigeben oder Ändern kann, je Gruppe, natürlich immer nur Einer gleichzeitig, wenn die Speicher zufällig im selben Block liegen.