On Feb 20, 6:15 pm, Bronek Kozicki <b...@s...net> wrote:
> On 19/02/2012 19:23, Andrzej Jarzabek wrote:
>
> >> różnica polega na tym, że każdy z członków zespołu może w danym momencie
> >> pracować nad innym zadaniem, i tylko okazjonalnie poświęcić swoją uwagę
> >> zadaniom kolegów.
>
> > W takiej sytuacji jest kilka problemów:
>
> > Skoro kolega zajmuje się czymś innym, to niekonieczenie ma orientację w
> > tym, co robisz, żeby jakkolwiek pomóc. Więc musi się wdrożyć w tematem,
>
> widzisz, cały zespół (mały, ale zespół) zajmuje się pielęgnacją
> *jednego* programu, jeden z celów takiej polityki jest taki że dowolny
> członek zespołu potrafi poprawić program/ocenić pracę innego/dodać nowe
> features. Oczywiście niektórzy znaję pewne miejsce programu lepiej od
> innych, ale to kwestia praktyki. GUI jest pielęgnowane przez inny zespół
> (i w innym języku).
>
> Ponadto na ten konkretny problem każdy z członków zespołu już wcześniej
> się natknął, tylko dopiero niedawno zaczęło to przeszkadzać użytkownikom.

No ale sam widzisz, masz taki konkretny problem i taką specyfikę
projektu.

W innych projektach często jest tak, że poszczególne problemy są mocno
rozstrzelone, np. jedna osoba robi interfejs do JMS, inna optymalizuje
zużycie pamięci, a inna jeszcze moduł komunikacji z bazą danych.

Nawet jeśli założenie jest takie, że każdy ma móc pracować nad
dowolnym kawałkiem programu i programiści są rotowani między
komponentami, to nadal masz ten problem: inny programista w danym
momencie zajmuje się czymś zupełnie innym; nad twoim komponentem może
kiedyś pracował, ale to mogło być wiele miesięcy temu. Musiałby sobie
przypomnieć. Poza tym nawet jak się orientuje w danym komponencie, to
nie orientuje się w tym, co ty akurat próbujesz z nim zrobić. Więc
musisz mu to wytłumaczyć - czasem będzie to proste, ale czasem sprawa
jest bardziej skomplikowana i tak jak ty poświęciłeś kilka godzin na
czytanie dokumentacji, rozmowy z analitykami itd. żeby to zrozumieć,
tak może teraz będziesz musiał poświęcić kilka godzin swojego i kolegi
czasu na wytłumaczenie mu tego.

> > Kolejną istotną sprawą jest czas przestawienia się, zmiany kontekstu.
> > Jeśli twój kolega pracuje nad czymś innym, ale odrywa się od swojej
>
> z mojego doświadczenia zmiana kontekstu jest stosunkowo tania jeżeli
> cały czas dotyczy programowania, w ramach tego samego programu.
> Spotkania za to, czy zmiana projektu .... to już inna para kaloszy.

Z mojego doświadczenia w ramach jednego projektu możesz mieć problemy
tak rozbieżne, że równie dobrze mogłyby dotyczyć zupełnie innego
projektu.

do góry

On Feb 20, 6:28 pm, A.L. <l...@a...com> wrote:
> On Mon, 20 Feb 2012 16:27:20 +0100, bartekltg <b...@g...com>
>
> >> Albo c) dwóch facetów zrobi to samo zadanie 2 razy szybciej niż 1 facet.
>
> No a 100 facetow to bylby jeden blysk

No bo to zawsze tak działa. Jeśli np. wnoszę kanapę na trzecie piętro
i mi ciężko idzie, to zanim poproszę drugą osobę o pomoc zawsze
stawiam sobie pytanie: czy pułk wojska wniósłby tę kanapę w kilka
sekund? Oczywiście, że by nie wniósł, więc proszenie drugiej osoby o
pomoc równiez nie ma sensu.

do góry

