🚀 go-pugleaf

Date sent:      	Fri, 19 Feb 1999 13:24:52 +0100
Send reply to:  	objects@sprocket.ict.pwr.wroc.pl
From:           	Kalafiorczyk <simg@netcom.com>
To:             	Multiple recipients of list <objects@sprocket.ict.pwr.wroc.pl>
Subject:        	Glos na temat zasad dyskusji naukowej

> Z gory prosze o wybaczenie. Jestem tylko skromnym magistrem inzynierem,
> a nie doktorem nauk jak Panowie Subieta i Lewandowski. Zmuszony
> jednak jestem otwarcie poprosic obu Panow o bardziej powazne 
> zachowywanie sie w dyskusji na forum publicznym.
> 
> Ja napisalem:
> > http://www.harlequin.com/mm/reference/ 
> > Prosze tam poszukac informacji na temat 'incremental garbage
> > collection' and 'tri-color marking'.
> 
> Na co Pan Subieta odpisal:
> > Zgoda. Np. reference count. Ale ta metoda ma inne wady.
> Uwazam, ze opisywanie wad 'reference counting' jako odpowiedz
> na wzmianke o 'tri-color marking' jest cokolwiek bez sensu.
> 
> Z kolei Pan Lewandowski napisal:
> > 1. Reference count to smietnik historii,

OK, zarowno u mnie jak i u Pana Subiety na slowo "reference" 
zadzialal odruch Pawlowa... Do tej poty "harlequin" kojarzyl mi sie 
z Lispem, jakos nie zajrzalem pod "reference". Mam swoje 
pointery do stron na temat "garbage collection", o czym zreszta 
donioslem. Anyway, na przyszlosc bede uwazal.

> Uwazam, ze umieszczanie metody 'reference count' na smietniku
> historii jest mocno przedwczesne. Dla przykladu w calkiem
> nowoczesnym jezyku Python jest to podstawowa metoda zarzadzania
> pamiecia. Co wiecej: Visual Basic z cala pewnoscia uzywa
> 'reference counting' to zarzadzania obiektami COM i/lub OCX.
> Ponadto, zarzadzanie pamiecia na lancuchy tekstowe w Basicu
> jest rowniez oparte o ta metode. 

Jednak, przynajmniej jak dla mnie jest to smietnik 
historii.Przypuscmy, ze Gmina Paczkow Dolny z powodu braku 
komunikacji ze Stolica i braku funduszy na autobus postanowila 
zafundowac sobie dylizans. Nowoczesny, z aerodynamiczna buda 
i hamulcami tarczowymi. Oczywiscie, problemy komunikacyjne 
Gminy zostana przynajmniej czesciowo eozwiazane, nie zmieni to 
jednak mojego pogladu na fakt ze dylizans to jest smietnik historii.

Jak zas idzie o odsmiecanie:

1. Wedle mojej najlepszej wiedzy Python nie ma odsmiecacza, 
przynajmniej dosyc swieza wersja ktora mam na swoim 
komputerze. MA MIEC, w przyszlosci, ale to bedzie Boehm, a nie 
reference coutning. Na razie ma, owszem, reference counting, ale 
to programista musi manualnie ten counter aktualizowac, i jedyne 
co moze z nim zrobic to sprawdzic jaka ma wartosc. Dosyc 
kiepski...

2. Rzeczywiscie, COM ma reference counting. Ale nie z milosci do 
tegoz tylko z powodu takiego ze to jest jedyne dobre rozwiazanie 
dla komponent dzialajacych w nie znanym z gory srodowisku. 
Zreszta, w srod programistow stosujacych COM prowadzone sa 
bez przerwy dyskusje na taki temat zeby nie zapomniec 
zdekrementowac licznika, a wsrod programistow VB wiedzacych 
co to COM do ulubionych tematow nalezy problem co zrobic z 
"circular references". Patrz ostatnie numery VB Journal + bardziej 
zaawansowane ksizaki na temat VB (tytulami sluze).

