A. L. wrote:

>>Nie.
>>Lubisz odsyłanie do książek... W kwestii wątków zgadzam się z "The Art of
>>Unix programming". Zacząłem miec takie samo zdanie jak autorzy jeszcze
>>zanim na tę książkę trafiłem.
>
> Poza tym jeszcze... Argument "to musi byc prawda bo jest napisane w
> ksiazce" jest takim sobie argumentem w dyskusji

Odsyłam do książki, ponieważ po co mam spisywać to na grupę własnymi słowami
to, co tam jest napisane? Szczególnie że tamci autorzy ujęli to ładniej, niż
ja bym to zrobił.

Na temat tego, że nie wszystko jest Uniksem: oczywiście, nie jest, ale też
nie ma się co ekscytować tym, że jakiś człowiek nie używa technik (a skoro
nie używa, to można stwierdzić że i nie zna), które jego rozmówca uwielbia -
a nie używa np. dlatego, że ma praktyczne doświadczenie tworzenia programów
na platformę, na której ta technika się nie sprawdza. I zależało mu na tym,
aby robić programy jak najlepsze, a nie jak najbardziej zbieżne z aktualnie
panującą modą.

do góry

On Feb 20, 3:27 pm, bartekltg <b...@g...com> wrote:
> W dniu 2012-02-19 22:26, Andrzej Jarzabek pisze:
>
> > On 19/02/2012 21:14, A.L. wrote:
> >> On Sun, 19 Feb 2012 19:18:08 +0100, szyk<s...@o...pl> wrote:
>
> >> Natomiast zeby nei wiem co pisac o "pair programming" i podobnych
> >> rzeczach - koszt projektu jest sprawa najwazniejsza. Albowiem jak sie
> >> sklada papiery w przetargu, to tzreba napisac ile projekt bedzie
> >> kosztowal. Jak zorganizujemy go tak ze przy jednym komputerze bedzie
> >> siedzialo dwoch facetow, to albo: a) koszt projektu wzrosnie
> >> dwukrotnie, albo b) kazdy z facetow zadowoli sie polowa pensji. W tym
>
> > Albo c) dwóch facetów zrobi to samo zadanie 2 razy szybciej niż 1 facet.
>
> Nie do końca.

Co to znaczy "nie do końca"? Ja nie mówię, że tak jest, ja mówię, że
jeśli tak jest, to ani koszt projektu nie wzrośnie dwókrotnie, ani
programiści nie będą się musieli zadowolić połową pensji.

> Jeden statek wiezie chiński badziew do europy 3 miesiące.
> Ile zajmie transport badziewia 5 statkami.
>
> ;)
>
> 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.

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?

A przykład ze statkami? Czemu nie? Można np. uzupełnić brakujące
informacje.

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

do góry

W dniu 2012-02-20 17:09, Andrzej Jarzabek pisze:
> On Feb 20, 3:27 pm, bartekltg<b...@g...com> wrote:
>> W dniu 2012-02-19 22:26, Andrzej Jarzabek pisze:
>>
>>> On 19/02/2012 21:14, A.L. wrote:
>>>> On Sun, 19 Feb 2012 19:18:08 +0100, szyk<s...@o...pl> wrote:
>>
>>>> Natomiast zeby nei wiem co pisac o "pair programming" i podobnych
>>>> rzeczach - koszt projektu jest sprawa najwazniejsza. Albowiem jak sie
>>>> sklada papiery w przetargu, to tzreba napisac ile projekt bedzie
>>>> kosztowal. Jak zorganizujemy go tak ze przy jednym komputerze bedzie
>>>> siedzialo dwoch facetow, to albo: a) koszt projektu wzrosnie
>>>> dwukrotnie, albo b) kazdy z facetow zadowoli sie polowa pensji. W tym
>>
>>> Albo c) dwóch facetów zrobi to samo zadanie 2 razy szybciej niż 1 facet.
>>
>> Nie do końca.
>
> Co to znaczy "nie do końca"?

Masz napisane poniżej;)