On Feb 20, 4:32 pm, bartekltg <b...@g...com> wrote:
> W dniu 2012-02-20 17:09, Andrzej Jarzabek pisze:
>
> >> Programiści akurat doskonale wiedzą, że zysk ze zrównoleglenia
> >> rzadko jest liniowy;-)
> > Jest szafa, kanapa, duży materac, trzeba wnieść po schodach na trzecie
> > piętro. Dwóm osobom wniesienie każdej z nich zajmie pięć minut, jednej
> > osobie zajmie po kilka godzin a pewnie jeszcze uszkodzi.
>
> I o to chodzi. 'Roboczogodzina' nie zawsze jest dobrym
> przelicznikiem.

Zgoda, jednak to, czego programiści mogą nie wiedzieć, to to, że w
innych kwestiach niż zrównoleglanie obliczeń na wielu procesorach,
zysk ze zrównoleglenia może być większy niż liniowy. Jeśli jest
większy niż liniowy, to to, co pisałem, jest również prawdą.

Ja nie wiem, jak w tym przypadku jest. Domyślam się, że raz jest tak,
raz jest inaczej, a w dodatku trudno to dokładnie określić, bo na
ostateczny długoterminowy zysk wpływają różne rzeczy.

> > Czy twoje programistyczne doświadczenie mówi ci, że to kompletnie
> > nierealistyczne, bo robienie czegoś wspólnie przez kilka osób działa
> > zawsze tak samo, jak zrównoleglanie programu na kilka procesorów?
>
> Cześć zadań da się idealnie zrównoleglić. Cześć nie.

Ale ty znowu myślisz o zrównoleglaniu obliczeń, gdzie
"idealnie"="liniowo". W życiu robienie czegoś wspólnie z innymi ludźmi
to niekoniecznie jest "zrównoleglenie" w takim sensie.

> Trzeba sie konsultować (to akurat czasem możę przyszpieszyć:)
> Napiszą program i teraz sie kompiluje a potem testuje/liczy.
> I tu już para nie pomogła.

Wiesz, jeśli każdy z nich z osobna będzie robił coś, co będzie
wymagało długiej kompilacji i/lub obliczeń, to i tak każdy z nich z
osobna będzie miał taki moment, kiedy ich kawałek się kompiluje czy
też liczy.

Oczywiście w takiej sytuacji para może nadal zazwyczaj coś robić przy
programie, np. zrobić sobie sesję projektowania, refaktoryzować kod,
albo rozpocząć analizę następnego kawałka roboty.

> Chciałem tylko zauważyć, że 'dwa razy więcej pracowników'
> nie musi oznaczać 'dwa razy szybciej' jak sugerowałeś.

Ale właśnie o to chodzi, że nie sugerowałem, że musi. Chodziło mi o
to, że cały wywód A.L. że albo a) dwa razy drożej, albo b) za połowę
pensji opierał się na nieuzasadnionym założeniu, że 'dwa razy więcej
pracowników' oznacza 'tak samo szybko'. Jest to tak samo nieuzasanione
co 'dwa razy szybciej', ale póki nie mamy uzasadnienia w którąkolwiek
stronę, możemy tylko powiedzieć, że nie wiemy, czy dwóch praccowników
zrobi to samo zadanie tak samo szybko czy więcej lub mniej niż dwa
razy szybciej.

Moje doświadczenie z pracą solo i bardzo sporadyczną pracą parami
wskazuje, że przypieszenie może być znaczne, nawet więcej niż
dwukrotne, w szczególności jeśli się wlicza czas nie tylko
bezpośrednio samego kodowania danego kawałka kodu, ale też korzyści
czasowe z mniejszej ilości błędów, lepszego projektu i szybszego
transferu wiedzy.

