j'ai souvent entendu dire que les processeurs PPC etaient à fréquence d'horloge égale très largement supérieurs aux processeurs "pc" (intel, amd...)
J'ai voulu savoir ce qu'il en était, j'ai donc fait un petit test d'encodage en ogg pour voir par moi même.
Le problème c'est que maintenant je ne sais plus quoi penser du tout ! Je sais que ce n'est pas la fréquence brute qui compte pour évaluer la réactivité d'un système, mais malgré tout on peut avoir besoin parfois de ne pas attendre qu'un calcul se fasse.
J'ai donc utilisé le même fichier musical et les mêmes paramètres pour encoder ce fichier. A partir d'un live cd (sur les pc windoze) j'ai lancé linux, copié à partir d'une clé usb le fichier en ram, et lancé le test. Les tests en live cd sont à partir d'un noyau 2.4, sur les linux installé noyau 2.6 minimum. Je n'ai pas compris pourquoi de vieilles machines en live cd calculaient plus vite qu'en version installées. J'ai pensé à une histoire de ram, mais en créant un ramdisk et en lançant de là, sur mon ordinateur c'était encore plus long...
Sans doute que des paramètres manquent pour faire un test "neutre", mais si quelqu'uns à d'autres idées pourquoi il y a de telles différences, merci de m'expliquer.
Ce qui est étonnant aussi c'est qu'en ayant fait le test avec le même fichier il y a qques temps, il me semblait que linux ppc était très légèrement plus rapide que mac os x : seulement depuis je suis passé du noyau linux 2.6.9 à 2.6.11 et de mac os x.3.7 à mac os x.3.9 (mais je crois que c'était déjà 1m20 pour le mac, et un peu moins de 1min20 pour linux ppc, ce qui serait plus logique)
De plus je crois qu'à l'époque en ayant fait le test sur l'athlon4 j'avais eu comme résultat dans les 40 s, ce qui corroborait plus ou moins : proc 2 fois plus rapide, calcul 2 fois plus rapide
les paramètres d'encodages sont :
oggenc fichier.wav --managed -b 128 -M 160 -q 6 fichier.ogg
Athlon 1400 mhz / 256 Mo 43 s (live cd)
Athlon2 1400 mhz / 256 Mo 46 s (live cd)
Athlon3 600 mhz / ? Mo 1 m 47 s (linux dd)
602 bogomips
Celeron 2000 mhz / 768 Mo (au travail)
55 s (linux dd 2.6.11)
50,5 s (live cd)
1 m 08 s (encodage dans ramdisk)
Athlon4 1900 mhz / 512 Mo (ordi perso)
2 m 07 (linux dd 2.6.7) / 1544 bogomips sad
1 m 04 (live cd 2.4) / 1900 bogomips
Macintosh ibook 933 mhz / 640 Mo
1 m 20 (mac os x)
4 m 19 (linux ppc 2.6.11)
Je ne comprends pas du tout pourquoi le linux ppc est aussi lent. Le noyau est précompilé, mais optimisé pour mon processeur. Pour l'athlon4, c'est moi qui ai recompilé le noyau (optimisé athlon), et le système est très réactif généralement. Pourquoi en live cd c'est 2 fois plus rapide, ou plutôt depuis mon noyau compilé 2 fois plus lent ?? De plus le bogomips le mets à la traîne. Et pourquoi un athlon 600 (lent sous linux, ex: firefox) est encore plus rapide à encoder ?
J'ai regardé la taille des fichiers ogg résultants, apparemment c'était toujours la même taille, et je pense que la qualité était toujours pareille (j'ai entré les mêmes paramètres tout le temps).
Journal contreperformances étonnantes de calculs sur diverses machines
14
mai
2005
# Quelques hypothèses
Posté par un_brice (site web personnel) . Évalué à 5.
Si tu me fournis le fichier wav à encoder, je pourrais faire le test en et hors 2.4, histoire de savoir si ça vient d'une mauvaise configuration de ton installation ou bel et bien du kernel.
Ou sinon, tu peut tenter toi même, en prenant la dernière knoppix (en 2.6 et 2.4, sauf erreur) et en l'essayant avec les deux kernels (on doit pouvoir choisir au boot).
Une autre piste pourrait être les CFLAGS des distribs/liveCD utilisés. Par exemple je crois que la Mandrake utilise le coprocesseur arithmétique par défaut dans tout ses paquets (586), au contraire de Debian si je me souviens bien. Dans un encodeur ça doit bien se sentir.
Sinon, je pense que l'absence de gain de perf en ramdisk risque d'être lié au cache : il devait être activé pour le disque, ce qui faisait que l'encodeur n'avait pas à attendre et que donc le gain du ramdisk devait être nul. Comme en plus comme le transfert des données vers le disque dur peut se faire (presque) sans opérations du CPU, au contraire du transfert d'une partie à l'autre de la mémoire, je pense qu'on peut expliquer qu'il y ait carrément eu des pertes (surtout si le fichier et gros).
Et pour le cas du mac, je suspecte encore une fois de mauvais cflags, voir un problème de compilateur, mais tu donne pas d'infos à ce sujet.
[^] # Re: Quelques hypothèses
Posté par B16F4RV4RD1N . Évalué à 3.
Le live cd est knoppix, donc debian. Le noyau est effectivement "optimisé pour rien" et le plus générique possible, pourtant c'est en live-cd que la performance est la meilleure, toute machine confondue (de plus en live cd le calcul se fait dans la ram...)
Pour toutes les machines où j'ai compilé le noyau, j'ai choisi d'optimiser pour le type de processeur que j'avais, pourtant la machine notée athlon3 (600 mhz noyau 2.4 non optimisé) est plus rapide que mon athlon 2000 mhz :(
Pour le mac le noyau est précompilé mais en théorie optimisé G4.
Je vais essayer de faire plus de test avec les live cd pour voir où cela pêche, mais c'est assez long à faire (démarrage machine à chaque fois...). En noyau 2.6 ma clé usb ne montait pas sur une machine, alors je n'ai pas persévéré. Je vais copier le fichier sur dd et rebooterai pour tester cela.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Quelques hypothèses
Posté par un_brice (site web personnel) . Évalué à 5.
Le premier est sur Gentoo, avec mes CFLAGs par défaut :
CFLAGS="-O2 -march=athlon-xp -mcpu=athlon-xp -pipe -msse -mfpmath=sse -m128bit-long -fomit-frame-pointer -frename-registers"
"Temps écoulé : 1m 01,7s"
Le second en chroot sur une Debian sarge mise à jour hier (je ne connais pas les CFLAGS, mais je pourrais chercher)
"Elapsed time: 1m 11.9s"
(chiffres stables sur plusieurs essais sucessifs !)
La version Debian prend à peu près 16% de plus (10 secondes) -> on dirais bien que les paramètres de compilation sont déterminants pour ce test (et, d'après mon tatonage rapide, surtout ceux du sse).
[^] # Re: Quelques hypothèses
Posté par B16F4RV4RD1N . Évalué à 1.
Le CFLAGs dont tu parles, c'est pour la compilation du noyau ou du programme oggenc ? (pour ma part j'utilise le paquet debian du programme, je ne l'ai pas recompilé)
En tout cas les paquets debian pour ce programme sont :
stable (sound): Several Ogg Vorbis Tools
1.0rc3-1: alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc
-> le seul paquet existant est pour i386, donc pour tout type de proc.
J'en viens même à me demander si ce n'est pas l'encodeur ogg qui ajuste les performances (et donc la "qualité" du résultat final) en fonction du proc mais j'en doute un peu. Peut être qu'il faudrait refaire le même test avec des options différentes, ou un autre type de calcul.
Car je ne comprends pas pourquoi un athlon 1400 mhz avec moins de mémoire et sans doute moins de cache est plus rapide en live cd que mon athlon 2000 mhz avec le même test et le même live cd.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Quelques hypothèses
Posté par un_brice (site web personnel) . Évalué à 3.
Je parlais de CFLAGs d'oggenc et libvorbis. Un kernel compilé comme ça tiendras pas 10 minutes (dans mes souvenirs, on peut même pas tout compiler en -O3).
Question idiote : tu as vérifié qu'hdparm et autres s'étaient configurés de la même manière ? Peut être que sur 78 mo ça fait une différence.
Ou sinon, c'est peut être la RAM.. j'ai cru constater que "hdparm -T /dev/hda" retournait en pratique le débit de la RAM (mais va savoir pourquoi)
[^] # Re: Quelques hypothèses
Posté par daggett . Évalué à 4.
C'est bien le rôle de l'option -T: « Perform timings of cache reads [...] This displays the speed of reading directly from the Linux buffer cache without disk access » donc effectivement, on peut s'en servir pour avoir une idée du débit de sa RAM.
(c'est l'option -t pour avoir le débit physique du disque)
[^] # Re: CFLAGS
Posté par foulmetal canette (site web personnel) . Évalué à 3.
Euh, il y aurait pas comme une redondance dans ton CFLAGS ?
Parce que de ce que j'ai compris, -march implique -mcpu et -msse :
http://leander256.free.fr/gentoo/gcc-flags-chap02.html(...)
man gcc :
s/-m128bit-long/-m128bit-long-double ?
Tiens, intéressant le -frename-registers, je note :)
[^] # Re: CFLAGS
Posté par un_brice (site web personnel) . Évalué à 2.
Effectivement, le "-msse" est redondant. Je m'en vais jetter ça de suite (surtout qu'il risque d'être nuisible dans le cas où l'ebuild chercherais à filtrer march).
Et pour le "-m128bit-long" c'est une pauvre faute de copier coller.
[^] # Re: CFLAGS (mode capillotraction)
Posté par foulmetal canette (site web personnel) . Évalué à 4.
[^] # Re: CFLAGS (mode capillotraction)
Posté par un_brice (site web personnel) . Évalué à 2.
# Compilateurs
Posté par Boa Treize (site web personnel) . Évalué à 8.
Je me souviens il y a cinq ou six ans, un développeur Slackware s'était amusé avec l'encodage sur une Alpha. Il était parti de la base, un truc compilé avec gcc sans rien de particulier, puis il était passé au compilateur C fourni par Digital (euh Compaq), puis aux bibliothèques de calcul mathématique fournies par Digital (euh Compaq), puis encore peut être un ou deux autres petits trucs, bref pas grand chose au niveau modification des sources, juste des changements d'include. Résultat : triplage de la vitesse (peut être même plus, c'était vraiment brutal).
[^] # Re: Compilateurs
Posté par B16F4RV4RD1N . Évalué à 1.
Je pense à qu'a compilateur égal, sur des machines test la différence viendra surtout ensuite du processeur. Evidemment il faudra avoir tous la même base pour comparer justement (cache, mémoire, matériel) et changer juste le cpu, mais j'ai fait ces qques test sur les ordinateurs de mon travail.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Compilateurs
Posté par Boa Treize (site web personnel) . Évalué à 4.
Sauf qu'il n'y a pas de « compilateur égal ». gcc sur PowerPC n'est pas « égal » à gcc sur IA32, les optimisations ne sont pas forcément les mêmes, ne sont pas forcément codées pareil, ne sont pas forcément toutes disponibles, etc. Il est bien connu (ou était bien connu il y a quatre/cinq ans) qu'avec gcc sur Alpha, tu as pas la moitié de la performance que tu pourrais obtenir.
# version des vorbis-tools
Posté par thranduil . Évalué à 4.
Il y a de fortes chances que les versions de oggenc soient différentes. Peut être mets tu en évidence un gain de perf sur l'encodeur ?
Ca plus les histoires de compilos sus mentionnées ...
[^] # Re: version des vorbis-tools
Posté par B16F4RV4RD1N . Évalué à 2.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
# Car tout est marketing d'apple
Posté par DrahcirBS . Évalué à 1.
Avec les PowerG5, changement complet d'architecture !!! Les PPC reprennent tous les principes et les technologie de l'architecture des X86, (dont la pluspard existe depuis les MMX). Cependant un Athlon 64 est globalemennt supérieur à un PP5 de même fréquence, pourquoi ? Car tout simplement les FSB des PP5 sont au nombre de 2, comme tout les x86, mais ceux des PPC sont synchrone (doivent être utilisés en même temps) alors que ceux des x86 sont asynchrone (ils peuvent être utilisé séparément), de plus ceux des PPC fonctionne réélement à 500Mhz pas à 1Ghz etc... Donc les PPC5 ont un énorme goulot d'étranglement à ce niveau. (Quand on pense que déjà pour les x86 c'est un goulot détranglement).
De plus, les microprossesseur, si on éxécute du 32bit, comparé à tous les autres CPU, et tous mis à une même fréquence, est le Pintium M, et il met tout le monde d'accord !
Cependant les PP5 ont un énorme avantage sur les x86 (mais qui ne suffit pas), il ne contienne que 32 instructions, dont 16 programmables, alors que ce n'est absolument pas le cas des x86 qui en contienne des centaines, dont certaines ne sont plus utilisés mais sont gardé pour la compatibilité. Ce qui permet par exemple d'utiliser les puce PPC5 dans des matos qui nécéssite une grosse puissance de calcul, mais pas de toutes les fonctions d'un PC, comme à bord de l'A380 pour le décodage des MPEG.
La réputation que les PPC sont plus rapide que les X86 est totalement fausse et est entretenu par Apple par simple effet de marketing (Apple c'est 90% de marketing), et ils sont bien aidé car MS bride ses Windows en fonctions des licenses (la Home est bridé par rappord à la PRO, elle même bridé par rapport à une version Server, etc...), et de plus ses derniers ont la réputation de ne pas supporter les calculs et de ne pas être performant. De plus Apple entretien que les PC ne sont que de simple copie des Mac, et si pas mal de logiciel d'infographie étaient optimisé pour Mac et non pour Windows.
D'ailleurs depuis 4/5 ans, Apple est abandonné par les infographes préférant les PC qui sont plus puissant, mais certain revienne uniquement pour avoir MacOsX qui est basé sur Unix.
[^] # Re: Car tout est marketing d'apple
Posté par M . Évalué à 4.
T'as des sources pour tes affirmations?
Comme dit plus haut, les perfs dependent du compilo et il y a fort a parier que gcc est plus optimise pour ia32 que ppc...
[^] # Re: Car tout est marketing d'apple
Posté par tonton . Évalué à 1.
[^] # Re: Car tout est marketing d'apple
Posté par Castor666 . Évalué à 1.
J'ai cru le lire quelquepart, j'aimerai bien avoir plus d'info sur ça.
[^] # Re: Car tout est marketing d'apple
Posté par Boa Treize (site web personnel) . Évalué à 4.
http://developer.apple.com/releasenotes/DeveloperTools/GCC3.html(...)
Voir notamment la partie « Optimization » aux deux tiers de la page, notamment l'option « -faltivec » et surtout « -fast ».
[^] # Re: Car tout est marketing d'apple
Posté par B16F4RV4RD1N . Évalué à 1.
Je crois aussi que Photoshop (pour citer un partenaire apple connu) est particulièrement optimisé sur mac (instructions spéciales sur mac ?). D'ailleurs mac os x offre un système très optimisé de façon générale : firefox rame un peu sur mac os x, mais safari est bien rapide, l'affichage tue vraiment (vitesse de redimensionnement d'image etc.), si on compare avec les effets d'ombres portées et de transparence sous linux, apple est plus fort de ce côté là.
De plus apparemment avec les sorties de mac os x, le système devient de plus en plus rapide, y compris sur vieilles machines (le premier mac os x tourne plus lentement que le dernier). C'est l'inverse avec windoze, il faut des machines de plus en plus "puissantes".
Je pense donc qu'une partie de l'affirmation qu'un proc ppc est plus rapide qu'un proc x86 vient de là, mais pourtant un informaticien m'a expliqué qu'un PPC est plus rapide pour certains nombres de points. Je voulais tester pour du calcul brut, mais apparement ce n'est pas si facile puisque je tombe sur des contradictions au sein même des x86 (un athlon 1400 plus rapide qu'un athlon 2000 mhz ).
Je vais refaire des tests avec d'autres logiciels (calcul effets gimp par exemple)
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Car tout est marketing d'apple
Posté par Yusei (Mastodon) . Évalué à 5.
Pour des raisons de chaleur et d'économie d'énergie, j'utilise en général mon portable à la fréquence minimale fournie par son processeur, soit 663 MHz pour un Athlon MP, et Gnome est parfaitement utilisable (plus que sur mon "vieux" PC équipé d'un Celeron de la même fréquence). Les machines sont devenues tellement puissantes que pour l'utilisation de tous les jours, il est difficile de les distinguer. C'est sur les gros calculs que la différence commence à se sentir.
«l'affichage tue vraiment (vitesse de redimensionnement d'image etc.), si on compare avec les effets d'ombres portées et de transparence sous linux, apple est plus fort de ce côté là.»
Oui, mais là on ne compare pas vraiment le processeur mais plutôt la carte graphique, ses drivers et l'utilisation que l'OS en fait.
# pas représentatif
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Si tu veux minimiser les différences entre application, il faut essayer d'avoir la même version rescente de compilo, et surtout la même version des oggtools. Si les algo sont différents tu ne compares pas la même choses !
Ensuite, un teste multimedia n'est pas représentatif de grand chose étant donné que l'utilisation (ou non) d'instruction comme le SSE ou altivec change tout dans les performances.
"La première sécurité est la liberté"
[^] # Re: pas représentatif
Posté par Yth (Mastodon) . Évalué à 2.
Yth.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.