>> Jeden statek wiezie chiński badziew do europy 3 miesiące.
>> Ile zajmie transport badziewia 5 statkami.
>>
>> ;)
>>
>> 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.


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


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

To żaden atak, spokojnie;)

>
> 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;)


Serio, meliska, bo sie nerwowo na grupie robi.

pzdr
bartekltg

do góry

On Monday, February 20, 2012 3:41:02 PM UTC, Wojciech Jaczewski wrote:
I zależało mu na tym,
> aby robić programy jak najlepsze, a nie jak najbardziej zbieżne z aktualnie
> panującą modą.

Ale watki to nie jest "aktualnie pannujaca moda" tylko dosc stary temat.

RW

do góry

On 19/02/2012 19:23, Andrzej Jarzabek wrote:
> On 19/02/2012 14:33, Bronek Kozicki wrote:
>> On 19/02/2012 12:31, Andrzej Jarzabek wrote:
>>>
>>> Druga sprawa jest taka, że to, co opisujesz jest tylko możliwe wtedy,
>>> kiedy masz innych członków zespołu pracujących nad tym samym, co ty. A
>>> to ma te same wady, które są przypisywane programowaniu parami.
>>
>> 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.

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


B.

do góry

On Mon, 20 Feb 2012 16:41:02 +0100, Wojciech Jaczewski
<w...@o...pl> wrote:

>A. L. wrote:
>
>>>Nie.
>>>Lubisz odsyłanie do książek... W kwestii wątków zgadzam się z "The Art of
>>>Unix programming". Zacząłem miec takie samo zdanie jak autorzy jeszcze
>>>zanim na tę książkę trafiłem.
>>
>> Poza tym jeszcze... Argument "to musi byc prawda bo jest napisane w
>> ksiazce" jest takim sobie argumentem w dyskusji
>
>Odsyłam do książki, ponieważ po co mam spisywać to na grupę własnymi słowami
>to, co tam jest napisane? Szczególnie że tamci autorzy ujęli to ładniej, niż
>ja bym to zrobił.
>
>Na temat tego, że nie wszystko jest Uniksem: oczywiście, nie jest, ale też
>nie ma się co ekscytować tym, że jakiś człowiek nie używa technik (a skoro
>nie używa, to można stwierdzić że i nie zna), które jego rozmówca uwielbia -
>a nie używa np. dlatego, że ma praktyczne doświadczenie tworzenia programów
>na platformę, na której ta technika się nie sprawdza. I zależało mu na tym,
>aby robić programy jak najlepsze, a nie jak najbardziej zbieżne z aktualnie
>panującą modą.

Nie rozumiem powyzszego paragrafu, ale jak ktos programuje w Javie i
nie wie co to Thread i co to synchronize, to bardzo przepraszam, ale
neich zmieni zawod.

Poza tym zadziwie mnei pakowanie watkow do kategorii "moda". Ciekawe
jak Kolega zrobi pod Windows, w Javie, program ktory bedzie robil
dlugie obliczenia, a uzytkownik bedzie chcial mniec wglad w stan tych
obliczen bez przerywania procesu obliczania. Rozumiem ze bedzie jedna
wielka petla ktora co milisekunde bedzie sprawdzala stan klawiatury i
co milisekunde wysylala na ekran?

A.L.

do góry

On Mon, 20 Feb 2012 16:27:20 +0100, bartekltg <b...@g...com>
wrote:

>W dniu 2012-02-19 22:26, Andrzej Jarzabek pisze:
>> On 19/02/2012 21:14, A.L. wrote:
>>> On Sun, 19 Feb 2012 19:18:08 +0100, szyk<s...@o...pl> wrote:
>>>
>>> Natomiast zeby nei wiem co pisac o "pair programming" i podobnych
>>> rzeczach - koszt projektu jest sprawa najwazniejsza. Albowiem jak sie
>>> sklada papiery w przetargu, to tzreba napisac ile projekt bedzie
>>> kosztowal. Jak zorganizujemy go tak ze przy jednym komputerze bedzie
>>> siedzialo dwoch facetow, to albo: a) koszt projektu wzrosnie
>>> dwukrotnie, albo b) kazdy z facetow zadowoli sie polowa pensji. W tym
>>
>> Albo c) dwóch facetów zrobi to samo zadanie 2 razy szybciej niż 1 facet.

