🚀 go-pugleaf

Dnia Thu, 25 May 2006 18:20:41 +0200, jarekr skrobie:
> Weź sobie napisz symulator tego rozwiązania i zobacz jaka jest rónica w 
> stosunku do normalnego gc (bez operacji delete).
> Otóż ja widzę jedną istotną różnicę - obiekty długożyjące. Teraz 
> powstaje pytanie: dużo takich masz? I czy warto się w to bawić skoro
> narzut na ich śledzenie jest rozsądnie kompensowany w dowolnym 
> generacyjnym gc.

Jasne; jaka jest różnica pomiędzy "dobrze zoptymalizowanym" śledzeniem, a
brakiem śledzenia? Sam sobie odpowiedz.

Nie interesuje mnie, jaka jest różnica pomiędzy tak przedstawionym sposobem
zarządzania pamięci, a tym, co ma Java. Interesuje mnie różnica względem
tradycyjnego malloc().

> >>>Po drugie, najefektywniejszym sposobem zarządzania pamięcią obiektów,
> >>>szczególnie dużą ilością małych obiektów o krótkim czasie życia, pozostaje
> >>>alokator specjalizowany (pula przeznaczona dla obiektów tylko jednego typu).
> > 
> > 
> >>Najefektywniejszym w jakim sensie ?
> > 
> > Zużycia czasu procesora na czynności związane z przydziałem i zwalnianiem
> > pamięci przeznaczonej na obiekty.
> > 
> > 
> >>Np. w sesnie zużycia CPU to prawdopodobnie najefektywniejszym jest 
> >>dokupienie kilku terabajtów pamięci i wyłaczenie gc :-)
> > 
> > 
> > Pomińmy to milczeniem. Jeśli się nie zgadzasz - proszę bardzo, masz pole do
> > popisu, tylko konkretnie, proszę.

> Podałem rozwiązanie IMHO lepsze od twojego przy założeniu że 
> minimalizujemy użycie CPU na allokacje/deallokacje. A więc - dedykowane 
> allokatory NIE są najefektywniejsze (w podanym sensie).

Zatem, twoim zdaniem, jak firma będzie sprzedawać oprogramowanie, to do
każdego egzemplarza powinna dołączać sztukę procesora i parę kości pamięci.

Podsuń ten pomysł firmom stosującym SOA. Myślę, że bardzo im się taki pomysł
przyda.

> > 
> > 
> > Czego w powyższym zdaniu nie zrozumiałeś?
> > 

> to paragraf-mydło - wnosi nic do dyskusji. (poza jedną wskazaną nieprawdą)

Dyskusja to się, prawdę mówiąc, jeszcze nie zaczęła ;)

> > Taaa... może wybitny specjalista od języków wszelakich p. Andrzej Lewandowski
> > podpowie ci, w jaki sposób w Javie zapewnia się deterministyczność usuwania
> > obiektów.

> No właśnie: jak będzie wyglądała ta deterministyczność przy twoim 
> rozwiązaniu z trackowaniem po delete ? (zwłaszcza przy wzmiankowanej 
> "amortyzacji" i "przesuwaniu" obiektów (cokolwiek to przesuwanie nie 
> oznacza))

Dokładnie tak samo, jak to wygląda aktualnie w C++. To język C++ gwarantuje ci
ową deterministyczność, a nie podsystem alokacji pamięci, którego
zaprojektowanie leży w gestii producenta implementacji lub systemu (jeśli
implementacja zwala to na system).

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"