> > A przykład ze statkami? Czemu nie? Można np. uzupełnić brakujące
> > informacje.
>
> A choćby czekanie na informacje zwrotną. Od klijenta,
> od komputera (wynik programu, wynik testów).
> Testem może być 'doba podłączenia do sieci' i wtedy
> większa liczba komputerów nie pomaga.
>
> >> Jeden statek wiezie chiński badziew do europy 3 miesiące.
> > Chińskiego badziewia jest tysiąc ton, a statek może na raz zabrać 200.
> >> Ile zajmie transport badziewia 5 statkami.
>
> Ale tu już inne zadanie;)

To jest to samo zadanie, tylko uzupełnione o brakującą informację. :)

Oczywiście domyślam się, że w zadaniu chodziło ci o to, że statek
bierze całe badziewie na jeden raz i w związku z tym w te 3 miesiące
wykonuje tylko jedną podróż, ale jeśli dopiszesz to do zadania, to
powstaje pytanie, dlaczego akuat twoje, a nie moje warunki mają być
adekwatną analogią do pracy parami?

Ja oczywiście uważam, że w ogóle to zadanie nie jest adekwatne. W
ogólności jeśli postawisz pytanie tak: "jeden X wykonuje Y w p godzin,
w ile godzin wykona Y n X-ów?" to odpowiedź brzmi "zależy od X, Y, n i
p". Dla statków może być tak, dla sprzątaczek może być inaczej, dla
wnoszenia meblli po schodach może być jeszcze inaczej, a dla
programistów może to nawet zależeć od tego jaki program piszą, jakie
mają chechy osobowości i od pierdyliona innych czynników. Ludzie to
nie procesory, nie działają do końca racjonalnie i o ich zachowaniu
decyduje tzw. psychologia.

> Serio, meliska, bo sie nerwowo na grupie robi.

E tam nerwowo.

do góry

Andrzej Jarzabek wrote:

> Moje doświadczenie z pracą solo i bardzo sporadyczną pracą parami
> wskazuje, że przypieszenie może być znaczne, nawet więcej niż
> dwukrotne, w szczególności jeśli się wlicza czas nie tylko
> bezpośrednio samego kodowania danego kawałka kodu, ale też korzyści
> czasowe z mniejszej ilości błędów, lepszego projektu i szybszego
> transferu wiedzy.

Czy w tej parze miałeś człowieka z podobnym do swojego doświadczeniem, czy z
całkowicie innym?

do góry

On Feb 21, 12:59 pm, Wojciech Jaczewski <w...@o...pl> wrote:
> Andrzej Jarzabek wrote:
> > Moje doświadczenie z pracą solo i bardzo sporadyczną pracą parami
> > wskazuje, że przypieszenie może być znaczne, nawet więcej niż
> > dwukrotne, w szczególności jeśli się wlicza czas nie tylko
> > bezpośrednio samego kodowania danego kawałka kodu, ale też korzyści
> > czasowe z mniejszej ilości błędów, lepszego projektu i szybszego
> > transferu wiedzy.
>
> Czy w tej parze miałeś człowieka z podobnym do swojego doświadczeniem, czy z
> całkowicie innym?

Raczej podobnym, ale jeszcze raz powtórzę, że było to bardzo
sporadyczne - na studiach miałem może ze dwa kursy gdzie tak
pracowaliśmy, w działalności zawodowej to było raczej dosłownie kilka
posiadówek po parę minut - z ludźmi o różnycm doświadczeniu, czasem
podobnym do mojego, czasem nie.

do góry

Dnia Mon, 20 Feb 2012 22:26:37 +0100, Wojciech Jaczewski napisał(a):

> W C++ długotrwałe obliczenia wolałbym wyrzucić do osobnego procesu - bo
> proces w przeciwieństwie do wątku, zawsze daje się zatrzymać/ubić - gdyby
> użytkownik stwierdził że jednak mu to obliczenie niepotrzebne.

Watku niby nie da sie zatrzymac, gdy sie go _dobrze_ napisze?

--
pozdro
R.e.m.e.K

do góry

R.e.m.e.K wrote:

