4. Multithreading-tauglicher Allocator für Tru64/OSF1 5.1b

Multithreading-tauglicher Allocator für Tru64/OSF1 5.1b

  • 7

    Hallo zusammen,

    ich suche einen multithread-tauglichen Allocator für Tru64. Momentan besteht das Problem, dass eine normale Singlethread-Anwendung wenn sie mit Multithread-Support kompiliert wird einen Performance-Einbruch von bis zu 50% hat. Das passiert unabhängig vom Compiler (gcc3.4.5, gcc4.0.3, kcc4.0f).

    Profiling hat gezeigt, dass das Problem im new/malloc begraben liegt. Unter SunOS 5.8 hatte ich das selbe Problem - allerdings kann man dort wenn man libmtmalloc dazu linkt, eine multithread-fähige Speicherverwaltung bekommen (Sun bezeichnet das normale malloc für Multithread-Anwendungen selbst als "unsuitable"), die u.a. auch versucht false-sharing zu vermeiden.

    Leider habe ich bis jetzt kein Pendant für Tru64 gefunden. In malloc(3) stehen ein paar mystische Variablen um das Verhalten von malloc zu verbessern, ein wirklicher Performance-Knaller ist das aber nicht (immernoch abfallende Leistung mit zunehmender Anzahl Threads).

    Hat jemand Erfahrungen in diesem Bereich oder ein paar Tipps parat? Eine Allocator-Bibliothek sollte übrigens zulassen, dass sie auch kommerziell verwendet werden darf, ohne das Programm unter die GPL zu zwingen.

    Vielen Dank im Voraus! 🙂

    0
  • R

    http://goog-perftools.sourceforge.net/ weiß nur nicht ob der mit Tru64 funktioniert.

    0
  • 7

    Danke. Leider funktioniert das ganze nur auf i386 bzw x64. Wir haben hier allerdings eine DEC Alpha Maschine mit (ich muss lügen) EV5 Prozessoren. 😞

    0
  • R

    hmm, vielleicht kannst du den Allocator aus der dietlibc oä nehmen. Der sollte zumindest für Alpha funktionieren und eigentlich portabel sein.

    (btw. bist du sicher, dass die Google-Perf-Tools nur auf x86 funktionieren?)

    0
  • 7

    Ja, ich habe versucht die Google-Perf-Tools zu bauen, darauf hin stößt man sofort auf einen Build-Fehler. Im entsprechenden Header gibt's ifdefs für x86 und x86-64 und eine Error-Direktive für den Rest. Das brutale Ändern der ifdefs kompiliert dann leider auch nicht, zumal ich dann vermutlich an den gcc gebunden wäre, wir allerdings produktiv KAI C++ einsetzen. Mit der libunwind würde ich vielleicht noch weiterkommen, aber die gibt es auch nicht für Alpha.

    Die dietlibc kommt leider nicht in Frage, da sie unter der GPL steht. 😞 Da die Entwicklung nunmal kommerziell ist. Da kann ich nichts machen. (dafür muss es aber auch nicht unbedingt OpenSource/Freeware sein und kann auch was kosten) Für den Hoard-Allocator, der ja einen recht guten Ruf hat, gibt's leider auch keinen Tru64-Port.

    0
Anmelden zum Antworten