W dniu środa, 1 kwietnia 2015 12:03:58 UTC+2 użytkownik M.M. napisał:
>
> > i nie jest do konca
> > pewien jak działa np jakies api z ktorym sie
> > łaczy wtedy ten łancuch dowodzenia moze sie
> > zerwać
> To już w ogóle robi się sieczka.
>
no niestety, czasem mozna sie zgubiec lekko nawet we wlasnym kodzie, choc mi sie to
raczej nie zdarza, tj zdarza sie ale w ograniczonym zakresie i tymczasowo (aqkurat
dzis mi sie cos spieprzylo z eventami), wtedy nieststy trzeba
poswiecic troche czasu i przeczytac jakas sciezke i dojsc do jasnosci

do góry

On Wednesday, April 1, 2015 at 12:44:41 PM UTC+2, firr wrote:
> W dniu środa, 1 kwietnia 2015 12:03:58 UTC+2 użytkownik M.M. napisał:
> >
> > > gorzej jest jesli ktos pracuje gdzies w jakiejs
> > > firmie np pod presja czasu
> > Nie dość że pod presją czasu, to jeszcze pod innymi
> > presjami
>
> pod jakimi na przyklad*? ja np osobiscie nie na.leze do ludzi dla ktorych
pracowanie pod
> presją daje dobre wyniki
>
> * mi do glowy przychodzą
> - rozpraszajacy ludzie
> - rozpraszajace obowiazki poboczne
> - newygoda siedzenie 8h na tylku
> ( - problemy zdrowotne (gorsze do ogarniecia w publicznej lokalizacji)
To nie jest presja, to są zwykłe przeszkody. Np. presja emocjonalna,
albo finansowa, jakieś kary, sądy. Siadasz do kodu i myślisz o
czymś innym. Uważam że lekkie naciski dobrze robią, ale po
przekroczeniu jakiegoś poziomu, działa odwrotnie.

do góry

On Wednesday, April 1, 2015 at 12:51:12 PM UTC+2, firr wrote:
> W dniu środa, 1 kwietnia 2015 12:03:58 UTC+2 użytkownik M.M. napisał:
> >
> > > i nie jest do konca
> > > pewien jak działa np jakies api z ktorym sie
> > > łaczy wtedy ten łancuch dowodzenia moze sie
> > > zerwać
> > To już w ogóle robi się sieczka.
> >
> no niestety, czasem mozna sie zgubiec lekko nawet we wlasnym kodzie, choc mi sie to
raczej nie zdarza, tj zdarza sie ale w ograniczonym zakresie i tymczasowo (aqkurat
dzis mi sie cos spieprzylo z eventami), wtedy nieststy trzeba
> poswiecic troche czasu i przeczytac jakas sciezke i dojsc do jasnosci
Ja wychodzę z założenia, że po czasie... mówiąc precyzyjnie to nie
zgubię się, ale zapomnę. Staram się pisać modułowo. Małą poprawę
zawsze jestem w stanie w module zrobić, a gdy jest za dużo zmian, to
gruntownie przerabiam tylko dany moduł, albo stary kopiuję i na jego
bazie robię nowy - wtedy mam starą i nową wersję.

do góry

W dniu środa, 1 kwietnia 2015 14:29:11 UTC+2 użytkownik M.M. napisał:
> On Wednesday, April 1, 2015 at 12:44:41 PM UTC+2, firr wrote:
> > W dniu środa, 1 kwietnia 2015 12:03:58 UTC+2 użytkownik M.M. napisał:
> > >
> > > > gorzej jest jesli ktos pracuje gdzies w jakiejs
> > > > firmie np pod presja czasu
> > > Nie dość że pod presją czasu, to jeszcze pod innymi
> > > presjami
> >
> > pod jakimi na przyklad*? ja np osobiscie nie na.leze do ludzi dla ktorych
pracowanie pod
> > presją daje dobre wyniki
> >
> > * mi do glowy przychodzą
> > - rozpraszajacy ludzie
> > - rozpraszajace obowiazki poboczne
> > - newygoda siedzenie 8h na tylku
> > ( - problemy zdrowotne (gorsze do ogarniecia w publicznej lokalizacji)
> To nie jest presja, to są zwykłe przeszkody. Np. presja emocjonalna,
> albo finansowa, jakieś kary, sądy. Siadasz do kodu i myślisz o
> czymś innym. Uważam że lekkie naciski dobrze robią, ale po
> przekroczeniu jakiegoś poziomu, działa odwrotnie.

mi nie robia dobrze chyba nawet lekkie,
przynajmniej nigdy nic takiego nie zauwazylem

dla mnie to powyzej to jest presja o tyle ze jest ci to narzucane i sie nie da tego
wyzbyc
wiec sa to stale elementy nacisku i dyskomfortu ;/

do góry

W dniu środa, 1 kwietnia 2015 14:32:40 UTC+2 użytkownik M.M. napisał:
> On Wednesday, April 1, 2015 at 12:51:12 PM UTC+2, firr wrote:
> > W dniu środa, 1 kwietnia 2015 12:03:58 UTC+2 użytkownik M.M. napisał:
> > >
> > > > i nie jest do konca
> > > > pewien jak działa np jakies api z ktorym sie
> > > > łaczy wtedy ten łancuch dowodzenia moze sie
> > > > zerwać
> > > To już w ogóle robi się sieczka.
> > >
> > no niestety, czasem mozna sie zgubiec lekko nawet we wlasnym kodzie, choc mi sie
to raczej nie zdarza, tj zdarza sie ale w ograniczonym zakresie i tymczasowo (aqkurat
dzis mi sie cos spieprzylo z eventami), wtedy nieststy trzeba
> > poswiecic troche czasu i przeczytac jakas sciezke i dojsc do jasnosci
> Ja wychodzę z założenia, że po czasie... mówiąc precyzyjnie to nie
> zgubię się, ale zapomnę. Staram się pisać modułowo. Małą poprawę
> zawsze jestem w stanie w module zrobić, a gdy jest za dużo zmian, to
> gruntownie przerabiam tylko dany moduł, albo stary kopiuję i na jego
> bazie robię nowy - wtedy mam starą i nową wersję.

to ze ja sie czasem gubie w tych eventach to mz chyab wynika z tego ze nie ogarnalem
jeszcze jakiegos dobrego globalnego 'designu' i nie widze pewnych kawalkow zupelnie
czysto - bedzie trzeba nad tym popracowac (wraz z doswiadczeniem idze lepiej
ogarnianie takich zawijasów, aczkolwiek powoli)

do góry

W dniu środa, 1 kwietnia 2015 11:57:13 UTC+2 użytkownik M.M. napisał:

> > > > "Najlepiej jak to możliwe" -- to też nieprecyzyjne określenie.
> > > > Można je rozumieć jako "najlepiej jak komputer potrafi", albo
> > > > "najlepiej jak programista potrafi". To ostatnie jest zresztą
> > > > zazwyczaj twardym limitem, chyba że klient znajdzie lepszego
> > > > programistę
> > > No oczywiście że jest nieprecyzyjne. Jest nieprecyzyjne jak każde
> > > generalizowanie.
> >
> > Generalizowanie to tyle, co uogólnianie, czyli przechodzenie
> > od przypadku konkretniejszego do ogólniejszego. Stąd, że Twoje
> > generalizowanie jest nieprecyzyjne, nie wynika, że każde generalizowanie
> > jest nieprecyzyjne.
> Poczekaj bo się robią jakieś jaja z tej rozmowy:) Wątek ten dotyczy
> (nie)przydatności formalnego dowodu na poprawność programu w
> praktyce programistycznej/biznesowej. Potem ja wtrąciłem, że
> wymagania są różne, np. klient chce najlepszy program. Jak słuszne
> zauważyłeś, nie precyzowałem co oznacza najlepszy. Piłem do tego,
> że jeśli już tak ściśle i formalnie chcemy dowodzić, to należało
> by również dowieść, że program istotnie jest najlepszy. Więc moje
> generalizowanie obejmuje zbiór kryteriów według których
> w praktyce programistycznej ocenia się programy. Co widzisz
> nieprecyzyjnego w takim generalizowaniu?

To Ty (nie ja) napisałeś, cytuję "[określenie >najlepiej<] jest
nieprecyzyjne jak każde generalizowanie", stwierdzając
tym samym, że każde generalizowanie jest nieprecyzyjne.

> > Na przykład dodanie funkcji porównującej jako parametru
> > dla funkcji "sort" jest generalizowaniem, a jest piekielnie
> > precyzyjne.
> Dlaczego można precyzyjne generalizować po tejże funkcji, a po
> spotykanych kryteriach oceny programu nie można?

Nie wiem. To Ty twierdzisz, że nie można precyzyjnie generalizować
(chyba że coś źle zrozumiałem, bo teraz wydajesz się sugerować,
że jednak można?)

> > > Przypuszczasz, że chodziło mi o dowód formalny (na podstawie kodu
> > > źródłowego) na istnienie lepszego programu na rynku? ;-)
> >
> > Problem polega na tym, że nie wiem, o co Ci chodziło, bo wyraziłeś
> > się dość nieprecyzyjnie
> Myślałem że jak tylko odrzucisz przypadki nonsensowne, to będzie
> precyzyjnie.

