🚀 go-pugleaf

Andrzej Rosa <bakters@yahoo.com> wrote:
> On 2011-04-17, Piotr B. [pb2004] <p_borkowski@nospamgazeta.pl> wrote:
>> Andrzej Rosa <bakters@yahoo.com> wrote:
>>> Ram też się marnuje.  
>>
>>> Na ten przykład dla firefoksa:
>>> $ pmap 16657 | ack total
>>> total   336252K
>>
>>> $ free -m
>>>             total       used       free     shared    buffers     cached
>>> Mem:           753        475        277          0          7        325
>>> -/+ buffers/cache:        142        611
>>> Swap:          956         15        941
>>
>>> Normalnie cuda...
>>
>> Jakie cuda? Chyba nie uważasz że developerzy Linuksa są głupcami i 
>> niezmienione strony pamięci z plików które są już na dysku będą drugi 
>> raz zapisywać w swapie.

> One są w pamięci, nie na dysku.

Doczytaj o demand paging. One znajdą się w pamięci RAM gdy będą 
potrzebne.

>  Firefox spawnuje ileś tam child
> processes o tej samej zawartości, które są w 100% dzielone, stąd
> rozbieżność.

Mylisz Fxa z Chrome lub IE. Poza tym to jest normalne rozwiązanie w 
każdym systemie. Żaden współczesny system nie duplikuje identycznych 
stron w pamięci.

>>> P.S. - Poczytałem trochę, żeby przypadkowo jakiejś durnoty nie wysłać i
>>> się doczytałem, że Windows nie ma shared libraries.   
>>> http://en.wikipedia.org/wiki/Position_independent_code#Windows_DLLs
>>
>>> Microsoft Windows DLLs are not shared libraries in the Unix sense and do not
>>> use position independent code. This means they cannot have their routines
>>> overridden by previously loaded DLLs and require small tricks for sharing
>>> selected global data. Code has to be relocated after it has been loaded from
>>> disk, making it potentially non-shareable between processes; sharing mostly
>>> occurs on disk.
>>
>> Powyższe jest bzdurą. 

> Och, to przesada.  Zgodzę się na typowy MS. ;-P

Bzdurą jest to zdanie: Code has to be relocated after it has been loaded 
from disk, making it potentially non-shareable between processes. 
Dlaczego pisałem w poprzednim poście.

>> Wirtualny adres pod jakim jest zamapowana 
>> biblioteka dll w przestrzeni adresowej danego procesu nie ma nic 
>> wspólnego ze współdzieleniem pamięci RAM. To system zarządza zawartością 
>> pamięci RAM i niemożliwe jest aby ten sam plik dll był dwukrotnie 
>> zamapowany w pamięci RAM jako wykonywalny.

> Nie rozumiesz.

> http://hackage.haskell.org/trac/ghc/wiki/Commentary/PositionIndependentCode

> Position independent code

> First, let it be said that there is no such thing as
> position-independent code on Windows. The dynamic linker will just
> patiently relocate all dynamic libraries that are not loaded at their
> preferred base address.

> Urocze.  :-)

No i? YPB?

-- 
Piotr Borkowski