Derniers journaux de Zezinho :
- [04/10@10:15] En quête de DRM pour ATI Rage PRO
- [28/09@21:45] Randr 1.2 est géré par le pilote libre Radeon
- [28/09@06:57] Aider les Birmans
- [09/09@19:40] Kdenlive permet de produire des films
- [06/09@14:37] MyFreeTV (et coup de gueule sur la modération...)
- [20/08@07:43] Comment mieux gérer les plantages de carte graphique
- [27/07@10:39] Nouveau script pour Amarok : transcogg
- [20/07@12:22] MANDRIVA IGGI CLUSTER
- [02/06@20:51] Faciliter l'utilisation de dosbox
- [10/05@13:54] AMD64 pour quoi faire
- [01/02@16:23] Linux pour tous?
- [21/12@22:19] Utiliser un système libre...
- [05/12@22:21] Mandriva sux
- [13/10@12:10] Pilotes graphiques libres Intel : et les performances?
- [07/10@07:07] Pilote propriétaire NVIDIA : pas de mode DGA!
- [06/10@19:54] Pilote propriétaire ATI : pas de mode 16 bits!
- [16/06@14:35] Performances 3D d'un vieux chipset : Intel 810
- [17/04@22:23] Regarder FreeTV à distance
- [05/12@08:24] Suite du journal précédent ;-)
- [28/08@21:38] Flightgear
Journal : Suite de mon feuilleton x86 versus x86_64
Posté par José JORGE (Jabber id, page perso, ) le 12 octobre 2007J'ai pris comme critère le résultat pour user de la commande time, sur un Athlon 64 3200+ (2.4Ghz-512ko de cache) avec vidéo AMD-ATI X300 64Mo.
time ffmpeg2theora test.mov
64 bit user 08m03.702s
32 bit user 10m10.702s
time oggdec -Q -R -o - a.ogg | oggenc -q 1 -Q -r -o b.ogg -
64 bit user 0m11.269s
32 bit user 0m15.557s
- glxgears (oui cen'est pas un benchmark)
64 bit
normal 1280fps
fs 1600x1200 77fps
32 bit
normal 1407fps
fs 1600x1200 77fps
- openarena (timedemo)
64 bit : 80fps
32 bit : 87fps
- time 7za a s.7z syslog
64 bit user 0m3.940s
32 bit user 0m4.188s
Ma conclusion, est que les traitements bruts y gagnent bien (au moins 20%) mais d'un autre côté le pilote libre pour les radeon s'essoufle un peu en x86_64. Ce n'est pas étonnant, vu qu'on n'en est qu'au stade "pas d'optimisations".
Faites-en ce que vous voulez.
> Lire le journal (7 commentaires, moyenne: 2,3).
Merci
Merci, c'est intéressant.
Pour ma part, ce qui m'embête le plus avec l'amd64, c'est les applis qui ne fonctionne pas. Notamment stepmania. Enfin voila, je suis, je devrais envoyer un patch, mais je ne connais pas les outils qui me permettrais de debuggé. J'avais réussi à compiler la version 3.9 en faisant quelques modifications grossière, et le jeu se lançais même, mais frisait rapidement. Je sais pas trop comment je pourrais trouver les erreurs qui causent le freeze, d'autant que je ne connais pas le code du jeux. Peut être gdb permet ça, j'avoue que j'y connais rien, mais si quelqu'un à un tuto pour le débuggage, je pourrais peut être m'y remettre.
-
[^]Re: Merci
Posté par Snarky (Jabber id, page perso, ) le 12/10/2007 à 18:08. (lien). Évalué à 2.Étonnant, voici plus de 2 ans que je joue a stepmania 3.9 en 64bits. Je l'ai compilé moi même (après quelques modification mineur dans le source, sur ce qui passais pas) et j'ai jamais eu de problèmes.
Par contre, la version 4 bug à mort... À mes derniers essai voilà plusieurs mois.--
Milite pour un about:black sur les navigateurs ! (Sauvons la planète)-
[^]Re: Merci
Posté par Snarky (Jabber id, page perso, ) le 12/10/2007 à 20:05. (lien). Évalué à 2.Pour info, je viens de refaire un test avec sm4, et ça compile sans la moindre erreur en 64bits. Et ça tourne du tonnerre ^^
--
Milite pour un about:black sur les navigateurs ! (Sauvons la planète)-
[^]Re: Merci
Posté par Mathieu Stumpf (Jabber id, page perso, ) le 13/10/2007 à 04:08. (lien). Évalué à 1.Ah bah merde alors! Tu peux pourrait me filer un diff des modifs que tu as fais aux sources du 3.9 (en me précisant le version source à dl si nécessaire) ?
-
-
consommation mémoire
un autre bench intéressant aurait été de mesurer la différence de consommation mémoire d'une application comme OpenOffice, avec de gros fichiers ouverts, ou la consommation de Gnome ou KDE.
Si le jeu d'instructions est plus performant en 64-bit, les pointeurs prennent 2 fois plus de mémoire, donc les gains ne doivent pas être systématique.
En tout cas, les gains que tu obtiens sont significatifs et prouve que les compilateurs savent tirer partie de l'architecture x86-64. Et ça, c'est bien, sauf si les programmes 32-bit ont été compilé pour être le plus portable possible.
Je pensais que l'utilisation d'instructions SSE2 ou autres nivelleraient les performances. ça doit être implicite en 64-bit, mais pas en 32-bit.
-
[^]Re: consommation mémoire
Posté par Ontologia (page perso, ) le 13/10/2007 à 13:31. (lien). Évalué à 4.Je pensais que l'utilisation d'instructions SSE2 ou autres nivelleraient les performances. ça doit être implicite en 64-bit, mais pas en 32-bit.
C'est surtout les 8 registres supplémentaires qui doivent aider pour le moment.
Gcc ne sait pas encore utiliser le SSE/3dNow etc... sur du code non prévu pour, mais ça va venir avec la version 4.3 :
http://gcc.gnu.org/projects/tree-ssa/vectorization.html-
[^]Re: consommation mémoire
Posté par José JORGE (Jabber id, page perso, ) le 15/10/2007 à 12:13. (lien). Évalué à 3.C'est peut-être là l'intérêt principal des versions x86_64 aujourd'hui : les logiciels sont compilés avec ces jeux d'instruction, alors que les versions i386,i486,i586 ne s'autorisent aucune instruction moderne.
-
Les journaux sont destinés à des informations qui ne sont pas suffisamment intéressantes
pour être validées en dépêche (sinon n'hésitez pas à proposer votre information en
dépêche), qui sont sans rapport avec Linux ou le libre, ou simplement pour donner votre
avis. Si vous désirez poser une question, merci d'utiliser 

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.