Jak odrzuciłem przypadki nonsensowne, to wyszedł mi zbiór pusty.

> > W pewnym zakresie może tak. Ale znajdzie się również taki, w którym
> > eksperci będą między sobą dywagować, czy Słomczyński, czy Barańczak
> TO też da się rozwiązać, można uznać za takie same, jeśli eksperci od
> razu nie są jednoznaczni - ale nie ma sensu brnąć dalej.

I w ten sposób może się okazać, że nie zabrniemy za daleko.

> > Też nie wiem. Prawdopodobnie nie można, tym bardziej, że
> > nie umiemy nawet uściślić, co to znaczy "lepiej tłumaczyć tekst"
> No więc właśnie. Co z tego, że nawet jeśli są jakieś znikome
> szanse na udowodnienie poprawności programu, to zwykle nie ma
> żadnych szans, czy program, choć jest poprawny, to realizuje
> zamierzony cel.

Pytanie, które chcemy sobie zadać, brzmi: w jakim zakresie
istnieje potrzeba udowodnienia tego, że program zachowuje
określone niezmienniki? Podane przez Ciebie przykłady całkowicie
chybiają. Koledzy podają przykłady np. sterowników hamulców
w samochodzie. Inny prosty przykład, to udowodnić, że urządzenie
odpowiedzialne za zmianę świateł na skrzyżowaniu nie dopuści
nigdy do tego, że dla obu kierunków skrzyżowania nie będzie
się paliło jednocześnie zielone światło.

