Autor: Krzysztof Halasa (khc_at_intrepid.pm.waw.pl)
Data: Thu 05 Mar 1998 - 19:41:31 MET
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.
> 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).
> 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.
> 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.
> 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.
> >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.
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.
> 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.
-- Krzysztof Halasa Network Administrator of The Palace of Youth in Warsaw
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 17:04:31 MET DST