Dynarray Implementation

camper

Hat jemand mal demonstriert, dass ein alloca-basiertes Array signifikant schneller ist als z.B. ein Array basierend auf einem thread-lokalen Pool (im Prinzip ist der Stack ja nichts anderes)?

ungefähr so (ungestest, wahrscheinlich auch nicht ganz korrekt)

struct tl_pool
{
    thread_local unique_ptr<char[]> pool;
    thread_local char* pool_ptr;

    static const std::size_t align = 8;
};

thread_local unique_ptr<char[]> tl_pool::pool(new char[1024*1024]);
thread_local char* tl_pool::pool_ptr = pool;

template <typename T>
struct tl_pool_alloc
{
    typedef T value_type;

    T* allocate(std:size_t n)
    {
        T* result = reinterpret_cast<T*>(pool_ptr);
        pool_ptr += ( n * sizeof(T) + ( align - 1 ) ) / align * align;
        return result;
    }

    void deallocate(T* p, std:size_t)
    {
        pool_ptr = p;
    }
};

Shade Of Mine

krümelkacker schrieb:

Die Stack-Optimierung könnte so aussehen, dass der dynarray-Klasse noch einen besonderern, privaten Konstruktor bekommt, der dann ggf automatisch aufgerufen wird und worüber der allozierte Stack-Speicher empfangen werden kann.

Wieso nicht über den allocator gehen? Dazu sind die ja da.

Aber Stack allokation ist tricky, weil du nicht mehr moven kannst, da wenn du selber out of scope gehst, ja auch dein Speicher out of scope geht...

Hier bräuchte man halt intelligente allocatoren - was die C++ allocatoren leider nicht sind.

@camper:
alloca ist einfach zu gefährlich um relevant verwendet werden zu können. insofern würde ich in 99% aller Situationen einen thread local pool bevorzugen.

hustbaer

krümelkacker schrieb:

Im ursprünglichen Proposal steht auch nichts von Allokatoren oder Move-Operationen. Die Stack-Allokation wäre dann QoI/Compiler-Magie. Und ich würde das wahrscheinlich auch so basteln, dass, falls der Stack schon "recht voll" ist oder die geforderte Größe eine gewisse Grenze überschreitet, trotzdem auf den Freispeicher ausgewichen wird.

Siehe mein Beitrag auf Seite 5 (der im übrigen komplett ignoriert wurde).

hustbaer

camper schrieb:

Hat jemand mal demonstriert, dass ein alloca-basiertes Array signifikant schneller ist als z.B. ein Array basierend auf einem thread-lokalen Pool (im Prinzip ist der Stack ja nichts anderes)?

Die Geschwindigkeit hab ich noch nicht verglichen - könnte man ruhig mal machen.
Aber was ist mit dem Grundsätlichen Problem eines solchen Allocators: man muss verdammt aufpassen dass man damit keinen Mist baut.
Speziell wenn der Container dann noch so "gefährliche" Funktionen wie move anbietet.