Tu n'as pas tort mais vu que ca supporte aussi les plugins LADSPA et toutes les fonctionnalités de traitement audio, tu peux très bien l'utiliser pour cela. Sauf qu'en plus, tu peux t'amuser à du mixage grâce au multipiste.
Bon, c'est un peu la différence entre Gimp et KPaint mais qui peut le plus peut le moins, non? :-)
Bon, je ne suis pas un expert mais d'après ce que je comprends de la dépêche, elle prétend exactement ce que tu entends être une croyance erronée : un point-jar LGPL peut être importé par un code non LGPL. Mais si tu modifies le .jar importé, alors tu dois publier les modifications.
C'est exactement la même chose que "linker" avec une bibliothèque LGPL, autant que je comprenne.
On dirait que cette news ne dissipe pas tous les doutes :-)
No, pas que je sache, c'est juste que plus tu as de refroidissements liés à des ventilateurs, plus tu as de risques de panne sur le long terme de quelques uns de tes ventilateurs et du coup un mauvais refroidissement de l'ensemble de la machine.
Je rêve d'une retour à un refroidissement passif, sans ventilos. Ca, ca ne tombe jamais en panne.
Quelles affirmations? infirmées par qui? Apple?
Peux tu m'expliquer :
1/ Pourquoi Apple choisit justement gcc apparemment connu pour être assez médiocre sur P4?
2/ Pour ils ont visiblement selon le rapport de Veritest passer beaucoup de temps à faire des tests de flags, à optimiser une librairie malloc spécifique, et à choisir un flag -freorder-block-and-partition qui permet de l'optimisation en feedback, tout cela pour la plateforme G5 mais pas P4?
3/ Pourquoi ils utilisent le compilateur Fortran NAG qui est bien connu comme étant entre 30% et 40% plus lent que tous les autres compilateurs, y compris Portland et Lahey?
Va-y, je t'écoutes, avec mon 'foie inébranlable' (je ne te le fais pas dire. Me prendrais bien une bière :-)).
Pour finir, dès que tu as 5000 euros à me donner, je me prend une mono-proc IA-64. En attendant, je me contenterai d'un dual-Opteron pour moins de 1000 euros.
Si tu avais bien lu mes messages, tu aurais vu que je considère le PPC970 comme un très bon processeur. Mais que je m'offusque de ceux qui essayent de faire croire qu'il 'pulvérise' les x86, ce qui est juste complètement faux. Ils le font avec des arguments qui oscillent entre le FUD (la news) et le mensonge et la malhonnêteté patentés (Apple). Si tu veux des infos fiables sur le PPC970, prends les chez IBM, pas chez Apple. Ils savent de quoi ils parlent, eux.
Juste pour indiquer ce lien sur les benchs d'Apple. Paul Hsieh est un peu virulent ici, ce qui surprenant vu que c'est généralement un grand spécialiste de soft reconnu qui fait entre autres des soumissions aux commités Spec. Il n'empêche que ces arguments sont convaincants :
Pour ce qui est de gcc, je pense que tu as raison pour les x86 en général (gcc est plus optimisé), mais cela ne semble pas être le cas pour le P4 en particulier, qui a une architecture bien spécifique. C'est pourquoi une comparaison avec l'Opteron est plus intéressante.
J'ai lu ton lien (rapidement, je l'avoue). Il dit que la PPC 970 est 32% plus rapide à fréquence équivalente sans l'Altivec que le P4 en flottant scalaire. Sachant que le P4 a 50% de fréquence en plus, je te laisse imaginer qui sort vainqueur de l'affaire. Sachant que l'Opteron est plus rapide à 1.8GHz en flottant que le P4 à 3GHz, ben voila.
De plus, il utilise le compilateur du Portland group qui dans sa version 4 est bien loin derrière le compilateur Intel et semble avoir du mal avec le SSE2.
Je note, cela dit, que l'auteur précise bien qu'il s'intéressait surtout à voir l'évolution entre G4 et G5, donc on ne peut pas non plus trop lui reprocher ces différences. De plus, sur le code vectoriel, je ne suis effectivement pas convaincu qu'en utilisant par exemple le dernier compilateur Portland qui semble s'approcher du niveau de performance du compilateur Intel tout en étant plus solide, un P4 ou un Opteron atteindrait le gain observé avec l'Altivec.
Je suis convaincu comme toi que le PPC970 est un très bon processeur, très performant. Et comme toute architecture, il a ses situations privilégiées et ses situations plus problématiques. Pour ce qui est de Spec, il ne faut pas oublier qu'il s'agit d'un ensemble d'applications réelles, comme gcc, gzip ou bzip2. Le score est une moyenne géométrique mais il est aussi intéressant de regarder les scores individuels des applications pour voir justement les situations particulières de chaque architecture.
Ma prochaine machine sera une bi-Opteron. Si une carte mère bi-PPC970 avec les processeurs adaptés était disponible à des prix comparables, je pense que mon choix serait beaucoup moins évident.
Faux. Ces estimations de performance sont par IBM sous AIX avec un compilateur PPC d'IBM bien optimisé. Ils sont ce que l'on peut avoir de mieux pour la plateforme PPC et Apple ne fait pas de compilateur : elle prendra ce qui est disponible. Donc cette comparaison est valable.
Avec GCC, le PPC870 atteint 800 SpecINT sous MacOSX avec gcc contre 950 pour un Opteron 1.8GHz sous Linux. Donc, avec gcc, la différence est encore plus flagrante!
Ecoutes, si ca t'amuses de croire que ces résultats sont valides, c'est ton affaire après tout.
Le scheduler PPC est bien meilleur car les specs sont connus et qu'IBM s'est foulé d'apporter ce qu'il faut pour qu'il fonctionne bien (il y a intérête vu son engagement à Linux).
Pour ce qui est des flags, SPEC n'est pas threadé donc l'HT ne sert à rien et SSE2 apporte un gain en gros de moins de 5%. Donc, faire des concessions la dessus est de peu de poids. Par contre, utiliser un compilateur qui ne 'schedule' pas correctement sur l'architecture, c'est clairement limiter les performances de la machine.
J'en ai aussi assez marre de voir ressortir systématiquement ce papier de la NASA qui date d'il y a 3 ans pour preuve qu'Altivec est grandiose. Oui, Altivec est pas mal. Non, rien ne te dis que depuis trois ans, il n'est pas possible que d'autres systèmes n'aient pas acquis des gains similaires.
En plus, sélectionner des images ou des fichiers de traitement bien adaptés permet de faire croire tout et n'importe quoi : Intel a voulu montrer les gains du SSE2 avec Lightwave. Sur les images proposées par Intel, les gains sans et avec SSE2 étaient il est vrai impressionants. Sur d'autres, les gains étaient faibles.
Altivec ou pas, les comparaisons que j'ai lues sur Ace's, sur Digital Video ou sur Xbitlabs montrent qu'une fois que tu sors des sentiers balisés d'Apple, tu n'observes jamais les gains qu'ils indiquent dans leurs pubs.
Une fois de plus, je trouve extrêmement suspect qu'Apple n'ait à aucun moment fait intervenir l'Opteron dans ses comparaisons : contrairement au P4, il est difficile de trouver des options de compilations qui ne plaisent pas à un processeur AMD, surtout avec gcc qui a été bien optimisé sur cette plateforme.
IBM ont eux-même déclaré que le PPC970 aurait à 1.8GHz en gros les performances d'un P4 2.8GHz (ce qui est tout à fait respectable).
Mais à part ca, bien sur, tu préfères croire Apple.
IBM a probablement raison et d'ailleurs n'est pas le seul à le dire. Par contre, n'ayant que 10 unités de traitement, je doute qu'il puisse traiter 12 instructions en parallèlle. :-)
D'autre part, je suis d'accord avec toi qu'il n'est pas simple de savoir qu'elle est la meilleure architecture rien qu'en regardant l'architecture. Au final, ce sont les performances finales qui tranchent.
Quant à Photoshop, j'attends de voir : j'entends toujours les adorateurs de Mac parler le la vitesse de Photoshop sur Mac par rapport aux x86. Quand je lis des tests sur Ace's Hardware ou Digital Video, curieusement, les résultats sont beaucoup plus mitigés.
Bon, personnellement, je m'en fiche, mon prochain système sera un bi-opteron et Gimp sous Linux tournera dessus.
Mais au vu des résultats SPEC en entiers, je suis prêt à parier que l'Opteron est au moins aussi rapide sinon plus que le PPC970.
Rien ne vaut le forum d'Ace Hardware pour avoir de bonnes infos techniques. Alors, par exemple, un commentaire d'Andi Kleen, le responsable du portage du kernel sur Opteron/AMD 64 (aucune raison d'être pro-P4) :
Il dit en substance que les optimisations pour P4 de gcc sont très basique et qu'il manque en particulier un bon 'scheduler'.
Il y a d'autres threads qui donnaient plus d'explications (aux alentours du 23 juin), en particulier sur les flags utilisés et en quoi ils étaient particulièrement préjudiciables sur le P4 en particulier, mais le site semble inaccessible pour le moment donc je ne peux pas en dire plus.
Quant à l'altivec, si tu ne vectorise pas ton code toi-même ou que tu n'as pas un compilateur capable de le faire (à ma connaissance, actuellement, seul le compilateur d'Intel le fait un peu), ca ne sert à rien et SPEC n'est pas vectorisé. Donc, il ne peut en rien intervenir sur les scores d'Apple.
SSE2, pour Intel, n'apporte d'ailleurs qu'un gain d'environ 5% sur SPEC selon Intel. Effectivement, sous certaines applications, avec un code optimisé à la main et parfois directement en assembleur, le gain peut être bien supérieur. Mais dans la très grande majorité des cas, les éditeurs de logiciels n'ont pas le temps de faire ce genre d'optimisation : trop long, complexe et surtout casse-pied à maintenir avec les nouvelles versions. C'est pourquoi ces ajouts n'apportent souvent que peu de gains en performance, que ce soit chez Intel ou chez Apple.
La comparaison est effectivement malheureuse. L'architecture des deux pipelines est si différente qu'elle est difficilement comparable.
En l'occurrence, d'après le rapport du MPF, tu as raison mais tu oublies de préciser que les instructions PPC sont décodées en microinstructions (exactement comme pour un x86 récent) et qu'un "multiply-add", par exemple, est décomposée en plusieurs multiply et add. De plus, le pipeline complet est de 16 pour les entiers mais monte à 21 pour les FP et 25 pour les vector FP, ce qui le rend parfaitement comparable, même sans les 8 étages initiaux, à ce que tu trouves en longueur sur l'Opteron.
D'autre part, tu ne peux récupérer à la sortie que 5 résultats par cycle, autant que je comprennes. L'Opteron, par contre, peut dispatcher 3 opérations entières et trois flottantes en un seul cycle, et récupérer autant en un cycle.
Dans les serveurs en rack, c'est depuis toujours que le nombre de ventilateurs est plutôt élevé. Pour compenser du manque d'espace au dessus et en dessous. :-)
Mais dans un desktop (hé oui, c'est ce vante Apple), 9 ventilos c'est pas mal...
Cela dit s'ils sont en roulement à bille, ce n'est pas forcément trop bruyant. Mais la fiabilité à terme me semble moins bonne.
Certes, mais comme tu le dis, ce sont des cycles, à rapprocher de la fréquence du processeur. Et comme le P4 va 3x plus vite que la PPC 750, tu verras qu'il débite en fait plus de multiplications à la seconde, ce qui est ce qu'on attend de lui, non?
Mouais.
Mon Sony avec un Athlon XP 1600+ (loin d'être le plus performant en matière de consommation) durait 2H30 avec la batterie originale, entre 6 et 8 heures avec la batterie additionnelle.
Alors faire des commentaires sur la longévité des portables en se basant sur la consommation du processeur (qui reste tout de même assez faible par rapport au disque ou à l'écran) me parait douteux, tant qu'on ne connait pas la qualité des batteries.
Je me demande s'il n'y a pas confusion avec le PPC690, qui est un processeur serveur moins attaché à la notion de dissipation.
J'ai lu un peu partout des consommations de ~45W mais selon un rapport du Microprocessor Forum d'Octobre 2002, il s'agirait plutot du second, ce qui orienterait la consommation maximum plutôt dans les 60W, au niveau de l'Opteron à même fréquence.
Tiens, d'ailleurs, relire ce rapport m'a bien fait rire en pensant au sujet de ce thread : le pipeline du PPC970 fait tout de même 16 niveaux, 4 de plus que l'Opteron....
T'as raison, va. Je travaille entre autre ici sur un PowerG4 deux processeurs qui est la machine la plus bruyante de ma boite en dehors de la vieille Sun Ultra 5 pourrave.
Je pourrais aussi parler de notre super serveur IBM AIX qui souffle comme la climatisation ou le rack HP avec des Itanium 2 qui compilent à 2 à l'heure.
Au final? Ben les PC que j'ai sont les moins bruyants des machines et les plus rapides en fait.
Des ventilateurs donc des pertes? Certes. Mais comme dit Nico, je doute que le PPC970 fonctionne sans ventilo lui aussi. Et pas de ventilos ne veux pas forcément dire pas de perte. Il n'y a qu'à voir les énormes radiateurs qu'il y a sur certains Alphas.
Et ce que tu dis sur le traitement de texte n'est pas gentil pour les devs de KOffice et d'OpenOffice.
En bref, quand le reste sera mieux que le x86, je basculerai. Mais il n'y a pour le moment rien de mieux en rapport performance-prix. C'est tout.
IBM a fourni des résultats (estimés il est vrai) de 937 en SPECINT et de 1051 en SPECFP à 1.8GHz.
L'Opteron monte à 1150 en SpecInt et 1200 en SpecFP et ca en 32 bits. Il devrait encore pouvoir gagner 5-10% en 64 bits.
Evidemment, il y a des applications ou l'une ou l'autre des architectures sera plus adaptées, mais en moyenne, je doute que le PPC970 arrive à la auteur de l'Opteron ou du futur Prescott.
Il n'es reste pas moins que si quelqu'un me proposait un PPC970 avec une carte mère adaptée au même prix qu'un Opteron, je ne cracherait pas dessus.
Ben oui. Le 'High end' market est plus dicté par la bande passante des bus et de la mémoire, ainsi que par les performances disques que par la puissance pure du processeur. C'est pourquoi Sun et SGI sont encore en course.
De toutes les manières, cet article embaume la mauvaise foi et la propagande. La discussion sur SPEC est d'ailleurs risible à ce niveau : Apple a choisi les flags les plus négatifs pour le P4 dans sa compilation. Prendre GCC, pourquoi pas, mais faire en sorte de mettre le compétiteur sous son jour le plus négatif est... commercial.
Il suffit une fois de plus de comparer les scores de l'Opteron avec GCC à ceux qu'IBM a donné pour son PPC 970 et on voit que l'Opteron est devant, malgré le fait qu'IBM ait lui aussi cherché à optimiser à fond.
Il reste que le PPC 970 n'est effectivement pas loin derrière mais ce n'est pas en le défendant avec de mauvais arguments qu'on lui rend service.
Et ca recommence.
Maintenant qu'IBM a sorti un PPC qui arrive en gros à 80-90% des perfos des x86 les plus rapides, on a droit de nouveau à l'éternelle ritournelle (oubliant au passage que le PPC970 a une consommation électrique qui est tout à fait comparable à un Opteron, par exemple, sauf que l'Opteron est 20-30% plus rapide à fréquence équivalente).
On a droit à l'éternelle discussion sur le nombre de registres, en partant du principe que '4 x plus' c'est forcément 'beaucoup' sans préciser que les performances des processeurs RISC sont beaucoup plus dépendantes d'un grand nombre de registres que les processeurs x86. Ce qui apparait dans ce texte comme une qualité est plus une nécessité pour atteindre des performances comparables.
Il est extraordinairement malhonnête de mettre sur le compte de l'ISA des choix technologiques qui n'en dépendent qu'en partie. L'Opteron d'AMD montre qu'avec la même ISA que le P4, on peut créer un processeur x86 qui consomme autant ou moins que le PPC970 (en utilisant le même processus de gravure au passage, 0.13µ sur SOI), est plus rapide (nettement) à fréquence équivalente et pourtant est un x86.
Il en parle d'ailleurs de l'Opteron, mais 'après-coup' en évitant soigneusement de l'inclure dans son analyse.
La vérité, c'est le PPC 'grand public' a été à la traine en matière de performance par rapport au x86 depuis pas mal d'années. Point barre. IBM a sorti un processeur très intéressant avec le 970 mais il ne fait que revenir dans des gammes de performances que AMD et Intel connaissent depuis plus d'un an. Et cela, sans plus vraiment avoir l'avantage de la faible consommation des génération précédentes.
Il faut avoir un sacré culot pour en déduire la supériorité du RISC PPC sur le x86.
Oui mais ta Mandrake, elle est compilée en 586. Donc sur un 486, va mourir.
Enfin bref, on s'en fout un peu de tout ca. C'est évident que n'importe quelle distribe peut être réduite à une peau de chagrin puisque les composants indispensables sont les mêmes pour tous.
Non, l'avantage de la Slack, c'est que comme Volkerding est tout seul pour faire sa distribution, la seule source de packages (en gros) c'est lui, donc ils sont toujours cohérents, et il ne se prend pas la tête à refaire un système de configuration à lui : il utilise ce qui est donné par les projets Open Source.
Donc quand tu vas sur n'importe quel site de projet Open Source, les docs de configuration que tu y trouves seront toujours valables sur la Slack. Alors que la plupart des autres distributions ont tendance à magouiller la chose pour pouvoir utiliser leur outil à eux.
Tu ne te casses jamais la tête avec des packages 'devel' ou pas : les packages Slack incorporent toujours les headers et tout ce qui est nécessaire à la compilation de projets s'appuyant sur ces packages.
En bref, c'est la distribution la plus respectueuse de tous les projets qu'elle incorpore.
C'est là son principal intérêt.
En gros oui. Il y a eu deux-trois développeurs Slack à une époque mais je crois qu'il est globalement tout seul de nouveau. Il reçoit quelques contributions de ci de là.
Un bien pour un mal : ca l'oblige à faire des choix et du coup, la Slack tiens sur un CD et demi et contient tout ce qu'il faut. J'ai parfois du mal à comprendre ce que les autres distributions mettent dans leurs 8 CD.
Et en plus le CD d'installation est un système Linux complet avec tous les outils de maintenance tout prêt et qui te donne un shell après démarrage. Je l'utilise systématiquement à mon boulot pour tous les dépannages Linux.
[^] # Re: Présentation de Kwave, un éditeur de sons pour KDE
Posté par Richard Van Den Boom . En réponse à la dépêche Présentation de Kwave, un éditeur de sons pour KDE. Évalué à 2.
Bon, c'est un peu la différence entre Gimp et KPaint mais qui peut le plus peut le moins, non? :-)
Cordialement,
[^] # Re: Présentation de Kwave, un éditeur de sons pour KDE
Posté par Richard Van Den Boom . En réponse à la dépêche Présentation de Kwave, un éditeur de sons pour KDE. Évalué à 4.
Cordialement,
[^] # Re: La LGPL s'applique à Java exactement comme pour C/C++
Posté par Richard Van Den Boom . En réponse à la dépêche La LGPL s'applique à Java exactement comme pour C/C++. Évalué à 2.
C'est exactement la même chose que "linker" avec une bibliothèque LGPL, autant que je comprenne.
On dirait que cette news ne dissipe pas tous les doutes :-)
Cordialement,
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Richard Van Den Boom . En réponse à la dépêche X86 contre PPC : Un article fait le point. Évalué à 1.
Je rêve d'une retour à un refroidissement passif, sans ventilos. Ca, ca ne tombe jamais en panne.
Cordialement,
[^] # Re: Mouarf...
Posté par Richard Van Den Boom . En réponse à la dépêche X86 contre PPC : Un article fait le point. Évalué à 2.
Peux tu m'expliquer :
1/ Pourquoi Apple choisit justement gcc apparemment connu pour être assez médiocre sur P4?
2/ Pour ils ont visiblement selon le rapport de Veritest passer beaucoup de temps à faire des tests de flags, à optimiser une librairie malloc spécifique, et à choisir un flag -freorder-block-and-partition qui permet de l'optimisation en feedback, tout cela pour la plateforme G5 mais pas P4?
3/ Pourquoi ils utilisent le compilateur Fortran NAG qui est bien connu comme étant entre 30% et 40% plus lent que tous les autres compilateurs, y compris Portland et Lahey?
Va-y, je t'écoutes, avec mon 'foie inébranlable' (je ne te le fais pas dire. Me prendrais bien une bière :-)).
Pour finir, dès que tu as 5000 euros à me donner, je me prend une mono-proc IA-64. En attendant, je me contenterai d'un dual-Opteron pour moins de 1000 euros.
Si tu avais bien lu mes messages, tu aurais vu que je considère le PPC970 comme un très bon processeur. Mais que je m'offusque de ceux qui essayent de faire croire qu'il 'pulvérise' les x86, ce qui est juste complètement faux. Ils le font avec des arguments qui oscillent entre le FUD (la news) et le mensonge et la malhonnêteté patentés (Apple). Si tu veux des infos fiables sur le PPC970, prends les chez IBM, pas chez Apple. Ils savent de quoi ils parlent, eux.
Cordialement,
[^] # Re: Mouarf...
Posté par Richard Van Den Boom . En réponse à la dépêche X86 contre PPC : Un article fait le point. Évalué à 2.
http://www.azillionmonkeys.com/qed/apple.html(...)
Pour ce qui est de gcc, je pense que tu as raison pour les x86 en général (gcc est plus optimisé), mais cela ne semble pas être le cas pour le P4 en particulier, qui a une architecture bien spécifique. C'est pourquoi une comparaison avec l'Opteron est plus intéressante.
J'ai lu ton lien (rapidement, je l'avoue). Il dit que la PPC 970 est 32% plus rapide à fréquence équivalente sans l'Altivec que le P4 en flottant scalaire. Sachant que le P4 a 50% de fréquence en plus, je te laisse imaginer qui sort vainqueur de l'affaire. Sachant que l'Opteron est plus rapide à 1.8GHz en flottant que le P4 à 3GHz, ben voila.
De plus, il utilise le compilateur du Portland group qui dans sa version 4 est bien loin derrière le compilateur Intel et semble avoir du mal avec le SSE2.
Je note, cela dit, que l'auteur précise bien qu'il s'intéressait surtout à voir l'évolution entre G4 et G5, donc on ne peut pas non plus trop lui reprocher ces différences. De plus, sur le code vectoriel, je ne suis effectivement pas convaincu qu'en utilisant par exemple le dernier compilateur Portland qui semble s'approcher du niveau de performance du compilateur Intel tout en étant plus solide, un P4 ou un Opteron atteindrait le gain observé avec l'Altivec.
Je suis convaincu comme toi que le PPC970 est un très bon processeur, très performant. Et comme toute architecture, il a ses situations privilégiées et ses situations plus problématiques. Pour ce qui est de Spec, il ne faut pas oublier qu'il s'agit d'un ensemble d'applications réelles, comme gcc, gzip ou bzip2. Le score est une moyenne géométrique mais il est aussi intéressant de regarder les scores individuels des applications pour voir justement les situations particulières de chaque architecture.
Ma prochaine machine sera une bi-Opteron. Si une carte mère bi-PPC970 avec les processeurs adaptés était disponible à des prix comparables, je pense que mon choix serait beaucoup moins évident.
Cordialement,
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Richard Van Den Boom . En réponse à la dépêche X86 contre PPC : Un article fait le point. Évalué à 4.
Avec GCC, le PPC870 atteint 800 SpecINT sous MacOSX avec gcc contre 950 pour un Opteron 1.8GHz sous Linux. Donc, avec gcc, la différence est encore plus flagrante!
Cordialement,
[^] # Re: Mouarf...
Posté par Richard Van Den Boom . En réponse à la dépêche X86 contre PPC : Un article fait le point. Évalué à 3.
Ecoutes, si ca t'amuses de croire que ces résultats sont valides, c'est ton affaire après tout.
Le scheduler PPC est bien meilleur car les specs sont connus et qu'IBM s'est foulé d'apporter ce qu'il faut pour qu'il fonctionne bien (il y a intérête vu son engagement à Linux).
Pour ce qui est des flags, SPEC n'est pas threadé donc l'HT ne sert à rien et SSE2 apporte un gain en gros de moins de 5%. Donc, faire des concessions la dessus est de peu de poids. Par contre, utiliser un compilateur qui ne 'schedule' pas correctement sur l'architecture, c'est clairement limiter les performances de la machine.
J'en ai aussi assez marre de voir ressortir systématiquement ce papier de la NASA qui date d'il y a 3 ans pour preuve qu'Altivec est grandiose. Oui, Altivec est pas mal. Non, rien ne te dis que depuis trois ans, il n'est pas possible que d'autres systèmes n'aient pas acquis des gains similaires.
En plus, sélectionner des images ou des fichiers de traitement bien adaptés permet de faire croire tout et n'importe quoi : Intel a voulu montrer les gains du SSE2 avec Lightwave. Sur les images proposées par Intel, les gains sans et avec SSE2 étaient il est vrai impressionants. Sur d'autres, les gains étaient faibles.
Altivec ou pas, les comparaisons que j'ai lues sur Ace's, sur Digital Video ou sur Xbitlabs montrent qu'une fois que tu sors des sentiers balisés d'Apple, tu n'observes jamais les gains qu'ils indiquent dans leurs pubs.
Une fois de plus, je trouve extrêmement suspect qu'Apple n'ait à aucun moment fait intervenir l'Opteron dans ses comparaisons : contrairement au P4, il est difficile de trouver des options de compilations qui ne plaisent pas à un processeur AMD, surtout avec gcc qui a été bien optimisé sur cette plateforme.
Cordialement,
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Richard Van Den Boom . En réponse à la dépêche X86 contre PPC : Un article fait le point. Évalué à 2.
Mais à part ca, bien sur, tu préfères croire Apple.
Cordialement,
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Richard Van Den Boom . En réponse à la dépêche X86 contre PPC : Un article fait le point. Évalué à 5.
D'autre part, je suis d'accord avec toi qu'il n'est pas simple de savoir qu'elle est la meilleure architecture rien qu'en regardant l'architecture. Au final, ce sont les performances finales qui tranchent.
Quant à Photoshop, j'attends de voir : j'entends toujours les adorateurs de Mac parler le la vitesse de Photoshop sur Mac par rapport aux x86. Quand je lis des tests sur Ace's Hardware ou Digital Video, curieusement, les résultats sont beaucoup plus mitigés.
Bon, personnellement, je m'en fiche, mon prochain système sera un bi-opteron et Gimp sous Linux tournera dessus.
Mais au vu des résultats SPEC en entiers, je suis prêt à parier que l'Opteron est au moins aussi rapide sinon plus que le PPC970.
Cordialement,
[^] # Re: Mouarf...
Posté par Richard Van Den Boom . En réponse à la dépêche X86 contre PPC : Un article fait le point. Évalué à 3.
http://www.aceshardware.com/forum?read=105020517(...)
Il dit en substance que les optimisations pour P4 de gcc sont très basique et qu'il manque en particulier un bon 'scheduler'.
Il y a d'autres threads qui donnaient plus d'explications (aux alentours du 23 juin), en particulier sur les flags utilisés et en quoi ils étaient particulièrement préjudiciables sur le P4 en particulier, mais le site semble inaccessible pour le moment donc je ne peux pas en dire plus.
Quant à l'altivec, si tu ne vectorise pas ton code toi-même ou que tu n'as pas un compilateur capable de le faire (à ma connaissance, actuellement, seul le compilateur d'Intel le fait un peu), ca ne sert à rien et SPEC n'est pas vectorisé. Donc, il ne peut en rien intervenir sur les scores d'Apple.
SSE2, pour Intel, n'apporte d'ailleurs qu'un gain d'environ 5% sur SPEC selon Intel. Effectivement, sous certaines applications, avec un code optimisé à la main et parfois directement en assembleur, le gain peut être bien supérieur. Mais dans la très grande majorité des cas, les éditeurs de logiciels n'ont pas le temps de faire ce genre d'optimisation : trop long, complexe et surtout casse-pied à maintenir avec les nouvelles versions. C'est pourquoi ces ajouts n'apportent souvent que peu de gains en performance, que ce soit chez Intel ou chez Apple.
Cordialement,
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Richard Van Den Boom . En réponse à la dépêche X86 contre PPC : Un article fait le point. Évalué à 3.
En l'occurrence, d'après le rapport du MPF, tu as raison mais tu oublies de préciser que les instructions PPC sont décodées en microinstructions (exactement comme pour un x86 récent) et qu'un "multiply-add", par exemple, est décomposée en plusieurs multiply et add. De plus, le pipeline complet est de 16 pour les entiers mais monte à 21 pour les FP et 25 pour les vector FP, ce qui le rend parfaitement comparable, même sans les 8 étages initiaux, à ce que tu trouves en longueur sur l'Opteron.
D'autre part, tu ne peux récupérer à la sortie que 5 résultats par cycle, autant que je comprennes. L'Opteron, par contre, peut dispatcher 3 opérations entières et trois flottantes en un seul cycle, et récupérer autant en un cycle.
Cordialement,
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Richard Van Den Boom . En réponse à la dépêche X86 contre PPC : Un article fait le point. Évalué à 1.
Mais dans un desktop (hé oui, c'est ce vante Apple), 9 ventilos c'est pas mal...
Cela dit s'ils sont en roulement à bille, ce n'est pas forcément trop bruyant. Mais la fiabilité à terme me semble moins bonne.
Cordialement,
[^] # Re: [RC]ISC
Posté par Richard Van Den Boom . En réponse à la dépêche X86 contre PPC : Un article fait le point. Évalué à 2.
Cordialement,
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Richard Van Den Boom . En réponse à la dépêche X86 contre PPC : Un article fait le point. Évalué à 3.
Mon Sony avec un Athlon XP 1600+ (loin d'être le plus performant en matière de consommation) durait 2H30 avec la batterie originale, entre 6 et 8 heures avec la batterie additionnelle.
Alors faire des commentaires sur la longévité des portables en se basant sur la consommation du processeur (qui reste tout de même assez faible par rapport au disque ou à l'écran) me parait douteux, tant qu'on ne connait pas la qualité des batteries.
Cordialement,
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Richard Van Den Boom . En réponse à la dépêche X86 contre PPC : Un article fait le point. Évalué à 2.
J'ai lu un peu partout des consommations de ~45W mais selon un rapport du Microprocessor Forum d'Octobre 2002, il s'agirait plutot du second, ce qui orienterait la consommation maximum plutôt dans les 60W, au niveau de l'Opteron à même fréquence.
Tiens, d'ailleurs, relire ce rapport m'a bien fait rire en pensant au sujet de ce thread : le pipeline du PPC970 fait tout de même 16 niveaux, 4 de plus que l'Opteron....
Cordialement,
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Richard Van Den Boom . En réponse à la dépêche X86 contre PPC : Un article fait le point. Évalué à 1.
Ou se trouve le défaut équivalent des x86 que n'ont pas les PPC?
Cordialement,
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Richard Van Den Boom . En réponse à la dépêche X86 contre PPC : Un article fait le point. Évalué à 3.
C'est ce qui fait toute la différence...
Cordialement,
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Richard Van Den Boom . En réponse à la dépêche X86 contre PPC : Un article fait le point. Évalué à 0.
Cordialement,
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Richard Van Den Boom . En réponse à la dépêche X86 contre PPC : Un article fait le point. Évalué à 4.
Je pourrais aussi parler de notre super serveur IBM AIX qui souffle comme la climatisation ou le rack HP avec des Itanium 2 qui compilent à 2 à l'heure.
Au final? Ben les PC que j'ai sont les moins bruyants des machines et les plus rapides en fait.
Des ventilateurs donc des pertes? Certes. Mais comme dit Nico, je doute que le PPC970 fonctionne sans ventilo lui aussi. Et pas de ventilos ne veux pas forcément dire pas de perte. Il n'y a qu'à voir les énormes radiateurs qu'il y a sur certains Alphas.
Et ce que tu dis sur le traitement de texte n'est pas gentil pour les devs de KOffice et d'OpenOffice.
En bref, quand le reste sera mieux que le x86, je basculerai. Mais il n'y a pour le moment rien de mieux en rapport performance-prix. C'est tout.
Cordialement,
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Richard Van Den Boom . En réponse à la dépêche X86 contre PPC : Un article fait le point. Évalué à 3.
L'Opteron monte à 1150 en SpecInt et 1200 en SpecFP et ca en 32 bits. Il devrait encore pouvoir gagner 5-10% en 64 bits.
Evidemment, il y a des applications ou l'une ou l'autre des architectures sera plus adaptées, mais en moyenne, je doute que le PPC970 arrive à la auteur de l'Opteron ou du futur Prescott.
Il n'es reste pas moins que si quelqu'un me proposait un PPC970 avec une carte mère adaptée au même prix qu'un Opteron, je ne cracherait pas dessus.
Cordialement,
[^] # Re: Mouarf...
Posté par Richard Van Den Boom . En réponse à la dépêche X86 contre PPC : Un article fait le point. Évalué à 6.
De toutes les manières, cet article embaume la mauvaise foi et la propagande. La discussion sur SPEC est d'ailleurs risible à ce niveau : Apple a choisi les flags les plus négatifs pour le P4 dans sa compilation. Prendre GCC, pourquoi pas, mais faire en sorte de mettre le compétiteur sous son jour le plus négatif est... commercial.
Il suffit une fois de plus de comparer les scores de l'Opteron avec GCC à ceux qu'IBM a donné pour son PPC 970 et on voit que l'Opteron est devant, malgré le fait qu'IBM ait lui aussi cherché à optimiser à fond.
Il reste que le PPC 970 n'est effectivement pas loin derrière mais ce n'est pas en le défendant avec de mauvais arguments qu'on lui rend service.
Cordialement,
# Re: X86 contre PPC : Un article fait le point
Posté par Richard Van Den Boom . En réponse à la dépêche X86 contre PPC : Un article fait le point. Évalué à 10.
Maintenant qu'IBM a sorti un PPC qui arrive en gros à 80-90% des perfos des x86 les plus rapides, on a droit de nouveau à l'éternelle ritournelle (oubliant au passage que le PPC970 a une consommation électrique qui est tout à fait comparable à un Opteron, par exemple, sauf que l'Opteron est 20-30% plus rapide à fréquence équivalente).
On a droit à l'éternelle discussion sur le nombre de registres, en partant du principe que '4 x plus' c'est forcément 'beaucoup' sans préciser que les performances des processeurs RISC sont beaucoup plus dépendantes d'un grand nombre de registres que les processeurs x86. Ce qui apparait dans ce texte comme une qualité est plus une nécessité pour atteindre des performances comparables.
Il est extraordinairement malhonnête de mettre sur le compte de l'ISA des choix technologiques qui n'en dépendent qu'en partie. L'Opteron d'AMD montre qu'avec la même ISA que le P4, on peut créer un processeur x86 qui consomme autant ou moins que le PPC970 (en utilisant le même processus de gravure au passage, 0.13µ sur SOI), est plus rapide (nettement) à fréquence équivalente et pourtant est un x86.
Il en parle d'ailleurs de l'Opteron, mais 'après-coup' en évitant soigneusement de l'inclure dans son analyse.
La vérité, c'est le PPC 'grand public' a été à la traine en matière de performance par rapport au x86 depuis pas mal d'années. Point barre. IBM a sorti un processeur très intéressant avec le 970 mais il ne fait que revenir dans des gammes de performances que AMD et Intel connaissent depuis plus d'un an. Et cela, sans plus vraiment avoir l'avantage de la faible consommation des génération précédentes.
Il faut avoir un sacré culot pour en déduire la supériorité du RISC PPC sur le x86.
Cordialement,
[^] # Re: Ma premiere distrib, snif...
Posté par Richard Van Den Boom . En réponse à la dépêche Slackware a 10 ans !. Évalué à 10.
Enfin bref, on s'en fout un peu de tout ca. C'est évident que n'importe quelle distribe peut être réduite à une peau de chagrin puisque les composants indispensables sont les mêmes pour tous.
Non, l'avantage de la Slack, c'est que comme Volkerding est tout seul pour faire sa distribution, la seule source de packages (en gros) c'est lui, donc ils sont toujours cohérents, et il ne se prend pas la tête à refaire un système de configuration à lui : il utilise ce qui est donné par les projets Open Source.
Donc quand tu vas sur n'importe quel site de projet Open Source, les docs de configuration que tu y trouves seront toujours valables sur la Slack. Alors que la plupart des autres distributions ont tendance à magouiller la chose pour pouvoir utiliser leur outil à eux.
Tu ne te casses jamais la tête avec des packages 'devel' ou pas : les packages Slack incorporent toujours les headers et tout ce qui est nécessaire à la compilation de projets s'appuyant sur ces packages.
En bref, c'est la distribution la plus respectueuse de tous les projets qu'elle incorpore.
C'est là son principal intérêt.
Cordialement,
[^] # Re: Slackware a 10 ans !
Posté par Richard Van Den Boom . En réponse à la dépêche Slackware a 10 ans !. Évalué à 10.
Un bien pour un mal : ca l'oblige à faire des choix et du coup, la Slack tiens sur un CD et demi et contient tout ce qu'il faut. J'ai parfois du mal à comprendre ce que les autres distributions mettent dans leurs 8 CD.
Et en plus le CD d'installation est un système Linux complet avec tous les outils de maintenance tout prêt et qui te donne un shell après démarrage. Je l'utilise systématiquement à mon boulot pour tous les dépannages Linux.
En bref, la Slack simple mais de bon goût.
Cordialement,