🚀 go-pugleaf

Witam

Piotr Wyderski wrote:

>> Nie widzę żadnej synchronizacji.
> 
> No ja się nie dziwię, że _nie widzisz_, bo jest ona ukryta w przeciążonym
> operatorze =() środkowej instrukcji, operującej na klasie
> detail::shared_count:

OK. Rozumiem.

To jeszcze poproszę o jedno wyjaśnienie. Taki kod.

#include <boost/shared_ptr.hpp>

int main()
{
    ::boost::shared_ptr<int> p (new int(8));
    ::boost::shared_ptr<int> q (new int(9));

    p = q;

    return *p;
}

No i nic poza tym poniżej nie mam w kodzie.

.globl main
        .type   main, @function
main:
.LFB829:
        leal    4(%esp), %ecx
.LCFI0:
        andl    $-16, %esp
        pushl   -4(%ecx)
.LCFI1:
        xorl    %eax, %eax
        pushl   %ebp
.LCFI2:
        movl    %esp, %ebp
.LCFI3:
        pushl   %ecx
.LCFI4:
        popl    %ecx
        popl    %ebp
        leal    -4(%ecx), %esp
        ret
.LFE829:
        .size   main, .-main

Proszę o korepetycje z asemblera :-D.
 
> Zdradliwy języczek, co? :-)))

Hmm... czy ja wiem, dobrze działa przeładowanie w sumie to lubię kiedy tak
jest.
 
>> Hmm... no to spełnia się moja teoria użyteczności Flame.
> 
> :-)

Na pewno się spełnia.
 
> Mnie też się ona podoba. Wspominałeś coś ostatnio o teoretycznych
> podstawach dobierania optymalnego predyktora do rozkładu danych,
> chetnie bym się z tym bliżej zapoznał.

A co dokładnie chcesz wiedzieć? Do takich predykcji w wersji nadającej się
do HPC stosowałbym dwa podejścia.

Off-line. Polega na tym, że znasz swój soft i wiesz z jakim rozkładem (znasz
funkcję, nie znasz parametrów) są wołane "\Delta resize". Dla określonego
rozkładu istnieją optymalne estymatory średniej i wariancji -- IMHO
obliczenia estymatorów metodą największej wiarygodności są łatwe i szybkie
do uzyskania (na papierze) i są dobre. 

Tak jak wspomniałem np. dla rozkładu lognormal średnia harmoniczna najlepiej
oddaje faktyczną średnią, średnia arytmetyczna popełnia błędy. Jeszcze
gorzej jest z wariancją. Np. rozkład log-normal to jest rozkład, który
wygląda tak, że zlogarytmowane wartości mają rozkład normalny, czyli np.
user rzadko przydziela 1 000B, zazwyczaj 10 000B, rzadko 100 000B. Jak
widzisz po zlogarytmowaniu (np. log10) osi X masz 3, 4, 5. Tutaj okazuje
się, że właśnie średnia harmoniczna jest dobra a nie arytmetyczna.

Dodatkowo jest tak, że większość danych mieści się w przedziale średnia +
odchylenie standardowe (pierwiastek z wariancji). Czyli dokładnie wiesz
jakie ma przyrosty banków danych. Końcowo możesz dla danego dynamicznego
zbiornika przydzielać, albo dokładnie skoki o estymowaną średnią, albo
bardziej bezpiecznie o średnią + odchylenie.

W wersji On line zakładasz ustalony typ rozkładu (j.w.). Masz okno czasowe
ostatnich k przyrostów resize. Wyznaczasz estymator średniej i odchylenia
dla tego wektora k-ostatnich przyrostów allokacji i masz predyktor ZOH/FOH.
O co chodzi w tym prostym predyktorem:
1. nie zawiera modelu -- to jest ZOH, a w zasadzie FOH -- jest banalny.
2. wyliczanie pierwiastka też można mocno szacować (aby skrócić obliczenia),
bo i tak to wszystko są szacunki. Np. można pierwiastek zlinearyzować w
kilku przedziałach.
W ogóle wszystkie obliczenia poza ręcznymi (na papierze) wyznaczeniem
optymalnego estymatora można przybliżać tak, żeby wydajność była drakońska.

Można to oczywiście jeszcze podkręcać, albo modyfikować do potrzeb
konkretnego kontenera/usera. Ważne jest też dobieranie stosowanego rozmiaru
bufora pamiętającego kolejne Delta resize, ze względu na dynamikę
predyktora, ale to są że się tak wyrażę współczynniki dziadka Paździerzaka.
W swoich zabawkach raz potrzebowałem małe "k", raz duże w zależności od
kontekstu. Jak coś to pisz na priv.

> Właśnie wielowątkowo bezpieczne zliczanie referencji. Ale
> dokładnie TYLKO tyle. Na spójność zawartości dzielonych
> w ten sposób obiektów żadnych gwarancji nie daje, bo i nie
> może. Stąd poza szczególnym przypadkami, polegającymi
> na ręcznym zapewnianiu spójności pamięci (czy to jawne
> bariery, czy efekty uboczne tricków wyłączania forwardingu
> itp. sztuczkek) boost::shared_ptr powinien być stosowany
> tylko do obiektów const.

Rozumiem że łysy shared_ptr tylko do consta. Ale czy my jesteśmy
ograniczeni, czy jak? Czemu nie można mieć stosownego
elementu "pilnującego" spójności w otoczeniu shared_ptr. Nie wiem ale dla
mnie rozwiązania ręczne są lepsze niż globalne (za ciężkie). Np. mam klasę
i mam tam np. trzy zbiorniki. Jeden jest tylko do odczytu (inicjalizowane
na starcie stałe parametry modelu), drugi jest rzadko modyfikowany
(adaptator), trzeci zmienia się bądź co (dane uczące). Teraz do pierszego
nie ma co robić żadnych blokad. Drugi -- można dać mutex albo monitor. Ten
ostatni kontener to tylko warto obarczyć mutexem, bo on się zmienia na tyle
często, że niech będzie blokowany przy każdej próbie zapisu, odczyt niech
będzie swobodny (o ile jakiś zapis go nie blokuje). Lepiej zrobić to
samemu, czyż nie?

> PS. widzę, że poruszyliście sprawę włókien -- świetnie,
> to bardzo ciekawy temat, ale zbliżone do moich wnioski
> już zostały wyciągnięte, więc chwilowo nie mam nic do
> dodania.

He, he. Znowu moja teoria flame się sprawdziła. Do dziś byłem w niewiedzy
dot. włókien, a tu proszę nowe ciekawe zagadnienie i jeszcze milej bo na
moim pc mogę się tym pobawić, a może kiedyś nawet użyć w praktyce. W każdym
razie wygląda to na niezwykle wydajne cóś. Mam tylko kłopot z ustaleniem
ile konkretna procedura pożera stosu, aby jej przydzielić stosowny obszar.
To co widziałem w Tutkach jest strasznie duże w stosunku do potrzeb. Np.
16kB stałego bufora, a tak naprawdę w konkretnym przypadku wystarczy
przydzielić 447B.

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/