🚀 go-pugleaf

Seweryn Habdank-Wojewódzki wrote:

> 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.

To jest kod zupełnie innego programu. Twój w C++ powinien
zwrócić 9, a w asemblerze zwracane jest 0. Albo masz totalnie
popsuty kompilator, albo... sam nie wiem...

>> Zdradliwy języczek, co? :-)))
>
> Hmm... czy ja wiem, dobrze działa przeładowanie w sumie to lubię kiedy tak
> jest.

No tak, taki sposób zapisu bywa czytelniejszy, ale ma tę wadę, że
poźniej sie wydzierasz pod niebiosa, że nie widzisz synchronizacji.
Dlatego ja się w pełni zgadzam z tym, że jej *nie widzisz*, natomiast
niezupełnie z tym, ze jej tam nie ma. :->

> A co dokładnie chcesz wiedzieć?

Jaka matematyka za tym stoi. Moja dość rozbudowana w tym
zakresie intuicja pozwala mi całkiem skutecznie łapać ryby gołymi
rękami, ale wolałbym prawdziwą wędkę. :-)

> Off-line.

Przyjmijmy, że interesują mnie wyłącznie rozwiązania on-line.

> Tutaj okazuje się, że właśnie średnia harmoniczna jest dobra a nie 
> arytmetyczna.

No ale dlaczego? Tzn. nie chodzi mi o odpowiedź na powyższe
pytanie, tylko poznanie ogólnego mechanizmu fitowania. :-)

> W ogóle wszystkie obliczenia poza ręcznymi (na papierze) wyznaczeniem
> optymalnego estymatora można przybliżać tak, żeby wydajność była 
> drakońska.

O stronę implementacyjną się nie martwię, teoria mnie interesuje.

> 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 możemy, tylko wręcz musimy. Może być muteks, mogą
być barierki i lock-free... Swoją drogą, to ja w zasadzie nie
używam shared_ptr, zdecydowanie bardziej wolę intruzywnego.

> Lepiej zrobić to samemu, czyż nie?

Mnie nie musisz tego pytania zadawać. :-)
Problem w tym, że poza kilkoma rozwiązaniami kanonicznymi
typu sekcje krytyczne to są dość złożone rzeczy.

> 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ć

Wszędzie możesz, przecież to są wątki trybu użytkownika. W WinAPI
masz do tego funkcje, w POSIX też, a jak gdzieś nie masz, to daj mi
kawałek asemblera oraz dokumentację platformy i Ci zrobię na poczekaniu. :-)

> W każdym razie wygląda to na niezwykle wydajne cóś.

Słuszny wniosek. :-)
Inna sprawa, że ja wolę podejście jeszcze bardziej radykalne niż
włókna. Nazywam to taskami z braku lepszego pomysłu. Task
to paczka złożona z zestawu danych do przetworzenia i procedury
obliczeniowej. Wymagane jest, by dla każdych danych wejściowych
obliczenia były wykonalne się w skończonym czasie (nie w sensie
odgórnie ograniczonej liczby kroków, lecz tego, że procedura nie
może np. zawisnąć na IO), bo wykonanie tasku jest nieprzerywalne
(i w tym podejście jest słabsze od możliwości włókien, ale zyskuję
na wydajności). Wykonujący się task może aktywować inne taski,
może też tworzyć nowe. Front-endy IO same generują taski, więc
część wykonawcza nie musi czekać na odczyt lub zapis danych;
może jednak zlecać operacje IO, które jednak wykonają się jako
_inne_ taski. Model ten reprezentuje ekstremistyczne podejście
bottom-up. Zalety:

1. Jest niesamowicie wydajny oraz bardzo dobrze się skaluje.

2. Praktycznie nie wymaga od użytkownika synchronizacji,
bo aktywacja tasku sama w sobie jest punktem synchronizacyjnym.
Dane nie są dzielone między taskami (o ile same sobie tego nie
życzą), więc domeny spójności są bardzo wyrażnie określone.
Bardziej zaawansowane zagadnienia, takie jak podział jednego
zadania logicznego na kilka fizycznych (w tym automatyczna)
mogą wymagać dodatkowej synchronizacji, ale tam modele
lock-free niejako wynikają z architektury, więc zwykle garść
instrukcji atomowych i barierek wystarcza.

3. Jego cechą jest latency hiding, co wynika z samej zasady działania:
operacje zostaną wykonane _dopiero_ wtedy, gdy wszystkie dane są
skompletowane, więc nic (porawnie napisanego) nie ma prawa
zawisnąć np. na muteksie.

4. Działa tym wydajniej, im bardziej jest obciążony. Jeśli są jakieś
niewykorzystane moce przerobowe, to po prostu dorzuca się
systemowi zadań. Łatwo też wprowadzić automatyczne balansowanie
obciążenia oraz -- przy ostrożnym podejściu -- automatyczne
rozpraszanie zadań.

5. Asynchroniczność to jego drugie imię.

Wady:

1. Jest jednak dość nieintuicyjny dla osób przyzwyczajonych
do programowania top-down.

2. Jest bardzo płaski, praktycznie nie da się w nim wyróżnić
głębszej struktury, więc całą działalność związana z inżynierią
oprogramowania musi zostać przeniesiona na poziom wzajemnych
oddziaływań tasków.

3. Kod jest bardzo rozproszony, nie da się powiedzieć, że
jakaś procedura wywołuje inną, a jedynie to, że działanie
obecnej jest następstwem czegoś, co wykonało się uprzednio.

4. Pewne naturalne w modelu top-down konstrukcje
wymagają dość rozbudowanych odpowiedników botom-up.
Przypuszczam jednak, że interesujące z punktu widzenia
praktyki przypadki użycia da się tłumaczyć automatycznie,
ale pewności jeszcze nie mam.

No ale ja jestem zakochany po uszy w architekturze data flow,
więc mnie głównie jej zalety interesują, a z wadami nauczyłem
się żyć. ;-)))

    Pozdrawiam
    Piotr Wyderski