> in continuare te intreb, tu iti dai seama cat de incet va merge? asta
> este foarte similar cu swapul.Gandeste-te cum ar fi sa ai un program
> cu branchuri mai multe si mai departate.Pe sistemul asta ai numara
> secundele pana se executa ala.Nu cred ca e doar atat, sau are
> read-aheadul destul de mare.
Paginile raman rezidente (in afara de situatia extrema in care e
nevoie de memoria pe care o ocupa), nu se evacueaza cand nu trece
executia prin ele...
Branch-urile de care vorbesti tu (cazul cel mai defavorabil...) sunt
de doua feluri:
- la biblioteci, care de obicei sunt partajate intre procese si au
cele mai des apelate rutine deja rezidente
- in programele foarte mari, intre module, dar si acolo exista
"locality" pe seturi
Branch-uri aiurea de colo-colo nu prea exista, in practica :-) decat
poate la programe scrise in fortran sau mai stiu eu ce...
Nu inteleg ce incerci sa spui ca ar merge incet... Asa merge...
/usr/src/linux/fs/exec.c:
/*
* Demand-loading implemented 01.12.91 - no need to read anything but
* the header into memory. The inode of the executable is put into
* "current->executable", and page faults do the actual loading. Clean.
*
* Once more I can proudly say that linux stood up to being changed: it
* was less than 2 hours work to get demand-loading completely implemented.
...
Daca vrei sa te convingi ca treaba asta nu e hotaratoare pentru viteza
de executie a programelor sub linux (BTW, orice unix face la fel,
probabil ca pana si windows-ul face la fel), ruleaza "vmstat 1" intr-o
fereastra si o sa vezi ca, in timpul executiei programelor nu e asa
mare activitate de I/O. Uite, eu am acum vreo 8 xterm-uri, xemacs,
netscape pornite si ascult niste mp3-uri din retea cu xmms:
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
0 0 0 79820 11728 0 41804 0 0 0 0 322 802 0 3 97
1 0 0 79820 11732 0 41804 0 0 0 0 351 896 2 4 94
0 0 0 79820 11728 0 41804 0 0 0 0 354 1091 6 5 89
0 0 0 79820 11728 0 41804 0 0 0 0 340 914 3 2 95
0 0 0 79820 11728 0 41804 0 0 0 0 349 937 5 2 93
0 0 0 79820 11728 0 41804 0 0 0 0 350 923 3 2 95
0 0 0 79820 11728 0 41804 0 0 0 0 337 974 5 0 95
0 0 0 79820 11728 0 41804 0 0 0 0 337 886 1 4 95
0 0 0 79820 11728 0 41804 0 0 0 0 345 935 6 3 91
0 0 0 79820 11728 0 41804 0 0 0 0 353 910 3 2 95
0 0 0 79820 11728 0 41804 0 0 0 0 346 949 3 2 95
4 0 0 79820 11728 0 41804 0 0 0 0 351 937 29 2 69
9 0 0 79820 10564 0 41804 0 0 0 8 421 1004 13 6 81
3 0 0 79820 10948 0 41808 0 0 0 32 458 1448 55 11 34
0 0 0 79820 10944 0 41808 0 0 0 0 456 1236 2 3 95
0 0 0 79820 10944 0 41808 0 0 0 0 367 910 9 3 88
1 0 0 79820 9844 0 41820 0 0 4 16 436 1116 7 6 87
0 0 0 79820 9836 0 41828 0 0 8 0 361 932 2 3 95
0 0 0 79820 9828 0 41836 0 0 4 20 387 1017 1 3 96
Uita-te la 'bi', 'bo' (blocks in/out).... si la swap...
Un sistem care are memorie adecvata pentru ce are de facut, ajunge la
un moment dat intr-o stare stabila. Daca swap-eaza in continuu, normal
ca numeri secunde (sau minute), dar nu cred ca la asta te refereai...
In realitate, faptul ca paginile programului nu sunt in memorie
conteaza doar la startup, care e oricum mai rapid decat in situatia in
care ar fi incarcate TOATE paginile deodata :)
Si, daca vrei cazuri extreme, altfel nu ai putea rula programe mai
mari decat memoria fizica disponibila :-)
Matei
---
Pentru dezabonare, trimiteti mail la
[EMAIL PROTECTED] cu subiectul 'unsubscribe rlug'.
REGULI, arhive si alte informatii: http://www.lug.ro/mlist/
