Re: lug-bg: Mem usage Linux&Windows
- Subject: Re: lug-bg: Mem usage Linux&Windows
- From: danchev@xxxxxxxxx (George Danchev)
- Date: Fri, 7 Feb 2003 10:11:08 +0200
On 07 02 2003 02:56, Valentin Tzankov wrote:
> George Danchev wrote:
> Tova koeto se opitvah da napravja e da serializiram
> GTK Widget-i i edni ogromni dyrvovidni structuri pod C,
> no ne e lesna rabota, mnogo e bavno, a i ste e po-evtino
> za clienta da si kupi 2048Mb RAM.
eh ne e mnogo qsno kakvo iskash da napravish, no s GTK, nezavisimo koq versiq
mogat da se pravqt ubijstveno byrzi i ubijstveno bavni programi, zavisi koj i
za kakvo gi pishe. I to ne e samo do ... kolko byrzo ti izka4a syotvetniq
dzham, a i kakvo vyrshi code-a prez tova vreme, kolko pamet (i kolko 4esto)
zaema i osvobozhdava samoto prilozhenie ostavq li mem leaks i t.n..... mislq
ve4e si ubeden 4e ot samoto prilozhenie ne mozhesh da komandvash kernel-a
dali da mqta na swap ili ne, koito i da sa mempages ;-) ... Zavisi i ot kolko
thread-a ili fork-a se systoi tvoita programa, napr. edin thread za audio,
edin za video i t.n , ste se vidish v zor dokato im sinhronizirash zada4ite
kakto iskash (tuka se iska i dobyr context switching ot strana na kernela za
da izglezda vsi4ko gladko).... ili vsi4ko e v edin thread kato pri MPlayer-a
naprimer ... Maj e naj-dobre da se govori s code, stoto ina4e si prikazvame
naizust...
> Hubava si e Java che si ima serializatzia ama zasto Swing-a e tolkova
> baven.
neznam kakvo da kazha tuka.
> Neznam dali MS gubjat na byrz disk e nezabelijimo
> osven tova kogato prilojenie e napyno nevidimo
> systo otiva v swap-a pri malko pamet i "ALT"+"TAB",
> prevkljuchvaneto se zabavja samo sys dve tri sec.
heh. mislq 4e gledash na nestata povyrhnostno ... Zavisi ot samoto prilozhenie
kolko pamet zaema v daden moment i kolko osvobozhdava v daden moment (kato
mempages)... Mozhe prilozhenieto da e "kazalo" *ptr = (void *)calloc(5000000,
sizeof(int)) i sled tova kato napravish nesto si da pravi free(ptr);...
Tova 4e se osvobozhdava RAM hi4 ne zna4i 4e tezi pages otivat v swap-a...
Prilozheniqta iskat ili osvobozhdavat pamet ot sistemata, a tq reshava dali da
swap-va ili ne i koga (v koj moment) i kak (s kakva intenzivnost)... t.e. da
im razhvyrli i sybira tehnite data po stranicite iz rama i swap-a (ako go
ima)... Tozi diapazon ot mempages go preravq samiq kernel... prilozheniqta
(mogat da sa ot mngo procesi - fork, threads) "neznaqt" to4no kyde sa im
stranicite... Ako opitat da pishat po 4uzhdi memranges, to rabota na kernel-a
e da gi ivedomi 4e tova e neprili4no povedenie. Ako se opitat za iskat
prekaleno mnogo mempages i sa nastoqtelni (pove4e otkolkoto ima nali4ni v
sistemata) to rabota na kernel-a e da gi uvedomi 4e sa tova e neprili4no
povedenie.
> Pri Linux ako startirash process kojto da izjade pammeta,
> ste minat minuti za da privkljuchish s "ALT"+"TAB" .
heh, a pri emes kak e ? pri kojto i da e kak e v takyv slu4aj... Obektivno
sravnenie i test trudno ste izsimulirash .... zavisi kolko pamet e zaeta i ot
kyde kernel-a ste trqbva da "vadi" prilozhenieto koeto si poiskal (t.e. da mu
sybira negovite mempages, i to ne vinagi vsi4ki)... Za tova Linux keeps in
mem cache dokato ima vyzmozhnost... No za da si pozvolish tozi luks s
cache-vaneto trqbva kernel-a byrzo da mozhe da alokira, mesti i osvobozhdava
pamet kogato tova se nalaga... katoprez tova vreme prodylzhava da
context-switch-va drugite procesi za da izglezhda vsi4ko gladko ...
> Mislja che MS mnogo dobre si sinchronizirat
> kernel-a i gui-to,
az mislq 4e ot psihologi4eska gledna to4ka kogato zabravish vsi4ko ostanalo i
"pokazhesh" na potrebitelq dzham mnogo byrzo toj si misli 4e programata mu
raboti byrzo ;-) ... Tova e mngo dale4 ot postiganeto na golqma obsta
proizvoditelnost ... nisto 4udno nqkoj 4asti ot grafi4niq interface pri emes
da rabotqt v kernel space (vypreki 4e ot NT 4 maj sa na microkernel i ne se
znae koq 4ast kyde mozhe da e implementirana da raboti t.e. na koj cpu ring,
ako znaesh kakvo e tova)
> vjarno e che kato ti zabie XServer-a linux-a
> si prodyljava da raboti
XFree86 e edno ot malkoto priozheniq na koeto po4ti vsi4ki Unix-es mogat da mu
davat da pishe direktno v /dev/mem ... Tova e za byrzina, no akoXFree86
napravi losh zapis, togava sle posledva hard lockup, stoto mozhe da se omazhe
i mqstoto v pametta kydeto kernela si store-va svoite kernel-code i
kernel-data ... tova ne sym mnogo siguren dali e bash taka, imam symneniq
razni ;-)
> dokato tova ne e s NT i 2000
> ne znam kak pri XP.
zavisi ot NT nagore sa microkernel, ako bad gui code zabie, to ako e v samiq
microkernel, sledva hard lockup, ako ne e to systemata naj-veroqtno ste
prodylzhi rabota makar i s problemi ... (think GnuMach and Hurd servers...)
Vyobste rabotata e dosta po-slozhna i samo s nabludeniq ne se vadqt zaklu4eniq
... pri Unix-es graf. server e v user-space za tova mozhe da ti se struva
ponqkoga bavno, ako taka byde implementirano i pri emes neznam kolko bavno
ste da e ... Az li4no ne sym privyrzhenik xfree86 ili 4asti ot nego da bydat
nabutvani v koito i da e unix kernel ... (monolythic ili micro ...)
--
Greets,
fr33zb1
============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================
|