• Entretien avec le créateur du Bottin des jeux linux
    Le site « Le Bottin des jeux linux » recense les jeux vidéo sous Linux. Il a été créé en 2007 par Serge Le Tyrant. Celui-ci, en voulant mettre un peu d’ordre dans sa base de données de jeux, a fini par en effectuer la refonte complète. Après un travail important de mise en forme et de mi... (Lire l'article)
  • Conférences audio et vidéo
    Retrouvez les conférences données lors des Ubuntu party ou d'autres événements, ainsi que les interviews par OxyRadio. (Lire l'article)
  • Entretien avec Aviv de l'équipe de Wildfire Games
    Pour ceux qui ne le savent pas encore, 0 A.D. est un jeu de stratégie en temps réel de guerre antique, développé par l'équipe de Wildfire Games, et qui a été complètement libéré en 2009. (Lire l'article)
  • Entretien avec Quentin Bolsée, le développeur de ColorCube
    Très récemment, Quentin a annoncé la disponibilité de son jeu : ColorCube, un jeu basé sur le Blender Game Engine. Entretien d'un jeune et talentueux développeur. (Lire l'article)
  • Pourquoi devriez-vous utiliser OpenGL et non DirectX ?
    Il y a quelques jours, sur le blog de Wolfire Games, est apparu un intéressant point de vue sur les raisons d'utiliser OpenGL. L'article étant fort intéressant, nous vous l'avons traduit, pour qu'il profite au plus grand nombre. (Lire l'article)
  • Entretien avec l'équipe des Landes Eternelles
    Suite à la sortie, il y a un peu plus d'un mois, de la nouvelle version du client de Landes Eternelles, un mmorpg multi plateforme, nous avons voulu interroger Ackak & Nati, deux des administrateurs du serveur. (Lire l'article)
  • Entretien avec l'équipe de Smokin'Guns
    Si vous nous lisez régulièrement, vous savez que toute l'équipe de jeuxlinux.fr est fan de Smokin'Guns. Plusieurs questions nous trotté dans la tête concernant la suite de ce jeu, et ce n'est autre que ReD NeCKersoN et Téquila, les deux piliers de l'équipe, qui vont nous donner les réponses. (Lire l'article)
  • Créer une course pour Tux Racer
    La création de nouvelles pistes dans les Tux Racer libres est une chose qui a été vraiment bien pensé. Même si elle ne permet pas de creuser des sous-terrains ou de régler l'orientation des objets par exemple, elle vous permettra de modéliser assez facilement et plutôt rapidement des courses... (Lire l'article)
  • Entretien avec Frictional Games
    Ce mois-ci, les développeurs de Frictional Games, à l'origine de la série des Penumbra, nous parlent de leurs jeux, de leur modèle de développement ainsi que de leur projets futurs. La série des Penumbra contient des jeux d'horreur d'une excellente qualité vous plongeant dans un univers noir... (Lire l'article)
  • Open Transport Tycoon
    Les jeux de gestion sont rares sous linux, trop rares au point qu'il n'existe même pas de catégorie gestion sur jeuxlinux. Ce genre de jeu demande de la profondeur et un sens du détail hors du commun. (Lire l'article)

Comparatif x86_64 contre x86


Auteur(s) de l'article : Diablo150 - Date de parution : 1er mars 2007

Comparatif des performances entre Debian Sid x86_64 et i686.



Présentation Présentation

L’architecture x86_64 d’AMD est présentée par son constructeur comme une évolution dans le monde des ordinateurs compatibles PC, son avantage est de tirer profit du mode 64 bits, tout en restant compatible binairement avec les applications compilées pour les systèmes x86.
Qu’en est-il des jeux vidéos ?

Nous allons utiliser ici Debian sid sur la même machine, avec une édition i686 et une x86_64, avec le programme Procbench pour les tests du processeur sur chacun des systèmes. Et coté jeux, ioquake3, une modification du moteur Quake III sous licence GPL, qui a le mérite de supporter totalement l’architecture x86_64, ainsi que Unreal tournament 2004, qui est aussi disponible pour x86_64.

Description matérielle de la machine :

Processeur : AMD Athlon 64 3200+ cadencé à 2210 Mhz
Carte mère : Nforce 3
Mémoire vive : 1,2 Go
Carte graphique : Geforce 6600 GT 128 Mo, avec les pilotes Nvidia propriétaires.

Procbench

Procbench est un petit programme qui effectue une batterie de tests pour le processeur en 3 parties, vitesse des registres, vitesse de lecture de la mémoire et génération de nombres.

Commençons par un détail du processeur en question, fourni par procbench (mais peut être trouvé facilement chez soi avec la commande "cat /proc/cpuinfo" :

Fabriquant        : AuthenticAMD
Famille           : 15
Modèle            : 12
Révision          : 0
Nom               : AMD Athlon(tm) 64 Processor 3200+
cache:            : 512 KB
Caractéristiques  : fpu vme de pse tsc msr pae mce cxchg8 apic sep mtrr pge mca cmov pat pse36 clfl mmx fxsr sse sse2

Attention, les technologies embarquées ne signifient pas forcément qu’elles sont utilisées par le noyau.

En ce qui concerne les tests, les chiffres sont assez difficiles à interpréter, je vais faire un « résumé » , néanmoins, vous pouvez télécharger les résultats bruts utilisés lors de ce comparatif dans le fichier texte en bas de page.

Pour les tests à proprement parler, commençons par la vitesse d’exécution des registres, et force est de constater que les résultats sont sensiblement les mêmes. Ca varie donnant l’avantage à l’un ou l’autre.
Exemple avec 3DNow, le système 64 bits affiche 2173 MégaFLOPS avec 4 registres, tandis que le système 32 bits en affiche 2181. A contrario, la vitesse du FPU donne l’avantage au système 64 bits, avec 2181 contre 2166 MégaFLOPS, toujours avec 4 registres.

Concernant l’accès à la mémoire, l’avantage va au système 32 bits, exemple avec 2166 Mo/Seconde contre 2123. Ca n’est qu’un chiffre, mais très représentatif du reste des résultats.

Pour finir, le calcul brut ; et là, les résultats sont exactement les même, ou presque. Par exemple, il a fallu 0.366 seconde au système x86 pour résoudre la fonction d’Ackermann, contre 0.367 pour le système 64 bits.

Inutile d’aller plus loin, rien n’est vraiment significatif, aucune des deux architectures n’en sort réellement gagnante.
Passons donc à la pratique, avec les jeux.

ioquake 3

Comme dit dans l’introduction, ioquake 3 est un remodelage du moteur Quake 3, avec un support d’architectures différentes, dont l’x86_64.



Disons-le clairement, l’avantage revient au système i686, qui même sans grosse différence est plus rapide. A noter que même avec des résultats différents, les performances chutent exactement de la même manière en haute résolution, preuve d’une certaine cohérence entre les deux systèmes, ainsi que dans notre comparatif (sic !).

Unreal tournament 2004

Passons à Unreal tournament 2004, l’un des premiers jeux commerciaux à avoir supporté l’architecture AMD64.



Unreal Tournament 2004 est donc sorti en mars 2004, alors que les premiers processeurs x86_64 datent de septembre 2003.
Le jeu était donc relativement en avance, puisque bon nombre de jeux encore en développement ne prévoient même pas le support du 64 bits.

Je dis cela, parce qu’il est clair que l’AMD64 n’est pas à son avantage. Si en basse résolution il peut se vanter d’être très légèrement plus rapide, il perd rapidement sa place, laissant l’i686 seul en tête. Et plus la résolution augmente, plus l’écart se creuse.

Conclusion

Quoi ? C’est tout ? Deux jeux sur le banc d’essai pour séparer les candidats ? Même pas libres en plus !

Et oui, nous avons choisi ces deux jeux car ils sont totalement différents, sans aucun lien de parenté (UT2004 n’est pas un moteur basé sur quake, contrairement à de nombreux jeux libres), et même s’il n’y a que deux jeux, c’est suffisamment représentatif des performances dans les jeux vidéos sur x86_64.

De plus, à notre connaissance ce sont les deux seuls jeux natifs x86 et x86_64 sous Linux, tout en étant suffisamment poussés pour afficher de réelles différences, de petits jeux ne demandant pas beaucoup de ressources n’afficheraient pas de différence entre les deux systèmes, donc inintéressants (sans dénigrer le travail accompli, nous parlons ici de comparatifs de performances).
Pour finir, oui la machine de test est ancienne, parce que c’est l’ordinateur personnel de votre serviteur, et il est de toute façon inutile de réaliser des comparatifs sur des machines hautes de gamme, qui ne représentent probablement pas plus de 5 % de nos lecteurs.

Cette mise au point achevée, nous pouvons passer à la conclusion.
Alors oui, l’architecture AMD64 peine à venir au niveau de la vielle Intel 32 bits.
Mais dans ce contexte, difficile de trouver le responsable, est-ce le processeur en lui-même qui a du mal à mettre en application ses performances théoriques ?

Ou le problème est-il logiciel ?
Car il suffit que le jeu en lui-même soit pas ou mal optimisé pour l’architecture pour que les performances en pâtissent. (C’est probablement le cas d’Unreal tournament 2004, ces écarts n’étant pas justifiés au regard des performances d’ioquake 3, très proches entre les deux systèmes).

Mais cela peut aussi venir des pilotes ou même du noyau. Car si le processeur est théoriquement capable de bien des choses, il pourrait très bien être bridé par le système d’exploitation, s’il ne met pas à en applications les technologies en question.

Pour l’heure, l’architecture AMD64 n’est pas à la hauteur de l’x86 dans les jeux vidéos, c’est un fait, mais dans le même temps on n’a encore jamais vu un jeu commercial sous Linux spécialement optimisé pour x86_64.
Ce qui est logique dans la mesure où il ne représente qu’une infime partie du parc informatique.
Toujours est-il qu’il est actuellement difficile de savoir si l’AMD64 apportera réellement un gain de performance.

Qui vivra verra...

Documents joints

Procbench

Résultats avec procbench