Linux-Bulgaria.ORG
навигация

 

начало

пощенски списък

архив на групата

семинари ...

документи

как да ...

 

 

Предишно писмо Следващо писмо Предишно по тема Следващо по тема По Дата По тема (thread)

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
============================================================================




 

наши приятели

 

линукс за българи
http://linux-bg.org

FSA-BG
http://fsa-bg.org

OpenFest
http://openfest.org

FreeBSD BG
http://bg-freebsd.org

KDE-BG
http://kde.fsa-bg.org/

Gnome-BG
http://gnome.cult.bg/

проект OpenFMI
http://openfmi.net

NetField Forum
http://netField.ludost.net/forum/

 

 

Linux-Bulgaria.ORG

Mailing list messages are © Copyright their authors.