Journal Benchmarks de processeurs sous GNU/Linux

Posté par  .
Étiquettes : aucune
0
22
sept.
2004
Pour les anglophones, Anandtech.com (site de test de matériel américain) propose cette semaine une série de tests de processeurs ayant la particularité de ne tourner qu'autour de Linux ( http://www.anandtech.com/linux/showdoc.aspx?i=2213&p=1(...) )

Là ou c'est intéressant, c'est que ça montre pour diverses applications orientées bureau (MySQL? compression MP3, compilations, logiciels optimisés O2/O3, chiffrement, ...) les influences des types d'architecture Intel ou Amd, 32/64bits, types de mémoires employées, hyperthreading (simulation de bi-processeur) activé ou pas.

Bonne lecture.
  • # Bouuuuuuuuuuuuuh

    Posté par  . Évalué à 3.

    Ya que des X86 !!! C'est maaaaaaaaaaal ;)
  • # Prix / scores !

    Posté par  (site web personnel) . Évalué à 2.

    Pour moi, ces chiffres ne veulent rien dire... Pourquoi ne tient-on jamais compte du prix ? Si je devait en faire quelque chose, de ces chiffres, je chercherais le prix des différentes plate-formes et je diviserait par les scrores respectifs... Mais là, j'ai pas le courage, je connais pas les plate-formes en question, etc. Le plus simple aurait été qu'ils le fassent eux..., ceux qui on fait tout ces testes... Dommage... :(
    • [^] # Re: Prix / scores !

      Posté par  (site web personnel) . Évalué à 4.

      Ben faut lire le test mon gars, ils concluent en disant qu'actuellement, d'après leurs test, l'Athlon 64 3500+ est le meilleur rapport qualité/perf/prix.
      • [^] # Re: Prix / scores !

        Posté par  (site web personnel) . Évalué à 4.

        Il disent aussi que le 3800+ sera probablement le meilleur rapport qualité prix dans 6-12 mois. En gros, amd c'est une valeur sure, pour les plateformes ix86.

        C'est vrai qu'un comparatif avec des PPC serait intéressant (G3, G4 et G5 ou Power5 d'IBM).
      • [^] # Re: Prix / scores !

        Posté par  (site web personnel) . Évalué à 2.

        Tu es gentil, mais je ne parle pas de la conclusion...
  • # autre test

    Posté par  . Évalué à 5.

    Intel's New Platform Verses AMD's 64-bit Prowess :

    http://www.linuxhardware.org/article.pl?sid=04/09/17/1453239&mo(...)
  • # -o2 vs -o3

    Posté par  (site web personnel) . Évalué à 1.

    Je veux juste commenter la page 4 du test où l'on voit les différences entre -02 et -03 avec ou sans -march. On voit que l'utilisation de -03 -march vis à vis de -o2 tout court n'est pas forcement signe d'optimisation (surtout sur les AMD64), est-ce qu'il y a une règle plus ou moins générale qui permet de prédire si on à intéret à mettre -03 plutot que -o2 ou inversement ?

    Un jour libre ?

    • [^] # Re: -o2 vs -o3

      Posté par  (site web personnel) . Évalué à 2.

      Heu... juste pour dire que ce benchmark est bizarre de toutes manières : leurs optimisations semblent plus efficaces pour un 3500+ que pour un 3800+, alors que ce sont les mêmes processeurs, à la frèquence près. À mon avis ils ont mal tuné leur GCC et ce bench le revèle, à moins que ce ne soit une bizarerie du hardware qui provoque une perte de performances dans certains cas très particuliers...
      Autre chose : il est probable que la capacité de GCC à optimiser pour ces nouveaux processeurs soit infèrieure à ce qu'elle est d'habitude... dans mon make.conf (Gentoo) ils précisent même de ne pas utiliser march=pentium4 pour cause de bugs de GCC. Le fait que GCC les prenne mal en charge défavorise particulièrement ces processeurs à l'architecture très particulière qui, contrairement à ce que l'on pourrait penser, pourraient profiter plus d'un code optimisé pour leurs spécificités que les AMD64 (j'avais lu un article d'Onversity à ce sujet).

      Et pour finir, j'aimerais juste préciser que j'ai vu un paquet de benchmark qui présentent un gain beaucoup plus important lié aux optimisations de GCC.
      • [^] # Re: -o2 vs -o3

        Posté par  . Évalué à 3.

        Dans le même genre de remarques, comparer les performances du PIV en hyperthreading, sur un noyau qui ne gère pas l'hyperthreading, c'est pas étonnant que ca marche quasiment pareil ;-)

        Par contre j'aurai bien aimé voir le test avec un 2.6.7 (premier noyau a intégrer les "Scheduling domains" pour gérer l'hyperthreading.... si quelqu'un a un lien là-dessus, je suis plutot intéressé...

        Tus
    • [^] # Re: -o2 vs -o3

      Posté par  . Évalué à 1.

      Personnellement, j'avais fait quelques tests avec un petit programme de calcul (rien de fulgurant, un classique algorithme d'intégration Runge-Kutta). Si l'accélération obtenue est très importante entre un code non optimisé et un code optimisé, j'avoue que les résultats ont souvent été beaucoup moins nets entre les différents niveaux d'optimisation... avec parfois des O3 moins performants que des 02 par exemple.
  • # Oui, mais...

    Posté par  . Évalué à 1.

    même si l'athlon64 est plus rapide et moins cher, ce ne sera pas une bonne solution tant qu'il ne sera pas accompagné d'un chipset disposant de drivers libres et performants.

    VIA : j'ai eu tellement de problèmes avec (et toutes les personnes que je connais qui possèdaient du via ont eu les mêmes) que ce serait vraiment être masochiste que d'acheter à nouveau une carte basée sur leurs produits...

    Nvidia : Une partie des drivers n'est pas libre (chip réseau, je crois, et peut-être d'autres) et le jour où ils décident d'acheter d'arrêter le support, il faudra que je change de carte?
    • [^] # Re: Oui, mais...

      Posté par  (site web personnel) . Évalué à 3.

      Ouuups. Troll hardware.
      Je ne m'amuserais pas trop à dire du mal d'Nvidia mais tu peut savoir que les problèmes des via 333 et prècedent ont étés corrigés et que de nos jours ils sont très peu buggés, tout en restant bien mieux supportés que les Nforce2.
      Et pour être mèchant, je me permetrais de signaler que les bugs que les cartes mère Nforce ont ou ont eu ces derniers temps (problèmes de bios (!), d'APIC, de perfs quand on désynchronise la RAM...) rappellent la mauvaise pèriode de VIA, pas seulement sur les Asus.
      • [^] # Re: Oui, mais...

        Posté par  . Évalué à 2.

        J'ai une carte mere avec chipset NForce2 ( Asus a7n8x-deluxe ), et je confirme: cette carte est toute bugguée !

        En dehors de l'acpi ne fait plus planter la machine depuis le 2.6, le son est pourri avec alsa .
        Lorsque j'ai voulu utiliser un noyau 2.6 il y a quelque mois de ça sous gentoo, les modules pour le son est la carte reseau nvidia ne compilaient pas .
        Je me retrouve avec un 2.4.26 sans acpi.

        Ressement, j'ai essayer de desyncronyser la RAM dans le bios: RESET du bios necessaire pour pouvoir demarrer; cette fonction ne marche tous simplement pas.
        Cette carte mere a pourtant une tres bonne reputation.
        Si VIA a des probleme, il n'est pas le seul.
        Moralité: mieu vau se renseigner avant d'achetter son materiel !
    • [^] # Re: Oui, mais...

      Posté par  . Évalué à 2.

      Nvidia : Une partie des drivers n'est pas libre (chip réseau, je crois, et peut-être d'autres) et le jour où ils décident d'acheter d'arrêter le support, il faudra que je change de carte?

      C'est plus le cas depuis un moment , tu peux avoir un kernel libre etun chipset nforce/nforce2 pleinement supporté ( a part l acpi et encore )
      - reseau -> module forcedeth inclu de base dans le noyau 2.6
      - son -> alsa
      - ide/acpi/mem -> kernel

      bref encore une legende urbaine.
      • [^] # Re: Oui, mais...

        Posté par  . Évalué à 3.

        reseau -> module forcedeth inclu de base dans le noyau 2.6

        Tiens ça je ne savais pas.

        son -> alsa

        Normal leur truc c'est un chipset Intel i810 bricolé.

        bref encore une legende urbaine.

        Au bout de six mois de galère heureusement que ça à commencé à marcher sinon la carte serait passée par la fenêtre!

        Il reste le firewire qui ne marche pas. Le port est détecté mais impossible de faire marcher quoi que ce soit dessus. Je peut brancher ce que je veux dessus, nada, que dalle, niet. Ca marche nickel sur mon portable avec la même version du noyau.
        • [^] # Re: Oui, mais...

          Posté par  (site web personnel) . Évalué à 2.

          Euh... la carte son multichanel qui multichane pas en ALSA, et le fameux pilote réseau est considéré comme très expérimental car issu "d'ingénierie inverse". C'est pas ce que j'appelle un super libre décent et Nvidia fait tout pour décourager les devs.
          Au passage c'est bien l'apic (et pas seulement l'acpi) qui est buggé sans workaround fiable.
    • [^] # Re: Oui, mais...

      Posté par  (Mastodon) . Évalué à 2.

      il me semble qu'il n'y a pas que via et nvidia qui font des chipset amd. Il y'a SIS aussi.
    • [^] # Re: Oui, mais...

      Posté par  . Évalué à 2.

      VIA : j'ai eu tellement de problèmes avec

      Tu n'as pas eu de carte à base de NForce2, toi. Là, on commence à regretter Via. L'an dernier j'ai acheté une Asus A7N8X deluxe (sortie quelques mois auparavant) et j'ai mis des mois à obtenir un support correct. Au début il n'y avait même pas d'UDMA (pour cause de chipset tordu non standard), pas d'USB2, un firewire non standard qui ne fonctionne toujours pas aujourd'hui, pas d'agp (il ne marchait qu'à condition d'avoir une CG NVidia), le chip réseau avec un driver proprio (qu'est-ce qu'il y a de secret dans un chip 10/100 ??). J'ai passé un temps fou à récupérer et compiler chaque nouvelle version du noyau pour obtenir petit à petit une machine fonctionnelle.

      On peu cracher sur Via mais ils font quand même plus d'efforts que NVidia. Ils ont récemment fourni du code pour le support des chipsets pour mini-itx et prévoient d'ouvrir le code source de ce qui reste à moyen terme (chip Mpeg 2 des C3 M II).

      Nvidia : Une partie des drivers n'est pas libre (chip réseau, je crois

      Yep. Je ne l'ai jamais installé ce truc. J'ai 2 ports réseaux sur ma carte et ça me saoulait de devoir pourrir un noyau pour ça alors je ne me sert que de l'autre (chipset 3Com, standard, propre, driver libre).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.