Newsgroup: it.comp.os.dibattiti
Titolo: Ma davvero OSX e Windows hanno questo (grossissimo) limite?

Mi riferisco ai limiti di memoria. Io ho scoperto questa cosa sconvolgente 
in questo Blog legato a Blender:
http://orange.blender.org/blog/stupid-memory-problems
Ora capisco Windows che notoriamente e' un OS nato con un sacco di 
limitazioni e retrocompatibilita', ma OSX proprio non credevo che fosse 
cosi' limitato come si dice nell'episodio raccontato. Per risolvere questo 
problema si sono addirittura inventati un file manager virtuale che mappa i 
file sul disco per bypassare la limitazione di memoria, ma non ho ben capito 
se questo incide sulle prestazioni o meno (e quanto).
Vi risulta o il tutto e' stato un po' esagerato?
Ovviamente non che siano cose false (Ton Roosendaal e' un genio, quindi se 
lo dice lui mi fido), ma che magari queste limitazioni non siano intrinseche 
come sembra invece rivelare il blog.
Ovviamente su un Linux compilato e fatto girare a 64 bit, questi problemi 
semplicemente non esistono.
Mi piacerebbe sapere cosa ne pensate.
-- 
BArrYZ
"Gli studenti sono piu' interessati a superare l'esame, che ad apprendere."
                                      [Evariste Galois 1811-1832] 

 Mi riferisco ai limiti di memoria.
Scemenze.
--
Xelloss 

 Scemenze.
Se spieghi perche', magari e' meglio.
-- 
BArrYZ
[_Sign?_] 

 CUT
OS X è 64 bit da 10.4, Win32 ... beh.
OS X ha tutt'ora la maggior parte dello userland a 32 bit, inclusi i driver
OpenGL. Il limite non è un limite ne grosso ne piccolo, c'è una piattaforma
che deve far andare innanzitutto il software esistente, se questo è una
limitazione per qualche sporadica applicazione a 64 bit amen.
  ngw

 applicazione a 64 bit amen.
A me pare una bella limitazione, invece, ma proprio tanto. Anche perche' e' 
un problema che e' quasi imprevedibile se sei in produzione (infatti questi 
poveri cristi inizialmente non riuscivano a capire perche' gli crashava a 
ruota la renderfarm, chissa' quanto tempo perso senza contare chebsi sono 
dovuti inventare la pezza per andare avanti).


 dovuti inventare la pezza per andare avanti).
Proprio no, basta una conoscenza superficiale della piattaforma su cui si
lavora. Che poi questi "poveri cristi" siano in effetti dei poveri cristi che
non sanno fare la O col bicchiere è un'altro paio di maniche.
  ngw

 Se spieghi perche', magari e' meglio.
OSX non lo conosco abbastanza bene. Su Windows a 32 bit 2 GB su 4 di spazio 
di indirizzamento sono riservati al sistema operativo, ma possono essere 
ridotti a 1 GB. A 64 bit ovviamente queste limitazioni non ci sono.
--
Xelloss 

 Se spieghi perche', magari e' meglio.
"To my big dismay it appeared that OSX only assigns processes a memory space 
of 2 GB! Macs only use the 2nd half of the 32 bits 4 GB range. this I just 
couldn't believe. it wouldn't be even possible for the OS to swap out unused 
data segments while rendering (like texture maps or shadowbuffers)."
significa solo che semplicemente non sa come funziona la gestione di memoria 
di un qualsiasi OS a memoria virtuale,
attribuendo all'OS una incapacità che invece è dell'applicativo che sta 
usando.
Senza usare sistemi di gestione dello spazio di indirizzamento tipo PAE su 
CPU a 32 bit Intel
risulta difficile allocare più di 3 Gb di memoria per lo spazio di processo. 
Indipendentemente dall'OS usato.
http://www.microsoft.com/whdc/system/platform/server/PAE/pae_os.mspx
Saluti.

 CPU a 32 bit Intel
Lui parla di OSX, che era quello che aveva provato ad usare nella renderfarm 
per finalizzare il progetto di animazione 3D su cui stanno lavorando da 
svariati mesi. E siccome OSX e l'HW che lo fanno girare sono notoriamente a 
64 bit, pensava che simili problemi di indirizzamento semplicemente non ci 
fossero. Tanto e' vero che su Linux questo problema e' di fatto inesistente.
-- 
BArrYZ
[_Sign?_] 

 risulta difficile allocare più di 3 Gb di memoria per lo spazio di processo.
