Journal Conseils pour benchmark processeur

Posté par krumtrash le 09 février 2007 à 02:21.

Étiquettes : aucune

fév.

2007

Hello,

Je vais bientôt changer de processeur (P4C vers C2D).
Je vais faire quelques benchmarks à 2 frs pour voir la différence de patate des CPU.

Le but est juste une évaluation à titre personnel. Pas la recherche de la vérité absolue.

Merci de proposer vos idées/commentaires divers.

Pour le moment:



Benchmark Linux: P4C/C2D

##############################



Configuration:

==================================

P4C 2.8GHz HT + 2x 512Mo PC3200 + i965G

C2D E4300 1.8 GHz 2cores + 2x 512Mo PC5300 + i946GZ



Debian Etch (testing)

Linux 2.6.18-3-686 debian

Linux 2.6.20 maison

Système quasi minimum, pas de démon autre que ceux tournant par défaut ( acpid, atd, cron, dbus/hald, udev, syslogd ). 



Protocole de test:

==================================

Nettoyage si nécessaire et reboot entre chaque test

Test en tant qu'user de base sauf les stress

En console si possible



Test1:

==================================

time tar -xjf linux-2.6.20.tar.bz2



Test2:

==================================

time make



Test3:

==================================

time make -j2



Test4:

==================================

time make -j4



Test5:

==================================

Sous X (xorg+xfce4.4 compilé+iceweasel ouvert), écoute d'un MP3 avec XMMS.

Vérification de la réponse du systéme, des coupures de la musique, etc...



nice -n -10 stress --cpu 16 --timeout 10s

nice -n -5 stress --cpu 64 --timeout 10s

nice -n -20 stress --cpu 1 --timeout 10s

nice -n -20 stress --cpu 2 --timeout 10s

nice -n -15 stress --cpu 4 --timeout 10s

nice -n 0 stress --cpu 4096 --timeout 10s

nice -n -5 stress --cpu 4096 --timeout 30s

nice -n 0 stress --cpu 64000 --timeout 30s

...

D'autres tests avec vm et io: stress --cpu 8 --io 4 --vm 2 --vm-bytes 128M --timeout 10s



Test6:

==================================

Lancer une dizaine de mplayer lisant une vidéo...

# i865G à la place de i965G évidemment

Posté par krumtrash le 09 février 2007 à 02:23. Évalué à 2.

...
# tu pourrais encoder ?

Posté par djibb (site web personnel) le 09 février 2007 à 07:39. Évalué à 2.

encoder une vidéo en H264... ca peut etre pas mal :)

Tester l'ouverture de 20 fichiers ODT ds openoffice en meme temps.

voilou.
- [^] # Re: tu pourrais encoder ?
  
  Posté par krumtrash le 09 février 2007 à 10:50. Évalué à 1.
  
  Tu as une commande toute prête pour mencoder par exemple ?
  - [^] # Re: tu pourrais encoder ?
    
    Posté par hokata le 09 février 2007 à 14:07. Évalué à 4.
    
    mencoder video.avi -oac copy -ovc x264 -x264encopts pass=1:bitrate=900:subq=7:partitions=all:8x8dct:me=umh:frameref=5:bframes=3:b_pyramid:weight_b:ssim:psnr -o video_264.avi
    
    avec ça tu rames. Le nombre de fps pouvant faire benchmark.
    - [^] # H264 vs autre chose
      
      Posté par seginus le 09 février 2007 à 17:19. Évalué à 2.
      
      J'ai récemment fait un test de rippage de DVD en suivant ce tutoriel :
      http://linuxdansmonpc.is-a-geek.com/index.php?page=rip_dvd_m(...)
      
      J'ai fait tenir le film en VO + VF + sous-titres en français et en anglais et chapitrage, tout ça dans 700 Mo
      l'encodage de la vidéo fût très long
      
      mencoder -dvd-device /mnt/backup_dvd/xxx/ dvd://1 -ovc x264 -x264encopts bitrate=VBITRATE:pass=1:subq=6:4x4mv:8x8dct:me=3:frameref=5:bframes=3:b_pyramid:weight_b -vf pp=ci,crop=704:304:0:0,scale=512:216 -nosound -o /dev/null
      puis la deuxième passe
      
      la compression de la vidéo était genre 2 ou 3 images secondes de mémoire.
      
      Cependant, j'ai vraiment été bluffé par la qualité.
      
      le format x264 a-t-il quelque chose de particulier (j'en avais jamais entendu parlé avant)
      peut-on avoir l'équivalent avec xvid ou ffmpeg en choisissant de bonnes options ?
      J'ai fait pas mal de test sur le même film (en plus, le film est nul, mais j'avais que ça :-D) mais je n'ai rien réussi à avoir d'approchant.
      
      Et vous, quand vous voulez de la qualité, vous utilisez quoi ?
      - [^] # Re: H264 vs autre chose
        
        Posté par briaeros007 le 09 février 2007 à 17:33. Évalué à 3.
        
        le x264 provient du codage h264 , qui est du mpeg4-avc.
        En clair c'est le niveau au dessus de xvid (meilleur rapport qualité/debit).
        
        Le probleme du 264 : consomme bcp de cpu pour le décodage, et
        encore plus pour l'enco.
        
        Bon ensuite pour le ffmpeg mpeg4 tu peux essayer en utilisant toutes les options d'augmentation de la qualité comme le double pass et vhq (mais tu les a aussi en x264).
        
        Et vous, quand vous voulez de la qualité, vous utilisez quoi ?
        Si c'est du 640*480 <30fps -> le x264 , ou le mpeg4 (ffmpeg).
        si c'est du 720p ou du 60 fps -> mpeg4, sinon je peux pas lire :D
