🚀 go-pugleaf

Sebastian Kaliszewski wrote:

> Tak przy okazji... Coraz mocniej dochodzę do wniosku,
> że wątki do realizacji równoległości nadają się marnie

Nie Ty jeden... ;-) Wątki (jądrowe) to dla mnie zaledwie interfejs
umożliwiający dostanie się do procesorów systemowych (bo jakoś
trzeba), więc zdumiewa mnie takie upowszechnienie się tego modelu.
Genralnie preferuję model puli zadań (task -- nieprzerywalne,
wykona się albo do końca, albo wcale) w trybach work sharing
i work stealing do symulowania przetwarzania strumieniowego.

> Bo przy każdej alokacji i zwalnianiu muisz mieć conajmniej dostęp do TLS.

To akurat nie jest problemem, dostęp do TLS _da_ się zrobić tak, że
będzie superwydajny. Jeśli jest odpowiednie wsparcie sprzętowe
i programowe na poziomie ABI, to nie ma powodu, by TLSy były
wolniejsze niż zwykła pamięć. Np. na IA-32 pod Windows do realizacji
TLSów służy rejestr segmentowy fs. Niestety oficjalnie nie wolno
(mharharhar...) bezpośrednio pisać do tego segmentu i trzeba używać
dość powolnych funkcji z WinAPI. Znacznie gorzej jest na systemach
uniksowych, gdzie TLSy bywają bardzo powolne. No ale jest kilka
pomysłów na ich znaczne przyspieszenie...

> Standardowy (w C++(0/1)x, dziś tr1) shared_ptr musi być synchronizowany.

Musi, ale to za mało! :-) On się w zasadzie nadaje tylko do obiektów
read-only, bo gdy następuje modyfikacja dzielonej zawartości, to nie
ma żadnego mechanizmu wymuszenia spójności obrazów pamięci i coś,
co bezbłędnie zadziała na IA-32 wygeneruje heisenbug na PowerPC.
Niestety dobre zrozumienie tych niuansów nie jest zbyt powszechne,
a będzie jeszcze gorzej, bo programowanie wielowątkowe się
upowszechnia, a modele spójności rozluźniają. Już chyba czas zacząć
pytać "GDZIE SĄ BARIERY???", bo inaczej się skończy megakatastrofą. :-)

> A Zwykle 95% obiektów nigdy między wątkami nie będzie przekazywanych.

Dlatego lubię JITy. Tam się do pewnego stopnia da automatycznie
dowodzić pewnych własności obiektów i generować domeny
synchronizacji.

> A ta synchronizacja kosztuje i to kosztuje dużo.

Bardzo dużo. Operacje atomowe są około stukrotnie (!) wolniejsze niż
zwykłe, więc jeśli są często używane, to wydajność może nieźle siąść.
To i tak znacznie lepiej niż klasychne podejście z lockowaniem, które
się nie skaluje powyżej kilku rdzeni, ale mimo tego nie jest dobrze.
Dlatego wolę work stealing niż work sharing, mimo znacznie większej
komplikacji kolejki zadań -- mogę wówczas wykonać nawet kilkaset
milionów prostych tasków na sekundę, a nie zaledwie ~10 milionów
w trybie sharing. Im bardziej złożone zadania, tym narzut na kolejkę
jest mniejszy, ale ja lubie drobnoziarniste podziały.

> Równoległe rozwiązania wieloprocesowe, gdzie komunikacja między 
> kontekstami przetwarzania jest ściśle wydzielona i gdzie jest zarządzanie 
> całością jest sensownie realizowalne, są po prostu szybsze (i to o 
> kilkadziesiąt procent).

Ja tam wolę trzymać wszytsko w jednej przestrzeni adresowej, a więc
efektywnie w jednym procesie, ale zasadniczo nie programuję wielowątkowo
w standardowo rozumiany sposób -- wolę podejście oparte na przesyłaniu
komunikatów, wzbogacone potężnymi zaletami pamięci dzielonej, co
efektywnie odtwarza pewną klasę strukur strumieniowych -- tylko, że ja
jestem "dziwny", bo podejście data-flow przyjąłem za swoje "od pierwszego
wejrzenia" i nic dla mnie nie znaczy jego porażka w latach 70-tych. :-)
No i przede wszystkim te niedoceniane powszechnie SIMDy...

    Pozdrawiam
    Piotr Wyderski