Discussion :

[deuns0615]

bonjour a tous et merci de prendre un peu de votre temps pour me lire

je bosse sur un G5 dual 2.7 avec 6 gigas de ram

ma question n'aura peut etre pas sa place sur ce forum, donc si jamais vous savez ou je pourrais la poser, svp dites le moi...
puis j'avoue je suis totalement ignare en programmation, donc ma question n'aura peut etre pas grand interet pour vous... mais maintenant que je suis la je la pose quand meme:

je travaille avec un sampleur virtuel nomme kontakt 2 cree par native instruments, selon ses concepteurs d'architecture 32 bits

j'ai deja pose cette question a native instruments et les reponses que j'ai eu au pire sont a cote de la plaque, au mieux noient le poisson...

voila mon probleme:

pour economiser la ram, K2 ne charge que 1% du debut du sample, le temps que le disque dur se mette en route, puis il streame le reste directement sur le disque... on a un declenchement instantane alors que le sample est lu sur le disque...


donc disons que je suis de nature a etre aventurier et que je charge enormement de samples, genre 3000! ca va correspondre a 4,5 gigas de samples prets a l'emploi pour seulement 111 megas de ram utilisee...

111 megas oui, mais constitues de milliers de petits fichiers charges dans la ram!

imaginons que je continue a charger... arrive le moment fatidique ou si je charge un sample de plus, non seulement il ne se charge pas mais c'est la que tiger part en biberine: lettres du finder qui ressemblent subitement a du chinois, ou impossibilite de lancer une autre appli...

native instruments disent que c'est parceque la ram est toute utilisee, mais c'est faux! je regarde le moniteur d'activite, la memoire reelle ou virtuelle se porte a merveille, j'en ai 6 gigas, il m'en reste 5 de libres, donc tout va bien a ce niveau la. de plus j'ai fait l'experience de charger 2 samples de 1 giga chacun et ca fonctionne alors que 500 megas de ram sont utilises!

donc je resume:

je charge 3000 samples=3000 petits fichiers constituant 111 megas dans la ram=bloquage

ou

je charge 2 samples=2 fichiers constituant 500 megas dans la ram=tout va bien


je pense donc que le probleme vient du nombre trop important de samples... donc de petits fichiers dans la ram...

alors

soit NI ont instaure cette limite (qu'ils ont l'air d'ignorer au vu de leurs reponses) et ils pourraient se depecher de corriger ca...

soit ca vient de l'architecture du systeme ou de je ne sais quoi qui ferait que plus de 3000 petits fichiers de 2kb a charger dans la ram c'est trop pour le systeme...

trop pour le systeme ou trop pour k2? native instruments me repondent a cote, donc je me tourne vers vous...

qu'en pensez vous? je dis n'importe quoi?

encore desole si je suis hors sujet sur ce forum et n'hesitez pas a me demander gentiment d'aller voir ailleurs...

merci pour votre patience!

[JeitEmgie]

1. Un programme 32 bits a droit à un espace mémoire de 4 Gb. (donc que vous ayez 6 Gb d'installés ou 2 Gb ne change rien à cet aspect, avec 6Gb cela diminuera juste le nombre de swaps pendant l'exécution du programme et donc la performance mesurée sera meilleure). Seul un processus 64 bits peut accéder à plus de mémoire.

2. L'espace de 4 Gb est fractionné entre le code du programme, les images des librairies dynamiques auxquelles il est lié, le stack et le heap où sont chargés les "samples" des vidéos… Vous êtes donc très loin d'avoir accès à un espace continu de 4 Gb pour la mémoire allouée dynamiquement lors de l'exécution du programme.

3. Avoir beaucoup de fichiers ouverts en même temps augmente la "pression" sur le système car les tables de descripteurs de fichiers sont aussi allouées dans l'espace du kernel… Le nombre maximum de fichiers ouverts par un processus est déterminé par la configuration du système : voir ulimit.

4. Il n'est pas impossible que des programmes de vidéo optimise l'accès aux streams par du mapping de fichiers en mémoire ce qui optimise les accès disque et diminue le swap mais ne change rien à la limite des 4 Gb.

Voir : http://developer.apple.com/documenta...outMemory.html

[deuns0615]

merci pour votre reponse, j'ai suivi le lien donc je comprend un peu mieux comment se partage le ram...

ceci dit il me semble a present que le probleme ne vient pas du systeme ou du nombre de fichiers que la ram pourrait accepter, mais plutot de l'appli en elle meme ou d'une "sous application"...

j'ai fait une nouvelle experience

je sais qu' au lancement, kontakt 2 va dialoguer avec un autre programme lui uniquement responsable du direct from disc (d'ailleurs son nom c'est DFD) ce "programme" loge dans la bibliotheque rayon applications support

j'ouvre donc kontakt 2 et a l'aide du DFD je charge mes 13000 (et non 3000 j'ai verifie) samples (ce sont des samples audio provenant d'une gigantesque librairie de sons orchestraux), j'en arrive donc rappidement a la limite ou si j'en rajoutais quelques uns, tout flancherait...

mais la je decide plutot que les nouveaux samples que je vais rajouter n'utiliseront pas le systeme DFD (on peut le desactiver) et donc seront entierement charges dans la RAM... etant donne que je dispose de beaucoup de ram je dois pouvoir en charger beaucoup...

il s'avere qu'en faisant ca j'ai reussi a encore charger une enorme quantite de nouveaux samples sans que le systeme defaille...

donc je me suis trompe ca ne vient pas du nombre de fichiers gerables par le systeme, apparemment il peut en encaisser beaucoup plus en nombre!

est-ce que ca pourrait venir donc de ce petit programme DFD?

est-ce qu'il serait impossible pour lui de gerer plus qu'un certain nombre de fichiers independamment de la taille que represente la totalite?

j'ajouterai que tout ce que je charge que ce soit en mode DFD ou "tout dans la RAM" n'a jamais excede 4 gigas, je suis au courant de cette limite c'est la premiere raison qu'avancent NI alors que je me tue a leur repeter que a peine un gigas n'est utilise, memoire reelle et virtuelle ajoutee

je cherche a comprendre pourquoi ce DFD bloque a 13000 samples...

d'apres mes experiences ca n'a rien a voir avec la quantite de RAM utilisee, moniteur d'activites a l'appui, je sais aussi maintenant que ce n'est pas lie au nombre de fichiers que le systeme pourrait "considerer" en meme temps, car il peut encaisser un nombre bien plus important que ces 13000 samples a condition que je charge les samples supplementaires entierement dans la ram et sans utiliser le DFD...

y a t'il pour vous un quelconque semblant de logique dans tout ca?

je laisse le fichier DFD en piece jointe si jamais ca interresse quelqu'un de jeter un coup d'oeil ou juste me donner une piste pour traquer native instruments afin qu'ils ameliorent ceci... parceque on dirait qu'ils ignorent le probleme!

encore merci!