# Attention le pilote I810 instable en 64 bits

Posté par Ecran Plat (site web personnel, Mastodon) le 09 février 2007 à 09:12. Évalué à 2.

Salut,
si tu veux utiliser ton core duo en 64 bits tu ne peut pas utiliser le chipset graphique interne, il vas te freezer le système par intermittance (sous x).
J'ai le problème avec un Pentium D sur un 945GX.
En 32 bits aucun problème
# openssl speed

Posté par Bruno Muller le 09 février 2007 à 09:15. Évalué à 7.

la commande est dans le titre
- [^] # Re: openssl speed
  
  Posté par Olivier Grisel (site web personnel) le 09 février 2007 à 14:02. Évalué à 1.
  
  Y a aussi les pystones comme bench applicatif en python:
  
  python -c "from test import pystone; pystone.main(100000)"
  
  Ca ne prend pas en compte l'utilisation multi-cpu. Pour info j'ai entre 49 et 52 kpystones sur un C2D.
# un bench applicatif

Posté par Nicolas Boulay (site web personnel) le 09 février 2007 à 10:28. Évalué à 2.

j'ai écrit un bench applicatif, il y a quelques temps. Il demande pas mal de ressources mais je le trouve bien représentatif. Il test aussi l'avantage d'avoir plusieurs cpus.

http://f-cpu.seul.org/~nico/nicobenchv1.0.tar.bz2
"La première sécurité est la liberté"
- [^] # Re: un bench applicatif
  
  Posté par krumtrash le 10 février 2007 à 17:56. Évalué à 1.
  
  Qu'est-ce que c'est long!
  J'ai arrêté lors de la première fois.
  Plutôt que faire les tests en 1-4-8 concurrence , je verrais plutôt 1-2-4 surtout pour un desktop.
  
  Je le re ferais pe si j'ai le temps...
  - [^] # Re: un bench applicatif
    
    Posté par Nicolas Boulay (site web personnel) le 12 février 2007 à 09:17. Évalué à 2.
    
    Tu peux les lancer un par un. Certain sont bien plus long que d'autres (genre celui de compilation).
    "La première sécurité est la liberté"
# gare à l'écriture sur disque

Posté par Nicolas Dumoulin (site web personnel) le 09 février 2007 à 10:48. Évalué à 2.

Dans ton test 1, tu écris sur ton disque dur.
Il serait plus prudent d'écrire le résultat de la décompression dans /dev/null
- [^] # Re: gare à l'écriture sur disque
  
  Posté par krumtrash le 09 février 2007 à 10:52. Évalué à 1.
  
  Avec time tar -xjf linux-2.6.20.tar.bz2 > /dev/null ?
  
  Je ferais les 2 tests. Ca permettra de voir que le HDD est lent ;-)
  - [^] # Re: gare à l'écriture sur disque
    
    Posté par Nicolas Dumoulin (site web personnel) le 09 février 2007 à 11:25. Évalué à 3.
    
    Heu pas tout à fait. Il faut utiliser l'option -O de tar pour que le résultat soit envoyé sur la sortie standard :
    time tar -O -xjf linux-2.6.20.tar.bz2 > /dev/null
    - [^] # Re: gare à l'écriture sur disque
      
      Posté par xumelc le 09 février 2007 à 20:59. Évalué à 1.
      
      ou tout simplement tar -xvf linux-2.6.20.tar.bz2 -C /dev/null
- [^] # Re: gare à l'écriture sur disque
  
  Posté par rictus (site web personnel) le 09 février 2007 à 13:49. Évalué à 1.
  
  time tar -O -xjf linux-2.6.20.tar.bz2 | 7za a -bd -si linux-2.6.20.tar.7z
  
  7-Zip (A) 4.42 Copyright (c) 1999-2006 Igor Pavlov 2006-05-14
  p7zip Version 4.42 (locale=fr_FR.UTF-8,Utf16=on,HugeFiles=on,2 CPUs)
  Creating archive linux-2.6.20.tar.7z
  
  Compressing [Content]
  
  Everything is Ok
  
  real 3m3.355s
  user 4m43.359s
  sys 0m2.889s
  
  37523593 fév 9 13:43 linux-2.6.20.tar.7z
  43375937 fév 4 19:59 linux-2.6.20.tar.bz2
  
  ça limite l'influence du disque, et ça charge mieux les cpus (p7zip est multithreadé)
