5.5 c'est disponible...

Hum, ceux qui espéraient un miracle de W7 avaient précisé qu'il s'agissait d'un W7 64b afin de tirer mieux parti de l'architecture 64 d'une machine (proc et quantité de RAM).
C'est une nuance à pas oublier.
Je résume : il s'agît de comparer sur une machine en architecture 64 bitles performances d'Edius sous XP32 et sous W7 64...
(de préférence en incluant une différence de quantité de RAM : 2 Go ou 3 Go vus par XP32 contre 6 ou 8 possibles sous W7 64b, cette différence ayant toute chance de jouer de façon positive pour les monteurs qui travaillent avec Edius + Photoshop + Imaginate + pas mal de dossiers ouverts).

Quelqu'un serait-il en mesure de tester la différence ?

 

La machine de Raymon est bien une W7 64b avec 4 Go de RAM
Le test était de demontrer que Edius ne profite en rien du W7 64B .
CQFD.

Maintenant , si le but est d'ouvrir x applications en plus d' Edius, c'est tout autre chose ... et un tout autre test.
Il est evident que plus de RAM apportera un peu plus de confort si x applications ouvertes
Là c'est simple il suffit de rajouter quelques Go de plus.
Et tout depend du log : Photoshop 7 ou CS5 , la marche est grande.
En general 6 à 8 Go sont très confortables.

Marc

 

Désolé, j'avais sauté quelques messages.

Pardon d'insister mais le processeur de Raymon est-il vraiment en 64b ?
(Sauf erreur, il me semble qu'un W7 64 peut s'installer sur une machine dont l'architecture n'est pas 64b)

Je note par ailleurs les observations intéressantes de Hola :
W7 64 chargeant la RAM au boot, les applications seraient plus rapides à ouvrir.
C'est toujours bon à prendre...

 

Bonjour,

Mon processeur est bien un intel Core 2 Quad Q9400 64 bit d'origine comme indiqué sur la boite

J'ai constaté la chose suivante avec W7 64 bit

Lors d'un rendu avec "imprimer dans un fichier" en format de sortie blu ray, le projet avec les zones rouges mettait 2 minutes à etre encodé.
Ce meme projet avec uniquement les zones rouges pré-rendues ou calculées, le temps de rendu avec "imprimer dans un fichier" passait sous la minute.

Je n'ai jamais fais attention sous XP, mais peut etre que ce phonomène est indentique.
A vérifier, ou c'est la version 5.5 qui apporte ce gain.


Je précise que mon projet est composé éssentiellement de clips AVCHD, de photo jpeg, et de titre.

 

Cela voudrait effectivement dire que l'OS 64 bits ne change rien à l'utilisation du proc par rapport à XP 32.
Je serais curieux de savoir ce qu'en pense OGT puisqu'il nous disait :

Il faut néanmoins remarquer que les tests ont été réalisés dans Edius.
Dans la mesure où Edius est pour l'instant en 32 bit, le jeu d'instruction s'adresse uniquement en 32 bit. Du coup, c'est normal que les temps de calcul soient les mêmes. En revanche, avec des applications en 64 bits, ça ferait peut-être une différence...

 

Ben NON ...le fait d'avoir une adresse "plus longue" permet d'adresser des "zones" de données plus grandes, dont la mémoire ..
Cela ne change en rien les performances ..!!! "sauf si" le logiciel en profite pour "s'étaler" en mémoire, dans ce cas le traitement peut être accéléré en évitant "certains" allers/retours sur DD voire optimiser la parallélisation des traitements ...
Bertrand

 

C'est justement l'info que j'ai du mal à obtenir.
D'après AV2P, les fichiers du montage sont chargés en RAM ou plutôt dans dans le buffer TR, au fur et à mesure de la lecture du montage . Mais Edius ne serait pas capable de s'étaler en mémoire comme tu dis. Je ne sais pas d'où ils tiennent cette info.
Il existe peut-être d'autres avis sur la question.
Qu'est-ce qu'en pense Marc, par exemple ? A-t-il une info précise ?

 

Bill a propos pourquoi cette question te taraude à ce point ?

NON Edius au delà d'un certain seuil dispose de suffisamment de mémoire ...et quoique tu fasses n'augmente plus ( D'autre comme Vegas de mémoire envahissent littéralement la machine, de vrai glouton )
Par contre Edius peut se débrouiller avec 1Go de RAM, il va swapper sans arrêts ..ensuite plus il a de place, plus il va conserver en mémoire ses sous programmes ...et c'est fini...
Dit autrement, sauf à profiter d'une amélioration due à la "réécriture" des modules d'Edius pour gérer des adresses plus longues ..l'adressage 32bits ou 64 bits ne modifiera en rien sa vitesse ...**
Je sais que tu es déçu mais c'est comme ça ..!!!
Dur dur la vie
Bertrand
** ce n'est pas parce que ton numéro de téléphone comporte 10 ou 16 chiffres que tu vas mieux téléphoner ..
!!!!! par contre tu pourras "adresser/contacter/gérer" plus de numéros.
Maintenant si tu en profites pour changer de commutateurs .. électromagnétiques à électroniques ou tout autres améliorations ..là oui tu peux espérer, mais cela n'a strictement rien à voir .

 

1- merci pour cette réponse très intéressante
2- cette question me taraude parce que j'utilise beaucoup d'images fixes lourdes dans mes montages, et Edius accuse le coup, ce qui n'est certes pas le cas quand je travaille sur des projets qui ne sont qu'à base de rush vidéo. Et je me demande si le problème ne vient pas de la gestion de la RAM par Edius. Trouves-tu cela absurde ?
3- Je n'ai pas complètement compris ce que tu dis justement à propos de la façon qu'a Edius d'utiliser la RAM. Si je te comprends bien, Edius réserve jusqu'à 1 Go de RAM max, et ensuite, s'il en a besoin de davantage, il utilise le fichier d'échange autant que nécessaire ; c'est cela ?

Mais que veux-tu dire par : "ensuite plus il a de place, plus il va conserver en mémoire ses sous programmes ...et c'est fini..."
Excuse-moi mais tu es un peu trop elliptique pour moi. J'ai besoin qu'on me dise les choses pas trop vite !
En tous cas, j'ai vraiment l'impression que pour ce que je fais, Edius ne se débrouille pas assez bien avec 1 Go de RAM comme tu dis. Et je ne peux pas m'empêcher de penser que nous touchons là une limitation de ce très bon log de montage.
une "réécriture des modules d'Edius pour gérer des adresses plus longues" ne serait-elle pas une excellente chose, à demander à GV ?
Et pourquoi pas un fonctionnement analogue à Vegas, avec éventuellement, dans les préférences, un choix de taille de RAM qu'on est prêt à allouer au Log de montage, afin qu'il n'aille pas manger la nourriture des voisins, ce glouton ?