No a 100 facetow to bylby jeden blysk

A.L.

do góry

Dnia Mon, 20 Feb 2012 11:12:25 +0100, Wojciech Jaczewski napisal:

> A. L. wrote:
>
>> [...] "ale ja bez watkow". Na pytanie "dlaczego" padaja rozne
>> odpowiedzi.
>> [...] "to jest sposob na klopoty"
>
> A czy przypadkiem używanie wątków (tam gdzie nie jest to na prawdę
> niezbędne) nie jest proszeniem się o kłopoty?

Ogólnie, umiejętność poprawnego pisania programów wielowątkowych to
nie wysyłanie rakiety na Marsa.

Ale zgadzam się, że wielu programistów tego nie ogarnia,
co jest jedną z dwóch głównych motywacji transactional memory
(nie da się popsuć). Jeszcze jedna czy dwie wersje gcc i
transactional memory będzie dostarczane z kompilatorem, a za
jakiś czas będzie standartem faktycznym i skończy się to voodoo.

Edek

do góry

On Mon, 20 Feb 2012 17:32:36 +0100, bartekltg <b...@g...com>
wrote:

>W dniu 2012-02-20 17:09, Andrzej Jarzabek pisze:
>> On Feb 20, 3:27 pm, bartekltg<b...@g...com> wrote:
>>> W dniu 2012-02-19 22:26, Andrzej Jarzabek pisze:
>>>
>>>> On 19/02/2012 21:14, A.L. wrote:
>>>>> On Sun, 19 Feb 2012 19:18:08 +0100, szyk<s...@o...pl> wrote:
>>>
>>>>> Natomiast zeby nei wiem co pisac o "pair programming" i podobnych
>>>>> rzeczach - koszt projektu jest sprawa najwazniejsza. Albowiem jak sie
>>>>> sklada papiery w przetargu, to tzreba napisac ile projekt bedzie
>>>>> kosztowal. Jak zorganizujemy go tak ze przy jednym komputerze bedzie
>>>>> siedzialo dwoch facetow, to albo: a) koszt projektu wzrosnie
>>>>> dwukrotnie, albo b) kazdy z facetow zadowoli sie polowa pensji. W tym
>>>
>>>> Albo c) dwóch facetów zrobi to samo zadanie 2 razy szybciej niż 1 facet.
>>>
>>> Nie do końca.
>>
>> Co to znaczy "nie do końca"?
>
>Masz napisane poniżej;)
>
>>> Jeden statek wiezie chiński badziew do europy 3 miesiące.
>>> Ile zajmie transport badziewia 5 statkami.
>>>
>>> ;)
>>>
>>> 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.
>
>
>> 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.
>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.
>
>
>Chciałem tylko zauważyć, że 'dwa razy więcej pracowników'
>nie musi oznaczać 'dwa razy szybciej' jak sugerowałeś.
>

Co juz dawno zauwazyl Brooks w ksiazce Mythical Man-Month. Zauwazyl
mianowicie ze dodanei programistow do projektu na ogol opoznia projekt

A.L.

do góry

On 20/02/2012 15:41, Wojciech Jaczewski wrote:
> Na temat tego, że nie wszystko jest Uniksem: oczywiście, nie jest, ale też
> nie ma się co ekscytować tym, że jakiś człowiek nie używa technik (a skoro
> nie używa, to można stwierdzić że i nie zna), które jego rozmówca uwielbia -

to nie tak; synchronizacja jest potrzebna niezależnie czy mowa o
programowaniu wielowątkowym czy wielprocesowym; synchronizacja nie jest
"nowinką techniczną" której znajomość jest kwestią gustu.


B.

do góry