PAE non aumenta lo spazio disponibile per la memoria virtuale, ma
aumenta solo la quantita' di memoria fisica accessibile: Non cambia
quanta memoria un processo puo' indirizzare (ma solo quanta memoria
TUTTO IL SISTEMA puo' usare).

:

Il tizio si lamenta perchč ha bisogno di piů di 2 GB di indirizzamento
infatti.
  ngw

 fossero. Tanto e' vero che su Linux questo problema e' di fatto inesistente.
E pure tu non scherzi, visto che condividi lo stesso destino del mostro di cui
sopra.
Ne tu ne l'altro avete capito una sega.
  ngw


Vero.

 quale codice ha scritto e te ne renderai conto da solo.
Rimane il fatto che se parla di applicativi a 32 bit quello è il limite.

 Ne tu ne l'altro avete capito una sega.
Nicholas, guarda che non volevo essere polemico, era solo una cosa che mi ha 
stupito molto (e non solo me, a quanto pare), volevo solo parlarne e capire. 
Non volevo ne' voglio parlare male di niente e nessuno, solo capire 
realmente come stanno le cose. Se il tuo contributo si riassume tutto 
dicendo che non ho capito un cazzo, diciamo che, piu' che altro, la cosa me 
'arimbarza, come si dice a Roma.


 Rimane il fatto che se parla di applicativi a 32 bit
Da quello che ho capito il Blender che facevano girare su OSX era compilato 
a 64 bit, non e' un problema dell'applicativo, ma dell'OS.


 compilato a 64 bit, non e' un problema dell'applicativo, ma dell'OS.
Non si capisce una pippa di quello che sta facendo Ton. Scrive cose del 
genere:
"To my big dismay it appeared that OSX only assigns processes a memory space 
of 2 GB! Macs only use the 2nd half of the 32 bits 4 GB range. this I just 
couldn't believe. it wouldn't be even possible for the OS to swap out unused 
data segments while rendering (like texture maps or shadowbuffers)"
Suppongo che stia usando programmi compilati a 32 bit.
E nel resto dei reply al blog lui stesso dice che stanno usando Blender a 32 
bi
----DAL BLOG ---
Ton said on 18 Feb, 2006:
Autistor: Blender already had 64 bits support since 1999. It has been 
gathering dust though. with a lot of new code being added without proper 64 
bits awareness.
We'll definitely going to make the move to 64 bits this year. A proper 
migration test unfortunately not only requires the 64 bits OS, but also 
developers with > 5 GB memory in system to fully assure all allocations and 
pointers work as expected.
What you call 'dirty fixes' actually doesn't seem to be so. also for 64 bits 
it has advantages to assign memory to be swappable first.
And last but not least; 64 bits isn't a common platform yet.. our renderfarm 
sponsor for example still uses a 32 bits OS. So it's stilll useful to find 
practical solutions for existing limitations.
autist0r said on 18 Feb, 2006:
I'm not saying what you're doing is useless, I'm pointing out that if you or 
one of your users needs a lot of memory, the real answer is to upgrade the 
platform. I'm sorry to hear that you don't have the hardware required for 
your tests. If you ever find a 64-bit PC lying somewhere, know that you don't 
need to have more than 4 GB of physical memory to test thoroughly the 64-bit 
support, thanks to virtual memory. The allocation of pointers is not your 
concern, it's the concern of the VMM. Don't worry it'll work fine. ;) If you're 
concerned about some "cast" issues, the 64-bit compilers generally warn you 
about that. Use VirtualAllocEx() to have addresses that would be invalid in 
a 32-bit environement (for testing purposes)
Don't wait for 64-bit to be everywhere to catch up. And good luck. ;)
-----------------
Dire che  MacOSX a 64 bit non gestisce piů di 2 Gb di memoria allocata per i 
processi a 64 bit puň essere anche vero. Dipende dalla versione e da quali 
servizi usa il processo. Ogni commento č inutile.
Saluti.

 versione e da quali servizi usa il processo. Ogni commento è inutile.
