Zitat von Daniel:

Mir dünkt, dass FastMM das Problem ist.

Das ist absolut richtig.

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.

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.

Zitat von himitsu:

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

Das ist das Schöne an einer Lösung, wo man für eine konkrete Klasse noch einen Pool dazwischenschalten kann: Ich kann jedes Objekt in jeden Pool stecken, praktisch also auch ganz schnell in meinen Thread-lokalen.

Zitat von BUG:

Zitat von himitsu:

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

Das ist das Schöne an einer Lösung, wo man für eine konkrete Klasse noch einen Pool dazwischenschalten kann: Ich kann jedes Objekt in jeden Pool stecken, praktisch also auch ganz schnell in meinen Thread-lokalen.

Das würde Daniel aber auch nix helfen, die Instanzen gibts schon, die dann noch irgendwo in nem Pool zu verschieben, würde die Sache kaum schneller machen.

Es gibt gewisse Dinge, die kann man ebend nicht mit multithreading schneller machen (manchmal geht das sogar eher nach hinten los).
ScaleMM und Co mögen schneller sein, wenn man innerhalb mehrerer Threads Instanzen erzeugt und wieder freigibt oder mit strings hantiert (siehe Benchmarks) . Aber einmal erstellte Instanzen parallel freigeben, geht auch dort nicht schneller (eher langsamer wie auch meine Tests bestätigen).

Ich hab' mich jetzt eh an anderer Stelle im Projekt verfuddelt. Da hilft alles nix mehr.

Threads 1..4 bauen die Datenstruktur auf, Threads 5 und 6 solchen selbige durchsuchen, wenn die ersten vier Threads fertig sind. In der Theorie simpel, in der Praxis ein Deadlock. Ich glaub' das geht grundsätzlich nicht. *g*

Zitat von Daniel:

Ich hab' mich jetzt eh an anderer Stelle im Projekt verfuddelt. Da hilft alles nix mehr.

Threads 1..4 bauen die Datenstruktur auf, Threads 5 und 6 solchen selbige durchsuchen, wenn die ersten vier Threads fertig sind. In der Theorie simpel, in der Praxis ein Deadlock. Ich glaub' das geht grundsätzlich nicht. *g*

Ach was, alles ganz einfach mit der PPL!
Wo genau lockts denn? Grundsätzlich sollten ja für den start von Task 5 und 6 die ersten 4 fertig sind. Also können nur entweder die ersten 4 sich gegenseitig locken oder 5 und 6.

Zitat von Stevie:

Das würde Daniel aber auch nix helfen, die Instanzen gibts schon, die dann noch irgendwo in nem Pool zu verschieben, würde die Sache kaum schneller machen.

Die Datenstruktur wird wiederholt freigegeben und wieder neu aufgebaut. Wenn man bei der Freigabe, anstelle sich um ein Lock zu kloppen, die Instanz lokal merken kann, könnte das schon was bringen.

Zitat von Daniel:

Threads 1..4 bauen die Datenstruktur auf, Threads 5 und 6 solchen selbige durchsuchen, wenn die ersten vier Threads fertig sind.

Ein großer Baum, der öfter mal neu erstellt wird und ansonsten von 2 Threads durchsucht wird ... klingt nach einer spannenden Anwendung

@Daniel

Du brauchst dazu 7 Threads

Thread 1

• Startet 4 Holt-mal-Daten Threads und wartet bis die fertig sind
• Fasst die Ergebnislisten zusammen / teilt die Ergebnisse für die Such-Threads auf
• Startet 2 Sucht-mal-Daten Threads und wartet bis die fertig sind
• Beendet sich (oder legt sich schlafen)

Macht in Summe 7 Threads und du brauchst somit (aus der Sicht der Anwendung) nur mit einem Thread jonglieren.