Speicherallokierung (mit new) paralellisieren

hustbaer

dgrat__ schrieb:

Bei 1,5 Mio aufrufen teilweise 5 Minuten.

Das ist viel zu lange.

Nur als Beispiel: auf nem Core2 Duo mit 2,13 GHz, Windows XP 32 Bit schafft man so 3~10 Mio. Allocations + Deallocations pro Sekunde.

Dein Problem liegt vermutlich woanders.

BTW: Visual Studio aktiviert die Debug-Funktionen des Heaps, d.h. du musst zwei Dinge tun wenn du ne realistische Geschwindigkeit messen willst:

Release Version compilieren
UND
Ausserhalb von Visual Studio laufen lassen

Dann werde ich demnächst wohl nochmal den code-teil durchgehen und schauen woran das problem liegt.

cooky451 schrieb:

Also sowohl new als auch malloc sollten problemlos aus mehreren Threads gleichzeitig aufgerufen werden können. Aber warum nutzt du OpenMP statt std::thread? (Und warum allokierst du nicht in Blöcken? Das scheint mir am sinnvollsten.)

OpenMP und std::threads sind zwei völlig verschiedene Sachen. Threads startet man für nebenläufige Prozesse und OpenMp um Schleifen aufzurollen um EINEN Prozess mit voller LEistung zu berechnen.

SeppJ

dgrat__ schrieb:

OpenMP und std::threads sind zwei völlig verschiedene Sachen. Threads startet man für nebenläufige Prozesse und OpenMp um Schleifen aufzurollen um EINEN Prozess mit voller LEistung zu berechnen.

Ach! Und wo ist der Unterschied?

Dann werde ich demnächst wohl nochmal den code-teil durchgehen und schauen woran das problem liegt.

Deine Beschreibung klingt sehr ... manuell. Du machst das nicht von Hand, oder? Fuer solche Probleme wurden Profiler erfunden.

Alter,
Vergleich einfach mal den Overhead, wenn du ne Schleife mit std::thread aufrollst.
Die Technik funktioniert bei beiden ansätzen auf völlig verschiendene Art und Weise.
Schreib mal ein Programm was bspw. eine Vektoraddition vornimmt und addiere zweil mal bspw. 32 mio Einträge.
Mit std::threads darfst du dann erstmal die Aufteilung der Berechnung selber festlegen und zu erzeugst für das OS völlig unnötige threads + overhead und hast am ende wahrscheinlich auch eine langsamere berechnung, als auf einem Kern.
std::thread ist NUR für nebenläufigkeit gedacht.
Aber das nur am Rande. Ich war mir nicht sicher, ob man parallel Allokieren kann.
Mal davon abgesehen, dass std::threads für diesen Zweck in der Tat evtl eine Überlegung wert wäre.

cooky451

dgrat__ schrieb:

Alter,

Du willst mir erzählen [Prozessorkernzahl] Threads zu erstellen dauert dir zu lange? Autsch.

Aber wenn du Speed bei der Vektoraddition brauchst, machs doch einfach auf der Grafikkarte. Dagegen wird nichts ankommen. (Und wenn du VS11 hast kannst du auch gleich concurrency::parallel_for_each austesten, am besten gleich noch mit restrict(amp).)

Aber wie schon gesagt: Speicherverwaltung dauert zu lange? Was hast du gegen Speicherblöcke? Und warum dauert das so lange bei dir? (s. hustbaers Beitrag.)

erstens benutz ich schon die graka (cuda), was super ist und zweitens ist der aufwand mit std::threads um ein vielfaches größer. mit openmp reicht eine direktive und mit sthreads muss man ne ganze funktion schreiben, die einem die daten zusammenfasst. das ganze ist darüber hinaus auch noch langsamer.
ich kann dir bei sowas nur davon abraten.

cooky451

Wenn du meine Fragen nicht beantworten willst, dann halt nicht.

dgrat__ schrieb:

mit openmp reicht eine direktive und mit sthreads muss man ne ganze funktion schreiben, die einem die daten zusammenfasst.

Mag ja alles sein. Aber du hast in deinem ersten Post OpenMP im Zusammenhang mit Allokation gebracht, was den Schluss nahe legt, du wolltest dir einen Allokator unter Zuhilfenahme von OpenMP schreiben. Und das ist Quatsch.
OpenMP hat sicher seine Vorteile, darüber ist sich auch cooky im Klaren. Diese Nebendiskussion geht aber voll am Thema vorbei.

BTW.:

dgrat__ schrieb:

Threads startet man für nebenläufige Prozesse und OpenMp um Schleifen aufzurollen um EINEN Prozess mit voller LEistung zu berechnen.

Ist dir eigentlich klar, was an dieser Auffassung falsch ist? Threads laufen auch innerhalb eines Prozesses, genauso wie OpenMP. Und was heißt eigentlich "Prozess mit voller LEistung zu berechnen"? Deine Formulierungen sind komisch und regen zur Falschdeutung an...

hustbaer

@dgrat__
Zeig mal deine OpenMP Schleife her, vielleicht liegt das Problem ja genau da begraben dass du OpenMP doch nicht so gut verstanden hast wie du meinst. Man kann nämlich mit OpenMP auch ganz leicht Code schreiben der langsamer läuft als ohne Parallelisierung.
Ist nämlich nicht so dass die ganzen Synchronisierungs-Konstrukte auf einmal gratis sind, nur weil sie durch OpenMP Code erzeugt werden.

Und achte mal etwas auf deinen Ton.

Hmm, habe das Problem gefunden.
Ich hatte push_back() in einer Funktion aufgerufen und das nachfolgende Neuskalieren von std::vector verträgt sich natürlich nicht gut mit OpenMP.
Ich nehme an, dass das auch für die langsame Ausführungsgeschwindigkeit verantwortlich ist.