> > Ale niestety Twoje użycie słowa "najlepszy" jest nieprecyzyjne,
> > bo "najlepszy" może być również w sensie "maintainability" -- że
> > ma najlepsze komentarze, jest najłatwiej rozszerzalny itd.
> Oczywiście że może. Przecież to jest bardzo często spotykany
> wymóg. Ja np. mam sprzeczne wymogi: program ma być wydajny, ma
> obsługiwać bardzo dużą ilość użytkowników na tanim sprzęcie i
> jednocześnie ma być bardzo podatny na zmiany, żeby szybko go
> rozbudowywać.

A gdzie jest ta sprzeczność?

> > > > Nieprawda. To, jak się coś skonkretyzuje (oraz co się skonkretyzuje),
> > > > ma kluczowe znaczenie dla łatwości/trudności przeprowadzenia dowodu.
> > > Może czegoś nie wiem, dla jakich kryteriów dowód będzie łatwy w
> > > przeprowadzeniu?
> >
> > Nie rozumiem o co pytasz. W ogólności zależy to od przypadku.
> Pytam o to, jakie miałeś na myśli przypadki, gdy pisałeś, że
> może dowód być łatwy.

Na przykład wspominany przeze mnie przypadek, że funkcja append
jest operatorem łącznym.

> > > > owo polecenie. Deadlocka otrzymamy w każdym przypadku, gdy którykolwiek
> > > > z wątków w danej jednostce uruchomieniowej nie wywoła polecenia
__syncthreads().
> > > Nigdy nie używałem tego polecenia. Czy jest konieczne używanie?
> > > Co ono usprawnia?
> >
> > Umożliwia synchronizację wątków przed dostępem do pamięci.
> Po to jest prawie każda synchronizacja, a jeśli słowo pamięć
> zmienimy na zasób, to chyba dosłownie każda.