- [^] # Re: gare à l'écriture sur disque
  
  Posté par Nicolas Dumoulin (site web personnel) le 09 février 2007 à 15:40. Évalué à 2.
  
  Sinon tant qu'à pas utiliser le HDD, autant ne pas lire aussi.
  Un truc du genre pourrait faire l'affaire :
  time for i in `seq 1 10000`; do date | md5sum; done | bzip2 > /dev/null
  - [^] # Re: gare à l'écriture sur disque
    
    Posté par Nicolas Dumoulin (site web personnel) le 09 février 2007 à 15:43. Évalué à 2.
    
    En fait, non ce n'est pas une bonne idée :-)
    Car le "date | md5sum" est un aléatoire, donc le résultat ne sera pas comparable.
# Absurdité des benchs

Posté par fork_bomb le 09 février 2007 à 17:36. Évalué à 3.

Si tu as à nous poser la question sur les benchs, c'est que tu n'en as certainement pas besoin : tu ne liras jamais 10 vidéos à la fois, ni tu ne feras de make -j4 sur une machine dual core.

Les seuls benchs pertinents sont de comparer les performances des logiciels que tu utilise régulièrement et qui te semblent trop lents sur ton ancienne config...
- [^] # Re: Absurdité des benchs
  
  Posté par NeoX le 10 février 2007 à 20:19. Évalué à 2.
  
  j'irais meme jusqu'a dire
  
  il te faudra que tes applis supportent le SMP pour utiliser potentiellement les 2 coeurs.
  
  ainsi une appli non prevue pour tournera probablement moins vite sur le core 2 duo que sur le P4
  
  en effet par ex :
  P4 2.8Ghz
  Core2Duo 2x1.8Ghz
  
  si ton appli ne gere pas les 2 coeurs elle tournera sur un coeur à 1.8 au lieu du 2.8 que tu avais precedemment
  - [^] # Re: Absurdité des benchs
    
    Posté par fork_bomb le 10 février 2007 à 20:32. Évalué à 3.
    
    Oui, mais il ne faut pas oublier que le core2 et le pentium4 sont deux processeurs très différents. Il ne serait pas surprenant que un core2 solo à 1.8 soit au moins aussi puissant qu'un pentium4 à 2.8
  - [^] # Re: Absurdité des benchs
    
    Posté par lurker le 10 février 2007 à 21:51. Évalué à 2.
    
    si ton appli ne gere pas les 2 coeurs elle tournera sur un coeur à 1.8 au lieu du 2.8 que tu avais precedemment
    
    C'est bien connu, la performance d'un processeur dépend uniquement de sa fréquence, qui est la mesure ultime de toute chose.
    
    L'ex-marketing Intel, ce fléau.
# Résultat du bench

Posté par krumtrash le 11 février 2007 à 22:40. Évalué à 2.

Très partiel car je n'ai pas tout fait finalement.
Je met juste le chiffre real pour time.

Le tout sous le noyau de Etch: 2.6.18 en 32bits.

time tar -O -xjf linux>/dev/null
P4C: 0m25.996s
C2D: 0m18.541s

time make
P4C: 6m48.549s
C2D: 5m14.156s

time make -j2
P4C: 5m56.548s
C2D: 2m45.783s

openssl speed
P4C: http://krumli.free.fr/piti/P4C.txt
C2D: http://krumli.free.fr/piti/C2D.txt

Conclusion:
Un C2D à 1.8 GHz est plus rapide qu'un P4C 2.8 Ghz en mono tache (sauf qlq résultat de openssl speed ). En multi évidemment le P4 est largué ;-)

Dans le ressenti à l'utilisation, c'est aussi positif. Le P4C ne ramait pour ainsi dire jamais mais le C2D donne une bien meilleur impression de réactivité ou pour les petites charges ( ouverture de synaptic, firefox, etc... ).

Cette impression est pe aussi relative à la carte graphique (GMA3000 intégré + driver libre) qui me semble bien plus rapide en 2D que mes CG précédente: NV6600GS avec driver proprio et CG du i865G (Intel Extreme Graphics 2 ) avec le driver libre.

Très content par le changement donc!!!
# Idée

Posté par fork_bomb le 14 février 2007 à 17:48. Évalué à 2.

Pourquoi pas des tests de traitement d'image, par exemple avec imagemagick ?

Suivre le flux des commentaires

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