Autor: Andrzej Lewandowski (lewando_at_ibm.net)
Data: Sat 07 Mar 1998 - 03:01:19 MET
Krzysztof Halasa <khc_at_intrepid.pm.waw.pl> wrote:
>lewando_at_ibm.net (Andrzej Lewandowski) writes:
>> Niekoniecznie zaraz synchronizacja. Czasami wlasciwosci samego
>> problemu (nawet rozwiazywanego na idealnej teoretycznej maszynie
>> rownoleglej zwanej PRAM) nie pozwalaja na uzyskanie liniowego
>> przyspieszenia. Prykladem sa algorytmy "divide and conquer" ktore w
>> oryginalnym sformulowaniu nie pozwalaja na uzyskanie przyspieszenia
>> lepszego niz logarytmiczne.
>Jak dla mnie to nie ma znaczenia - albo jeden z "procesow" musi czekac
>na drugi (np. na wyniki z niego), albo nie musi.
Dla mnie ma. Bo jak cos z zasady nie da sie przyspieszyc, to zebym
stanal na uszach nic nie da sie zrobic. Natomiast twoja uwaga jest
rzeczywiscie odkrywcza.
>> Dlatego ze w Smalltalku robi sie 100 razy szybciej niz w... Nie mowiac
>> ze przyjemniej.
>Tzn. robi sie program czy program robi wyniki? Bo moze lepiej poswiecic
>kilka razy wiecej czasu na program, zeby wyniki byly szybciej?
>W te 100 razy to chyba sam nie wierzysz, chociaz nie znam smalltalka
>(trudno mi jest jednak wyobrazic sobie taki jezyk, z taka szybkoscia
>_byc_moze_ da sie wytlumaczyc komus istote algorytmu, ale nie napisac
>program).
Prowadzimy dyskusje akademicka.
>> No dziekuje - salesman prosty... Ale dla jakiej wymiarowosci jest on
>> prosty?
>W sensie algorytmu? Dla kazdej. Tylko wzrasta czas obliczen, ale
>nie ma to wielkiego zwiazku z prostota algorytmow. Problem bylby
>wtedy, gdyby algorytm byl nieprzydatny ze wzgledu na zbyt duzy koszt
>obliczeniowy.
Prowadzimy dyskusje akademicka.
>> Na dodatek to nie jest travelling salesman, tylko cos co sie
>> mazywa "multiple-depot periodic vehicle routing". Niewiele ma
>> wspolnego z salesmanem, i metodami specyficznymi dla salesmana nie da
>> sie go rozwiazac.
>Tzn. jakimi metodami? Bo jest wiele metod, i przypuszczam, ze przynajmniej
>niektore bylyby zupelnie dobre.
Prowadzimy dyskusje akademicka.
>> W ogolnosci, bardzo malo jest wiadomo na temat
>> dobrych metod rozwiazywania tego problemu, zwlaszcza takich o
>> wymiarowosci "wzietej z zycia". Jezeli potrafisz to zrobic prosto -
>> prosze bardzo, zrob, napisz papier - slawa (i pieniadze) gwarantowane.
>Widzisz - tak sie sklada, ze slawy nie potrzebuje, na ilosc pieniedzy
>tez nie narzekam, a lubie zajmowac sie innymi nieco rzeczami.
>Np. administrowaniem systemu UNIX. Albo sieciami komputerowymi.
>Albo np. bezpieczenstwem systemow w takich sieciach. I tez niespecjalnie
>lubie pisanie na ten temat papierow.
No i wlasnie na tym rzecz polega. Zajmujemy sie innymi rzeczami, mamy
inne doswiadczenie, i inny punkt widzenia. Ja sie nie wypowiadam na
temat administrowania sieciami bo tego nie robilem i sie na tym nie
znam. Znam sie jednak na tyle zeby wiedziec ze jest to bardzo daleke
od obliczen rownoleglych, optymalizacji kombinatorycznej, zlozonosci
algorytmow, technologii obiektowej oraz prowadzenia projektow
programistycznych w ktorych pracuje, powiedzmy, kilkadziesiat osob.
Na kazdy z powyzszych tematow ktory okresllem jako "dyskusje
akademicka" musialbym napisac esej zeby sie ustosunkowac. Raczej
brakowi ekspiriencji nalezy przypisac fakt ze w kazdym z tych tematow
wypowiadasz sie ze znawstwem i autorytatywnie. Tylko ze od tego
znawstwa opadaja rece i co tam moze jeszcze opasc...
>> >Oczywiscie, sam algorytm to nie wszystko, ale w takim razie jest
>> >to raczej prezentacja/bazy_danych/zarzadzanie + maly kawalek kodu
>> >(liczacy sie dlugo) na TSP.
>>
>> To nie jest MALY kawalek kodu.
>Nie wiem. Ale jednak przypuszczam, ze algorytm rozwiazywania takiego
>problemu nie musi byc dlugi. Nie wiem oczywiscie co rozumiesz przez
>MALY, ani jak sie zapisuje algorytmy w smalltalku - w assemblerze
>pewnie tez bylby to wiekszy kawalek, ale wydaje mi sie, ze smalltalk
>wlasnie tym rozni sie od assemblera.
Pisales kiedys cos takiego?
>Mi na przyklad bardzo milo pisze sie w C i w C++ (w zaleznosci od
>potrzeb), i przewidywana objetosc takiego algotytmu w C++ oceniam
>jako niezbyt duza.
Jak powyzej i powyzej.
>> Nie da sie, bo trzeba by wszystkie obiekty przekonwertowac do jakiejs
>> takiej postaci zeby "to cos innego" moglo je zrozumiec. Co by bylo
>> dosyc kosztowna operacja. Probowano, a jakze. A tak na marginesie,
>> probowano tez "cos innego". Pod UNIXem, a jakze. Nie NT, nie Wintel.
>> Za 10 albo 20 razy wiecej pieniedzy. 2 - 3 razy wolniej. A na pewno
>> nie szybciej.
>Tak, slyszalem. Na serwerze [typu np. plikow]. Dla scislosci, to chyba
>nie pod UNIXem, a pod AIXem.
>Moze to rzeczywiscie nie bylo najlepsze wyjscie, do obliczen sa naprawde
>lepsze komputery.
>--
Jak powyzej, powyzej i powyzej.
>Network Administrator of The Palace of Youth in Warsaw
No i wlasnie - nie ublizajac Palacowi Mlodziezy ktorego jestem
wychowankiem - rezczywistosc widziana z perspektywy Palacu Mlodziezy
rozni sie troche od rzeczywistosci widzianej z perspektywy srednio
duzej firmy produkujacej na rynek.
A.L.
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 17:04:31 MET DST