No widzisz.

> > Jeśli Cię to bardziej interesuje, polecam kurs z "Heterogenous Parallel
> > Programming" na Courserze albo książkę "CUDA w przykładach" (wyd. Helion)
> Nie mam aż tyle czasu, myślalem że rzucisz kilka zalet.

Zalet synchronizacji wątków przed dostępem do pamięci?

> > Nie. Każdy wątek może bezpiecznie wywołać __syncthreads i nie ma potrzeby
> > zabezpieczania jej semaforami,
> Nie pisałem że trzeba ją zabezpieczać semaformai, tylko że trzeba ją
> traktować jakby była zabezpieczona według takiego schematu.

I co to nam daje, w sensie udowodnienia, że program nie ma deadlocka?

do góry

W dniu środa, 1 kwietnia 2015 15:31:27 UTC+2 użytkownik g...@g...com napisał:
> > > Jeśli Cię to bardziej interesuje, polecam kurs z "Heterogenous Parallel
> > > Programming" na Courserze albo książkę "CUDA w przykładach" (wyd. Helion)
> > Nie mam aż tyle czasu, myślalem że rzucisz kilka zalet.
>
> Zalet synchronizacji wątków przed dostępem do pamięci?

Tak sobie myślę, że chyba niezbyt ładnie się zachowałem,
pisząc to, co napisałem powyżej, bo mogłoby to zostać
odebrane jako pogardliwe, a nie chciałbym, żeby tak było.
Przepraszam. (Z żalem przyznam, że to chyba "dyskusje"
z niektórymi osobami na tej grupie tak mnie zdegenerowały,
choć oczywiście nie ma się co obwiniać, a trzeba pracować
nad tym, żeby było lepiej)

To jest trochę (bardzo?) OT, ale nowoczesne procesory graficzne
pozwalają tworzyć programy zawierające tysiące wątków
(z których docelowo może nawet wszystkie będą się mogły
wykonywać równolegle). Klasyczny przykład to dodawanie
wektorów: zamiast wykonywać pętlę dodającą po kolei
tysiąc par elementów, możemy uruchomić tysiąc wątków, z których
każdy doda po jednej parze elementów.

Oczywiście przykład z dodawaniem wektorów nie jest szczególnie
porywający, zaś kolizje z dostępem do pamięci w tak prostym
przypadku nie zachodzą.

Gorzej jeżeli mamy kilka etapów obliczeń: może być tak, że
fragment pamięci, do którego zapis wykona kilka wątków
na jednym etapie, będzie potem użyty do obliczeń na innym
etapie. Żeby jednak mogło się tak stać, musimy się upewnić,
że wszystkie wątki skończyły już zapis -- i do tego właśnie
używa się __syncthreads()

do góry

W dniu wtorek, 31 marca 2015 23:32:32 UTC+2 użytkownik Andrzej Jarzabek napisał:

> Bo byś kalkulował co najlepsze dla ciebie jako pracownika etatowego, czy
> również dlatego, że jako profesjonalista podejmowałbyś decyzje twoim
> zdaniem najlepsze dla firmy?

Jako profesjonalista nie rozdzielam tych dwóch rzeczy. :-)
Zauważyłem też, że w profesjonalnych firmach te dwie rzeczy są zgodne.

Czyli tak, zrobiłbym system finansowy tak jak opisałeś, bo jest to per saldo plus
zarówno dla firmy jak i dla mnie.