Come e' inutile?
E' proprio quello che si sta cercando di capire (o almeno a me interessava). 
Lui ha detto questo:
"To my big dismay it appeared that OSX only assigns processes a memory space 
of 2 GB! Macs only use the 2nd half of the 32 bits 4 GB range. this I just 
couldn't believe. it wouldn't be even possible for the OS to swap out unused 
data segments while rendering (like texture maps or shadowbuffers).
After a lot of searching on the web I could find some confirmation on this. 
Photoshop and Shake both mention this limit (up to 1.7 gig is safe, above 
that Macs might crash). However; the Apple Developer website was 
mysteriously vague about this."
Si tratta di capire, se e' vero oppure se e' una cazzata che si e' inventato 
cosi' per sport.
E' vero o no ?
Lui dice addirittura che "it wouldn't be even possible for the OS to swap 
out unused data segments while rendering (like texture maps or 
shadowbuffers)" e ha notato che anche Shake fa questo scherzetto. Dice che 
ha contattato la Apple per avere ragguagli e in pratica non gli hanno 
risposto. Questo dice. Poi nel Blog gli hanno fatto notare che anche Windows 
soffre degli stessi identici problemi (anche se pare che in alcuni casi si 
possano evitare cosi' come ho letto qui:
http://petershipkov.com/tutorials/eliminatingthememmorylimitation/eliminatingthememmorylimitation.htm
http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx
 )
E' vero o sono tutte cazzate?
-- 
BArrYZ
[_Sign?_]

 TUTTO IL SISTEMA puo' usare).
Sě č vero. Per usare piů di 2 (3) GB un programma a 32 bit dev'essere 
specificamente progettato, utilizzando certe API... Inutile dire che si 
tratta di un sistema piuttosto inefficiente.
Saluti.
--
Xelloss

 E' vero o sono tutte cazzate?
Sono parzialemente vere per MacOSX per  versioni anteriori alla 10.4 le 
applicazioni anche a 64 bit
possono avere max 2 Gb di memoria allocata ed anche dalla 10.4 solo le 
applicazioni console possono infrangere i 2 Gb.
Almeno cosi dicono.
Per Windows a 32 bit il limite è di default a 2 Gb ma modificando un 
parametro nel boot.ini è possibile usare 3 Gb di memoria.
Per Windows a 64 non ci sono problemi. OVVIAMENTE l'applicazione deve essere 
a 64 bit.
Saluti. 

 Suppongo che stia usando programmi compilati a 32 bit.
Č costretto a farlo, secondo quanto sia lui che Tom Musgrove spiegano
nel dibattito che segue:
"Blender has been 64 bit clean since before it became open source.
However the render farm donated is OS X, and not on 64 bit hardware. So
there was no option to switch to 64 bit hardware and software."
Probabilmente usano degli XServe G4, che se non ricordo male non
potevano funzionare a 64 bit.
Ciao,
Paolo

 potevano funzionare a 64 bit.