3. Na dodatek, reference counting ma dosyc duzy "overhead" - oto 
mianowicie KAZDA operacja alokowania - zwalniania pamieci musi 
poswiecic kiloa cykli CPU na administracje. Inne, nowsze pomysly 
uzywaja CPU tylko wtedy gdy trzeba odsmiecic. Porownanie 
efektywnosci reference counting z innymi odsmiecaczami jest w 
papierach wymienionych na podanej przez Pana stronie.

Teraz odbije pileczke. Pan Kalafiorczyk napisal:

"..
Ja bardzo lubie czytac historyjki Doktora Lewandowskiego.
Ale znowu zmuszony jestem Go porawic. Od wielu lat znane sa 
metody pozwalajace na odsmiecanie bez zatrzymywania dzialania 
programu..."

Ja bardzo przepraszam, to znaczy jak one dzialaja? Nadswietlnie? 
Telepatycznie? W koncu odsmiecacz to tez program i niezaleznie 
od tego jaki wykonuje algorytm, aby sie wykonal musi uzyc pare 
cykli CPU. W czasie jak te cykle uzywa to program wlasciwy sie 
nie wykonuje. Wszystko mi jedno, czy przez pol godziny czy 
przez pol milisekundy. ZATRZYMUJE SIE I JUZ! Najgorsze ze nie 
wiadomo na jak dlugo.

Aby Pana przekonac, specjalnie wykonalem eksperyment w 
Smalltalku. Smalltak ma najbardziej zaawansowane odsmiecacze -
 ludzie mieli dosyc czasu zeby je udoskonalic. Oto program:

	A1 := OrderedCollection new.
	B1 := OrderedCollection new.
	C1 := OrderedCollection new.
	D1 := OrderedCollection new.
	E1 := OrderedCollection new.

	1 to: 2000000 do: [:i| A1 add: i].

	X := Time millisecondsToRun:[
		B1 := A1 copy.
		C1 := A1 copy.
		D1 := A1 copy.
		E1 := A1 copy].  
	 
	Y := Time millisecondsToRun:[
		B1 := A1 copy.
		C1 := A1 copy.
		D1 := A1 copy.
		E1 := A1 copy].  
	Transcript show: X printString, ' ', Y printString; cr

Nawet jak Pan nie zna Smalltalka, to nic nie szkodzi. Oto kreuje 5 
pustych kolekcji, potem pod jedna podstawiam 2 miliony 
integerow, a potem wykonuje dwa identyczne a proste kawalki 
programu. Wszyctko chodzi na maszynie ktora ma 256 MB 
pamieci, wiec jest tej pamieci od groma. Oto co Smalltalk pisze:


995 4158
993 4187
984 4159
984 4162
984 4170

visualnctest.im created at February 19, 1999 8:27:55 pm

Pierwsza grupa operacji wykonuje sie 4 razy szybciej niz taka 
sama, druga grupa. Dlaczego? Ano, prosta sprawa - mamy po kolei

	B1 := A1 copy
	...
	B1 := A1 copy.

Jak sie wykonuje drugie podstawienie, to poprzednia zawartosc B1 
zostaje odsmieciowana. Tak wiec porownanie 995 i 4158 daje nam 
poglad o nakladzie pracy wykonywanej przez odsmiecacz. 

Cala sprawa nie jest naukowa i hipotetyczna. W dosyc duzym 
projekcie musialem napisac swoja wlasne kolekcje tak aby 
uniknac odsmiecania. Poniewaz w Smalltalku nie mozna 
odsmiecania wylaczyc, tzreba bylo zrobic tak, zeby nie 
nastepowala dereferencja. Niepotrzebne obiekty trzeba bylo 
trzymac w specjalnej kolekcji, skad sie je pobieralo jak sie chcialo 
utworzyc nowy obiekt. Naprzeklinalem sie odsmiecacza co 
niemiara i niejeden siwy wlos w mojej brodzie stad pochodzi...

Stad wniosek, ze nie wszystko zloto co sie swieci....

A.L.