> Korzystając z komfortu braku konieczności
> wybierania między maksymalizacją zysku a minimalizacją ilości trupów...

Właśnie ten komfort miałem na myśli opisując dynamikę czynników biorących udział w
wywieraniu presji na decyzje merytoryczne. :-)

Cieszę się, że jesteśmy zgodni w tej ocenie.

A teraz albo wracamy do programowania albo odpinam się z tej dyskusji.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

On Wed, 1 Apr 2015 08:25:55 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:
> Jako profesjonalista nie rozdzielam tych dwóch rzeczy. :-)
> Zauważyłem też, że w profesjonalnych firmach te dwie rzeczy są zg=
> odne.

Nigdy całkowicie nie są.

RW

do góry

On Wednesday, April 1, 2015 at 5:10:22 PM UTC+2, g...@g...com wrote:
> W dniu środa, 1 kwietnia 2015 15:31:27 UTC+2 użytkownik g...@g...com
napisał:
> > > > Jeśli Cię to bardziej interesuje, polecam kurs z "Heterogenous Parallel
> > > > Programming" na Courserze albo książkę "CUDA w przykładach" (wyd. Helion)
> > > Nie mam aż tyle czasu, myślalem że rzucisz kilka zalet.
> >
> > Zalet synchronizacji wątków przed dostępem do pamięci?
>
> Tak sobie myślę, że chyba niezbyt ładnie się zachowałem,
Podając linki do literatury? To akurat bardzo w porządku. Mnie
się nie chciało już tłumaczyć, że słowo "precyzja" zmienia
znaczenie zależnie od kontekstu. Nie chce mi się precyzyjnie
tłumaczyć za każdym razem jak używam każdego słowa.

> pisząc to, co napisałem powyżej, bo mogłoby to zostać
> odebrane jako pogardliwe, a nie chciałbym, żeby tak było.
> Przepraszam. (Z żalem przyznam, że to chyba "dyskusje"
> z niektórymi osobami na tej grupie tak mnie zdegenerowały,
> choć oczywiście nie ma się co obwiniać, a trzeba pracować
> nad tym, żeby było lepiej)
Nie ma nic pogardliwego w podaniu linku do literatury.


> To jest trochę (bardzo?) OT,
Nie jest OT, rozmawiamy od dowodzeniu poprawności równoległego programu.

> ale nowoczesne procesory graficzne
> pozwalają tworzyć programy zawierające tysiące wątków
Rzecz jasna.

> (z których docelowo może nawet wszystkie będą się mogły
> wykonywać równolegle). Klasyczny przykład to dodawanie
> wektorów: zamiast wykonywać pętlę dodającą po kolei
> tysiąc par elementów, możemy uruchomić tysiąc wątków, z których
> każdy doda po jednej parze elementów.
Choć nie programuję procesorów graficznych, to tak to sobie
wyobrażałem.


> Oczywiście przykład z dodawaniem wektorów nie jest szczególnie
> porywający, zaś kolizje z dostępem do pamięci w tak prostym
> przypadku nie zachodzą.
Trochę szkoda, że podałeś przykład, w którym syncthreads się
nie przyda.

> Gorzej jeżeli mamy kilka etapów obliczeń: może być tak, że
> fragment pamięci, do którego zapis wykona kilka wątków
> na jednym etapie, będzie potem użyty do obliczeń na innym
> etapie. Żeby jednak mogło się tak stać, musimy się upewnić,
> że wszystkie wątki skończyły już zapis -- i do tego właśnie
> używa się __syncthreads()
Ja bym to inaczej uzasadnił, choć nigdy nie używałem takiej metody.
Mamy np. trzy wątki. W pierwszym etapie watek pierwszy dostaje dane spod
adresów 0,1,2, drugi spod: 3,4,5, trzeci spod: 6,7,8. W drugim etapie
wątek pierwszy dostaje dane 0,3,6; drugi 1,4,7; w trzecim 2,5,8.
Wtedy istotnie muszą wszystkie wątki czekać pomiędzy etapami.

Pozdrawiam

do góry