Ah, quindi e' per quello che usano la versione a 32 bit, ora capisco.
(effettivamente questa parte nel blog non l'avevo letta con attenzione, io 
pensavo usassero una versione a 64 bit visto che era HW Apple lo davo per 
scontato)
Ma mettiamo che avessero usato la versione compilata a 64 bit sull'ultima 
versione di OSX: il problema sarebbe sparito da solo?
(lo domando perche' non lo so, non per altro)
-- 
BArrYZ
[_Sign?_] 

 'arimbarza, come si dice a Roma.
A dire il vero ti ho spiegato innanzitutto perchè è un'ovvietà, dopodichè
notando come questo non abbia cambiato minimamente quello che dici (che
ripeto, puoi stupirti finchè vuoi ma è improponibile), ho dedotto che non hai
capito una sega.
  ngw

 a 64 bit, non e' un problema dell'applicativo, ma dell'OS.
CVD.
Quale parte di "le librerie sono a 32 bit" non hai capito ?
  ngw

 (lo domando perche' non lo so, non per altro)
Dipende da come sono compilate le librerie.
Se le librerie sono compilate a 64 bit ovviamente il problema scompare.
  ngw

 scompare.
E le librerie a cui si appoggia sono di OSX o sono di terze parti?
Cioe': sono compilabili tutte a 64 bit, oppure OSX per funzionare bene deve 
averne per forza anche alcune a 32  e quindi il problema di fatto e' 
ineliminabile?
(effettivamente non so bene quali sono tutte le librerie a cui si appoggia 
un programma come Blender, ma penso che gia' solo l'OpenGL sia una cosa 
gestita dal sistema e non dal programma, no?)
-- 
BArrYZ
[_Sign?_] 

 gestita dal sistema e non dal programma, no?)
In realtà è eliminabilissimo, basta usare i darwinports e tirare su xorg e
mesa.
  ngw

 xorg e mesa.
Eh, ma a quel punto devi sviluppare apposta per OSX, no?
Blender e' un programma CrossPlatform, sviluppato indipendentemente dalla 
piattaforma, gira su praticamente tutto (vabbe', quasi).


 Eh, ma a quel punto devi sviluppare apposta per OSX, no?
xorg e mesa sono cross platform.
-- 
Lawrence - 
http://www.oluyede.org/blog
"Anyone can freely use whatever he wants but the light at the end
of the tunnel for most of his problems is Python"

 piattaforma, gira su praticamente tutto (vabbe', quasi).
Davvero barryz, io ti voglio bene, ma ti rendi conto che lo spettro di
risposte differenti a "non hai capito un cazzo" si restringe sempre di più ?
Cazzo te l'abbiamo spiegato in 15, allora spara un "fuck the mac" e siamo
apposto no ?
  ngw

 xorg e mesa sono cross platform.
Al di la di questo che cazzo vuol dire "devi sviluppare apposta per OS X" ?
  ngw

 OS X" ?
Mi riferivo ai Darwinports (che non conosco), Xorg e mesa lo so bene cosa 
sono.
Intendo dire che devi fare una versione apposita per Mac (ovviamente si 
tratta di modifiche, ma e' sempre una cosa da fare a parte) per bypassare 
quel problema di indirizzamento, questo sto dicendo.


 Al di la di questo che cazzo vuol dire "devi sviluppare apposta per OS X" ?
Non lo so, ma e` troppo tardi per indagare nella mente di un qualsiasi
frequentatore di questo NG, te compreso :D


 mac" e siamo apposto no ?
Ti giuro che non voglio dimostrare un cazzo, credimi. Era ed e' pura 
cusiosita' per cercare di capire come e' la questione (anche perche' si 
parlava pure di Windows, non solo di OSX). Poi e' chiaro, io mica sono 
programmatore, facilissimo che dica cazzate se si entra nello specifico, e' 
per questo che chiedevo lumi.


 quel problema di indirizzamento, questo sto dicendo.
I DarwinPorts sono un sistema di packaging.
  ngw

 I DarwinPorts sono un sistema di packaging.
Quindi tu dici che e' solo e soltanto un problema di sviluppo?
-- 
BArrYZ
[_Sign?_]

 stessero scherzando all'inizio.
Si fa presto a dire 64 bits. Dire di avere un OS a 64 bit quando quasi tutti
i servizi della UI sono codice a 32 bit è una buona rappresentazione della 
realtà.
Per maggiori info sull'arcano
http://devnet.developerpipeline.com/documents/s=9858/q=1/ddj0602b/0602b.html
Saluti a 64 bit "a la Apple":  SSaall

 Quindi tu dici che e' solo e soltanto un problema di sviluppo?
Ma sai che non ho la minima idea di cosa hai capito ?
Il tizio ha sparato una cazzata, e l'ha fatto a diversi livelli.
Ha in mano un'applicazioni a 32 bit e, non si sa perchè, pretende di avere la
gestione della memoria di una a 64, cosa talmente improbabile che non saprei
nemmeno da dove partire per fargli capire dove ha sbagliato.
Tiger può avvalersi di processi a 64 bit, di problemi in merito non ce ne
sono, ma il software deve essere compilato per 64 bit, altrimenti siamo da
capo. Io sono _quasi_ sicuro che OpenGL sia ancora a 32, ma non ci giuro.
Se gli servono i 64 bit può tranquillamente usare xorg e mesa, compilandoli a
modino, ed evitare la pletora di pugnette che si sta facendo con mmap.
Il programma in se non c'entra un cazzo, ne lo sviluppo, ne il sistema
operativo: deve solo avere la roba compilata per 64 bit se vuole usare i 64
bit, _esattamente_ la stessa cosa che deve fare per Linux, perchè se ricompili
il kernel linux per un'architettura a 64 viene da se che devi ricompilare
anche tutto il sistema.
  ngw

 apposto no ?
ROTFL.
-- 
Porco Jobs!