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.