🚀 go-pugleaf

Dnia 2007-11-10, Piotr Wyderski napisał:
> Łukasz Krotowski wrote:
>
>> // gdzieś, lokalnie w kodzie
>> memory_pool local_pool(LOCAL_POOL_SIZE);
>> do_not_deallocate_allocator::set_pool(local_pool);
>
> A skąd sobie weźmiesz adres puli w miejscu użycia?
> Będzie globalna, czy będziesz przepychał to jako parametr?
> Bo pierwsze rozwiązanie padnie w kodzie wielowątkowym,
> a drugie będzie "wydajne inaczej".

Globalna. W przypadku wątków w TLS. Dla uproszczenia możemy założyć, że
alokator wielowątkowy można zastąpić wieloma instancjami alokatora
jednowątkowego w TLS.

>> W takim przypadku alokacja będzie porównywalna ze stosową
>
> OK.
>
>> a dealokacja szybsza.
>
> Nie widzę żadnego powodu, by była szybsza. Dealokacja stosowa
> składa się z _jednej_ instrukcji: addl, $size, %esp. Kompilator może
> zgrupować takie zwolnienia w jedno add, sumując ich rozmiary
> i z prawdopodobieństwem graniczącym z pewnością to zrobi, bo
> taka optymalizacja jest trywialna. Jak się mocno postarasz
> i będziesz miał szczęście, to dogonisz wydajność dealokacji
> stosowej, ale "you've got to ask yourself a question: Do I feel
> lucky? Well, do ya punk?" ;-)))

Hmm, jak pewnie się domyśliłeś dealokacja w do_not_deallocate_allocator
składa się z zera instrukcji. A powyższej optymalizacji opowiada jedno
wywołanie local_pool.release(). Czyli, jeśli kompilator nie
zoptymalizuje dobrze albo przeciągnę sobie życie local_pool przez więcej
niż jedno wywołanie funkcji to będę szybszy. (*)

>> Oczywiście długość życia obiektów ma znaczenie
>
> Jak najbardziej, ale akurat nie w tym rozwiązaniu,
> które z Sewerynem próbujecie mi sprzedać. :-)

Alokatory, alokatory! Trzy pięćdziesiąt za mendel!
BP, NMSP.


(*) Przekomarzanie się o kilka instrukcji. Ech, słodkie, sobotnie
dyskusje usnetowe. ;)

-- 
Łukasz Krotowski | lukasz.krotowski_AT_gmail.com