> Dnia Mon, 20 Feb 2012 22:26:37 +0100, Wojciech Jaczewski napisał(a):
>
>> W C++ długotrwałe obliczenia wolałbym wyrzucić do osobnego procesu - bo
>> proces w przeciwieństwie do wątku, zawsze daje się zatrzymać/ubić - gdyby
>> użytkownik stwierdził że jednak mu to obliczenie niepotrzebne.
>
> Watku niby nie da sie zatrzymac, gdy sie go _dobrze_ napisze?

Czyli pewnie w wątku muszę raz na jakiś czas przerywać obliczenia, aby
sprawdzić czy aby drugi wątek nie ma ochoty z nich zrezygnować?
W przypadku procesu NIE MUSZĘ tego robić a proces i tak będzie się dało
ubić.

do góry

On 20/02/2012 21:38, Wojciech Jaczewski wrote:
> Andrzej Jarzabek wrote:
>
>>> Wolę message passing na procesach.
>>> Częściowo wynika to z tego, co dotychczas robiłem, a POSIX-owe API ma
>>> bardzo poważne - jak dla mnie - wady:
>>> - pthread_cond_timedwait operuje na czasie systemowym a nie monotonicznym
>>
>> A do czego byś chciał używać tej funkcji, że ci to robi różnicę?
>
> Włącza się jakieś urządzenie, które mogło być ileś dni wyłączone, więc ma
> zegar rozsynchronizowany o kilka minut. Synchronizacja nastąpi wtedy, gdy
> będzie łączność z internetem, a ta może być od razu, a może za pół godziny.
>
> Nie mogę w takim przypadku używać pthread_cond_timedwait, bo zamiast
> poczekać planowane np. 5 sekund, raz poczeka mi 0 sekund a raz 5 minut.

Ale pthread_cond_timedwait nie jest po to, żeby odmierzać czas!

>> Można to łatwo zrobić tworząc osobne wątki, które czekają na zdarzenie
>> i generują komunikat czy warunek, na który czeka "główny" wątek.
>
> I w ten sposób zwiększyć komplikację programu, bo pojawia się więcej
> równoległych wątków niż byłoby w wersji z potokami/gniazdami.

Większa ilość wątków nie oznacza większej komplikacji - te wątki są
zresztą bardzo proste. A ponieważ - zwłaszcza jeśli się martwisz o
komplikację programu - masz to schowane za warstwą abstrakcji, to nie
robi to żadnej różnicy - po prostu tworzysz Warunek i rejestrujesz
Zdarzenia, które powodują jego spełnienie.

do góry

Andrzej Jarzabek wrote:

>> Nie mogę w takim przypadku używać pthread_cond_timedwait, bo zamiast
>> poczekać planowane np. 5 sekund, raz poczeka mi 0 sekund a raz 5 minut.
>
> Ale pthread_cond_timedwait nie jest po to, żeby odmierzać czas!

To po co w takim razie jest tam czas jako argument? I po co w ogóle istnieje
ta funkcja, skoro jest pthread_cond_wait?
Po prostu chciałem użyć pthread_cond_timedwait zgodnie z jej przeznaczeniem:
poczekaj na zdarzenie lub upływ czasu. I w moich warunkach - nie mogę.

> Większa ilość wątków nie oznacza większej komplikacji - te wątki są
> zresztą bardzo proste. A ponieważ - zwłaszcza jeśli się martwisz o
> komplikację programu - masz to schowane za warstwą abstrakcji, to nie
> robi to żadnej różnicy

Do czasu, gdy nie pojawia się błąd - być może w zupełnie innej części,
którego nie mogę wypatrzeć - wtedy nie mogę sobie na ślepo przyjąć
założenia, że inne części, działające w innych wątkach są OK - w ramach
szukania przyczyny błędu muszę zajrzeć także do nich. To, że zostało to
schowane za warstwą abstrakcji wiele nie zmienia.

do góry

