Windows Vista: ulteriori ritardi secondo Gartner

[mjordan]

Originariamente inviato da sirus

Non vorrei sbagliare ma anche Windows ha questo limite (Windows 32bit si intende), i processi possono sfruttare al massimo 3GB di memoria, il resto è utile solo come buffer, stessa cosa anche su Linux!

Si lo ha anche Windows. Linux invece riesce a gestire tutta la memoria disponibile. In ogni caso entrambi i sistemi, quando non riescono ad allocare memoria (vuoi per un limite fisico, vuoi per un limite del kernel), iniziano a paginare. MacOSX sui 32 bit, crasha.
Avevo trovato un programmino che exploitava il problema. Se lo ritrovo lo posto
Criceto ovviamente per far fronte all'argomento, ricorre al discorso dei 64 bit, che non sono mai stato oggetto di questa questione.

[bjt2]

Dunque, facciamo chiarezza.

In un S.O. a 32 bit, la quantità massima di memoria indirizzabile da un processo (COMPRESI FILES MAPPATI IN MEMORIA) è 4GB. Nei sistemi windows non server, tale memoria è divisa in 2GB per il kernel (NON UTILIZZABILI IN ALTRO MODO, ma credo che comprendano i files mappati in memoria, almeno lo spero) e 2GB per il codice ed i dati del processo utente. Sui sistemi windows server è possibile stabilire un'altra divisione fino ad un massimo di 3GB per il processo utente e 1GB per il kernel. In Linux, dipende da come si compila il kernel, ma in genere è compilato per i 3GB/1GB, che è la soluzione migliore per molti scopi. Anche qui è configurabile. Da quello postato sopra, si evince che il kernel di Mac OS X è compilato per 2GB/2GB come i sistemi windows consumer. Spero che le versioni server siano compilate per 3GB/1GB, perchè in caso di grossi DB serve più RAM per il processo (in genere il buffering lo fa il DBMS non appoggiandosi al file system). Ma i 3 GB servono anche in casi come sopra (il CAD) ed elaborazioni numeriche. Per esempio io con Matlab riesco ad allocare una singola variabile di 900MB su Linux, mentre in windows massimo di 500MB. Oltre da out of memory, anche se ce n'è molta disponibile. Allocando più variabili piccole, riesco comunque a superare questo limite (sono arrivato a 1GB di memoria virtuale occupata da Matlab), ma credo che la frammentazione dei 2GB tra codice, dati, stack ed heap, non mi consenta di sfruttare più di tanto...

[MenageZero]

Originariamente inviato da bist

Sì però fanno cagare : )
Soprattutto perché non indicizzano alla creazione/eliminazione/modifica di un file, ma bisogna aspettare il computer sia in idle perché si indicizzi l'hd (oppure dirglelo manualmente).

beh, su quale tool sia meglio non posso dire(e infatti non l'ho detto ) niente in quanto non li ho mai usati per un tempo significativo né soprattutto ho né mai usato per un po' un mac con spotlight

però indicizzare nei cicli di idle dovrebbe essere corretto almeno teoricamente come approccio in quanto dovrebbe minimizzare l'overhead dell'indicizzazione (soprattutto nei casi ad es di azione su grandi quantità di dati,come mb e principalmente come num. di files) e in un uso desktop di un pc lo stato di idle dovrebbe essere statisticamente molto frequente...

... se invece tale aproccio risulta all fine nell'avere quando vai fare una ricerca un'indicizzazione troppo poco aggiornata,e neanche si aggiorna automaticamente con la query(o ci mette troppo tempo), per risultare veramente utile, beh allora suppongo si possa convenire copn te che... favoriscano l'attività intestinale...

[MenageZero]

Originariamente inviato da mjordan

Non riguarda piu' processi, dove hai visto 100 processi contemporaneamente mica l'ho capito
Riguarda la memoria indirizzabile da un singolo processo e non è affatto un parametro modificabile ma un limite intrinseco del kernel di MacOSX sui 32 bit. Anche Photoshop ha lo stesso identico problema. Non dipende dalle API che citi, sono proprio limiti del memory manager del kernel.

è bello vedere come a volte ci si intenda "al volo" ...