On 21/02/2012 22:21, Wojciech Jaczewski wrote:
> Andrzej Jarzabek wrote:
>
>>> Nie mogę w takim przypadku używać pthread_cond_timedwait, bo zamiast
>>> poczekać planowane np. 5 sekund, raz poczeka mi 0 sekund a raz 5 minut.
>>
>> Ale pthread_cond_timedwait nie jest po to, żeby odmierzać czas!
>
> To po co w takim razie jest tam czas jako argument? I po co w ogóle istnieje
> ta funkcja, skoro jest pthread_cond_wait?
> Po prostu chciałem użyć pthread_cond_timedwait zgodnie z jej przeznaczeniem:
> poczekaj na zdarzenie lub upływ czasu. I w moich warunkach - nie mogę.

Ta funkcja, jak i wszystkie inne 'timed' nie jest po to, żeby jej używać
do normalnych czynności. Do tego, co próbujesz robić, powinieneś znowu
odpalić osobny wątek, który odczekuje odpowiednią ilość czasu i
sygnalizuje zmienną warunkową.

Funkcje 'timed' służą do zaimplementowania timeoutu, generalnie do
uniknięcia sytuacji, kiedy program by 'zwisał' albo zostawiał zbędne
wątki. Przykładowo jeśli wątkami realizujesz jakieś równolegle
działające komponenty w danym programie, to możesz chcieć mieć w tym
programie moduł monitorujący te komponenty, pozwalający użytkownikowi na
podglądnięcie, co program w danej chwili robi. I żeby taki moduł
wiedział, że dany wątek nadal żyje i czeka na cośtam, ten wątek może co
np. sekundę przerywać czekanie i wysyłać monitorowi komunikat 'nadal
żyję i czekam'. Inna możliwa sytuacja jest taka, że pewne wątki mogą
przestać być potrzebne - jako alternatywę dla pthread_cancel można
zaprojektować je tak, żeby periodycznie sprawdzały, czy powinny jeszcze
istnieć i jeśli nie, to się same zamykały.

>> Większa ilość wątków nie oznacza większej komplikacji - te wątki są
>> zresztą bardzo proste. A ponieważ - zwłaszcza jeśli się martwisz o
>> komplikację programu - masz to schowane za warstwą abstrakcji, to nie
>> robi to żadnej różnicy
>
> Do czasu, gdy nie pojawia się błąd - być może w zupełnie innej części,
> którego nie mogę wypatrzeć - wtedy nie mogę sobie na ślepo przyjąć
> założenia, że inne części, działające w innych wątkach są OK - w ramach
> szukania przyczyny błędu muszę zajrzeć także do nich. To, że zostało to
> schowane za warstwą abstrakcji wiele nie zmienia.

Właśnie wiele zmienia, bo pozwala na wnioskowanie o poszczególnych
częściach programu w izolacji. Oczywiście jeśli twój program ma UB, to
teoretycznie wszystko jest możliwe, ale w tym przypadku też można
dedukować przyczyny po objawach. Poza tym im prostszy dany element, tym
mniejsze prawdopodobieństwo, że ma UB. Np. funkcja typu void, która
blokuje aż będzie coś na wejściu czy innym sockecie, jest bardzo prosta.
Funkcja, która wywołuje zadaną funkcję typu void i ustawia zmienną
warunkową jest również bardzo prosta (a tę jedną funkcję możesz
wykorzystać do obsługi wszystkich interesujących cię zdarzeń,
wymieniając tylko która funkcja ma być wywołana.

Oczywiście do tego wszystkiego dobrze mieć jeszcze język wspierający
abstrakcję, a jeszcze lepiej do tego sensowne biblioteki, a nie grzebać
się w gołych pthreadsach. W ogóle jedyny racjonalny powód, jaki widzę,
żeby cokolwiek robić w pthreadsach, to napisanie Nowej Jeszcze
Zajebistszej Od Wszystkich Istniejących Biblioteki Do Wątków
(zajebistszej pod jakimkolwiek interesującym nas względem naturalnie).

do góry