L'auteur, un ingénieur sur l'architecture Pegasos (PPC), pointe du doigt l'ancienneté et la surconsommation électrique de l'architecture X86 par rapport aux puces PPC. Il évoque également le vaste problème des benchmarks et l'optimisation spécifique du compilateur Intel (ICC) pour les tests SPEC.
Même si le ton est très pro-PPC, j'ai trouvé l'article intéressant est suffisamment simple pour toucher une large audience.
Aller plus loin
- OSNews : « Analysis: x86 Vs PPC » (495 clics)
# Re: X86 contre PPC : Un article fait le point
Posté par Christophe Fergeau . Évalué à 9.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Moby-Dik . Évalué à 10.
Si vous voulez de bons articles sur les architectures CPU, lisez Ars Technica et laissez tomber OSNews.
http://arstechnica.com/cpu/index.html(...)
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Christophe Fergeau . Évalué à 2.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Fulgrim . Évalué à 6.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par skimmy . Évalué à 6.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Anonyme . Évalué à 2.
:-)
[^] # Re: X86 contre PPC : Un article fait le point
Posté par mammique . Évalué à 2.
Ha :-) ils remontent dans mon estime ;-pp
[^] # Re: X86 contre PPC : Un article fait le point
Posté par analogue o/ (site web personnel) . Évalué à 1.
J'y vais...ArsTechnica, the PC's enthusiast's resource
hum...
[^] # Re: X86 contre PPC : Un article fait le point
Posté par un_brice (site web personnel) . Évalué à 4.
Ceci dit, c'est vrai que, s'ils sont bien neutres, le choix de ce nom est maladroit.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par gallenza . Évalué à 2.
Un PC répond à un cahier des charges dont les plus importanes sont d'être produit par IBM et d'avoir un CPU X86.
Et il existe des formes très répandues d'ordinateurs équipés de CPU X86 et appelés "Compatible IBM PC".
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Adrien Bourdet . Évalué à 2.
j'ai un bouquin qui parle entre autre des differentes versions du PC, il y a bien une sorte de machine ancienne qui se nomme PC, puis sont venu les AT et ATX :)
(si j'ai bien pigé)
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Tof . Évalué à 2.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Nÿco (site web personnel) . Évalué à 2.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Jak . Évalué à 1.
http://www.arstechnica.com/cpu/03q2/ppc970-interview/ppc970-intervi(...)
Ça n'est pas très clair, je trouve, mais a priori, gcc sera le compilo le mieux optimisé pour PPC 970/Power4, de sorte qu'IBM n'ait pas à se soucier de maintenir son propre compilo.
[^] # Compilo...
Posté par Quzqo . Évalué à 1.
1. le compilo' utilisé actuellement sur les Power G5 dans l'optique MacOS 10.2.7 est effectivement gcc
2. le compilo' utilisé pour les futures versions Mac OS "full optimized" PPC 970 sera une version adaptée du compilo' IBM pour les Power4 (!= Power G4 !)
mais bon... ce n'était peut-être qu'un argument marketing pour inciter à l'achat...
# Re: X86 contre PPC : Un article fait le point
Posté par the_freeman . Évalué à -1.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Anonyme . Évalué à 4.
# Re: X86 contre PPC : Un article fait le point
Posté par Richard Van Den Boom . É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: X86 contre PPC : Un article fait le point
Posté par Moby-Dik . Évalué à 1.
Heu, pour l'instant, je ne crois pas qu'on aie beaucoup de benchmarks "real life" (à part les résultats SPEC d'Apple obtenus avec un compilo différent ;-)).
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Richard Van Den Boom . É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: X86 contre PPC : Un article fait le point
Posté par gallenza . Évalué à 1.
Tu me diras que l'utilisateur finale de Window$ s'en fout puisque son OS est compilé avec le compilo Intel, mais pour nous utilisateurs de logiciels libre et ben ça sert à rien de parler de perf dont on ne peut pas profiter...
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Richard Van Den Boom . É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: X86 contre PPC : Un article fait le point
Posté par Julien MOROT (site web personnel) . Évalué à 2.
Attendons la publication de benchmark sur des sites indépendants avant de se prononcer...
# Mouarf...
Posté par Nicolas Boulay (site web personnel) . Évalué à 8.
... instruction converter cannot remove the inherent complexity present in the x86 instruction set and consequently x86 is large and inefficient and is going to remain so.
Cela me fait de lire ça... le code x86 est plus compact qu'un code arm thumb, or un des très gros problème de l'itanium est l'explosion de la taille du code. Le ppc n'échappe pas à la règle. C'est un des avantages du cisc sur le risc.
In the high end markets, RISC CPUs from HP, SGI, IBM and Sun still dominate. x86 has never been able to reach these performance levels even though they are sometimes a process generation or two ahead.
Arf... c'est beau de lire de telles bétises :( Au boulot, sur une application bien bourrine (simulation vhdl et synthèse), un celeron 1.7Ghz en archi UMA (mémoire video piqué sur la mémoire vive) est 30% plus rapide qu'une Sun avec un cpu Ultra III @ 650Mhz. Je vous laisse faire le scaling avec des cpus en vente en ce moment...
"La première sécurité est la liberté"
[^] # Re: Mouarf...
Posté par Richard Van Den Boom . É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: Mouarf...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Et encore ! C'est vrai pour tout ce qui est serveur et base de donné mais pas pour ce que l'on appellait les "stations de travail" qui ont du boulot purement bourrin. Par exemple, dans la 3D, les fermes de rendu sont passé de SGI au PC. Et maintenant, les stations "des artistes" passent de SGI àau PC sous Linux.
En CAO, c'est pareil. (il suffit juste que qqun sorte des cartes 3D opengl aussi rapide que celle de SGI et le tour est joué)
"La première sécurité est la liberté"
[^] # Re: Mouarf...
Posté par Christophe Fergeau . Évalué à 1.
[^] # Re: Mouarf...
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Mouarf...
Posté par Nicolas Roard (site web personnel) . Évalué à 2.
Ah ? je suis curieux ... *Tout* ce que j'ai pu lire sur la question reconnassait in fine qu'Apple avait joué honnêtement et mis les bons flags pour assurer les meilleurs perfs avec gcc du P4.
Il y a eu aussi le bench du type de la Nasa, qui donnait des résultats intéressants, et d'ailleurs, proches de ceux d'Apple.
De plus, un truc est quand même oublié, c'est l'Altivec. A priori pour certaines applis, ça donnerait un *énorme* boost (cf le type de la nasa et son test). Alors, bien sûr, ça ne peut pas s'appliquer à n'importe quel code, mais bon du coup, les présentations d'Apple pendant la Keynote semble tout à fait vraisemblables.
[^] # Re: Mouarf...
Posté par Richard Van Den Boom . É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: Mouarf...
Posté par Nicolas Roard (site web personnel) . Évalué à 3.
Et ? idem pour les optimisations gcc pour powerpc 970 hein ...
en particulier sur les flags utilisés et en quoi ils étaient particulièrement préjudiciables sur le P4 en particulier,
Justement, sur ce que j'ai pu lire à la suite de l'article qui avait critiqué le bench qu'apple avait montré, il citait en particulier la désactivation de l'hyperthreading et la non-utilisation de sse2 ... Hors, la désactivation de l'hyperthreading donne en fait dans ce cas là un score supérieur (comme le montre les tests de Dell, ou l'hyperthreading est là aussi désactivé) et sse2 était activé (la confusion portant sur l'utilisation du flag "sse", qui en fait génére du code sse2 si dispo).
Quant à l'altivec, si tu ne vectorise pas ton code toi-même [...] ca ne sert à rien et SPEC n'est pas vectorisé.
Ben oui, mais c'est pour ça que SPEC n'est pas forcément représentatif de l'utilisation réelle : les applis qui ont été montrées lors de la keynote bénéficient par exemple de l'altivec, et ça peut expliquer pourquoi, effectivement, ils étaient en gros 2 fois plus rapide que le PC testé ... En fait, le type de la nasa obtient quelque chose comme un ordre de grandeur en plus en puissance en utilisant l'altivec. Comme on ne passe pas son temps à exécuter du code vectorisé, une accélération x2 comme montré est plausible. Bien évidemment ça ne concerne que les applis qui peuvent utiliser l'altivec; mais elles sont nombreuses, surtout pour le "multimédia" -- et de toute façon c'est bien là qu'on veut aller plus vite, pas à taper du texte dans word...
C'est pourquoi ces ajouts n'apportent souvent que peu de gains en performance, que ce soit chez Intel ou chez Apple.
Ben non ... certes, il faut utiliser l'altivec pour avoir droit à l'accélération (ouah, quelle découverte). Mais le gain est largement sensible à priori, on est loin du "peu de gains".
[^] # Re: Mouarf...
Posté par Richard Van Den Boom . É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: Mouarf...
Posté par Nicolas Roard (site web personnel) . Évalué à 4.
N'est-ce pas ?
Ecoutes, si ca t'amuses de croire que ces résultats sont valides, c'est ton affaire après tout.
Tout ce que je vois, c'est simplement que 1) les arguments du type qui a écrit le papier ralant sur les benchs d'Apple ont été démolis 2) que le type de la nasa avec son test tombe sur des résultats qui -- à priori -- corroborent les résultats d'apple, et surtout, le comportement des machines pendant la keynote
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).
J'avoue que là, je suis surpris : pour moi, gcc sur PowerPC est largement moins optimisé que sur Intel !
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
Je ne parle PAS de ce papier, mais du bench, d'il y a une semaine, d'un type à la nasa qui a testé, pour son programme, un G5. Les résultats qu'il obtient sont dans la ligne de ce qu'a montré apple à la keynote.
http://members.cox.net/craig.hunter/g5/(...)
je suis tombé l'autre jour sur une explication du type sur certains points de son bench, mais je ne remets pas la main sur l'url. De toute façon, en gros ce qu'il dit, c'est que c'est un bench qui veut dire quelque chose pour lui, et c'est tout. Mais que pour lui, effectivement, le G5 est particulièrement satisfaisant.
Maintenant, je ne clame absolument pas qu'Apple a pris dix ans d'avance, etc., simplement, ça m'énerve de voir les gens être d'une telle mauvaise foi sur Apple ! Le G5 à priori est effectivement un très bon processeur, à égalité voir supérieur suivant les applications (altivec, plus une machine avec pas mal de bande passante -- et l'architecture de la machine joue pas mal à mon avis en utilisation réelle) par rapport à d'autres solutions. Il est évident que sur PC on a des procs équivalents, et personnellement je ne peux pas assurer à 100% que les x86 sont encore devant les ppc, ou l'inverse. Il est évident aussi qu'Intel ou AMD augmenteront leurs perfs durant l'année qui vient -- de même qu'IBM pour le ppc970.
Dans les côtés intéressants, IBM clame que ce proc est taillé pour du multiprocesseur, et qu'il a une bonne marge de progression. Donc on verra bien.
Tout ça pour dire, que ce qui m'intéresse moi dans cette histoire, ce n'est pas d'être une groupie histérique d'Apple, et ce ne sont pas les tests SPEC : ils ne veulent pas dire grand chose (c'est mon avis hein).
Ce qui m'intéresse, c'est en utilisation réelle de savoir ce que donne le G5, et ce qui était montré à la keynote était impressionnant de ce point de vue.
A priori, sur ce que j'ai pu lire jusqu'à présent, ces démos là sont pour le moment corroborés par les gens qui ont pu tester les G5 (mais attendons de tte façon leur dispo réelle), et d'un point de vue personnel, ça m'intéresse beaucoup plus que de savoir si le PPC970 est à 100 points au dessus ou en dessous d'un benchmark par rapport à un PC.
[^] # Re: Mouarf...
Posté par Richard Van Den Boom . É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: Mouarf...
Posté par Paerro Trime . Évalué à 3.
En gros il dit qu'IBM n'a aucune excuse pour pas avoir atteint des fréquences plus élevées du premier coup avec le ppc970 alors qu'ils ont une technologie de gravure au top (ce qui est effectivement indiscutable) en prenant comme exemple le fait que l'athlon xp et le p4 ont tous les deux atteint des fréquences supérieures sur le même genre de process. Sauf que dans ces deux cas, c'est la nième révision du proc sur ce process et que ces fréquences élevées ont été accrochées au fil des mois précédent par le duo infernal, qui ont démarré sensiblement plus modestement. IBM a certainement une marge de progression sur son proc. A titre de comparaison, AMD, sur son nouveau processeur, n'a atteint que 1.8GHz sur un process comparable.
[^] # Re: Mouarf...
Posté par Jean Roc Morreale . Évalué à 1.
[^] # Re: Mouarf...
Posté par gallenza . Évalué à 1.
[^] # Re: Mouarf...
Posté par gallenza . Évalué à 1.
Donc pour faire court, les benchs fournis par Apple sont très valables, les attaques ont été démontées une à une, ce sont de bon vrais benchs specs parfaitement validés, et ils n'ont rien à voir avec les +254% (je dis ça au pif qu'on m'attaque pas) de perf d'un G4 par rapport à un P4 sous Photoshop selon saint Steve. En fait je confirme et soutiens toutes les phrases écrites par Nicolas Roard.
Je rajouterais pour apporter ma petite contribution sur les avantages comparés des architectures CISC et RISC et pour les gens comme Richard Van den boom qui semblent munis d'une foie inébrenlable que leur PC n'a pas d'égale et que les autres sont à la ramasse : voilà des SPEC FPU2000 Pentium 4 3.2Ghz HT activé 1261 ; Itanium II 1,5Ghz 2055.
Tout est dit, quand tu a un P4 à 5.2 Ghz tu m'appelles, si tu veux un Itanium II par contre suffit d'aller faire un tour sur le site de HP.
Alors bien sur la on est entre gens sérieux.
[^] # Re: Mouarf...
Posté par Richard Van Den Boom . É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 Paerro Trime . Évalué à 5.
Même si je suis d'accord avec une partie de tes arguments (mouhhahah les benchs constructeurs), y a clairement des trucs où tu as abusé. Il y a (encore) aucun benchmarks indépendants du PPC970, donc la quantification précise de son niveau de performance restera une question ouverte pendant encore quelques semaines.
En dehors de l'entrée de gamme à 1.4Ghz, l'opteron c'est pas donné. Il s'avera peut-être plus performant à fréquence égale que le ppc970 (et encore en FP j'ai des doutes, le ppc970 il a quand même récupéré les deux très chouettes FPU du power4) mais bon un bi opteron 1.8GHz en machine complète assemblée ça navigue sans pb dans les zones tarifaires d'un mac g5 bi-2Ghz (qui en plus est un machine constructeur, et même d'un constructeur cher).
C'est un bon produit l'opteron mais à part le 1,4Ghz il a pas du tout le positionnement tarifaire aggressif habituel des CPU compatibles x86.
Ensuite dire que gcc est un compilateur super optimisé pour ppc est une grosse connerie. IBM a son propre compilo proprio. Va sur les forums d'arstechnica, tu trouveras des mecs qui ont beaucoup d'heures de vol à faire du bas niveau sur cette architecture pour te dire tout le bien qu'il pensent du scheduling des instructions pour ppc avec gcc (objectivement, il y en a qui placent la barre très haut pour considérer un compilateur comme potable donc il faut relativiser, mais les tests SPECs ils en mettent au moins autant dans la vue à gcc sur ppc avec xlc que sur un P4 avec icc donc bon). Alors en plus sur la dernière incarnation de l'architecture ppc qui vient de sortir et qui a pas mal de différence au niveau du pipeline et du nombre d'unités de calcul avec ses prédécesseurs, faut pas espérer trouver dans la dernière release de gcc un scheduling des instructions qui enterre tout.
Par ailleurs, il est bien évident qu'au niveau du calcul vectoriel altivec/VMX domine encore le sujet de la tête et des épaules. Avec à la fois de la matière en abondance (unités de calculs) et une implémentation qui n'est pas soumise au bizarreries pas très propres qu'on peut trouver ailleurs.
[^] # Re: Mouarf...
Posté par gallenza . Évalué à 2.
Cependant por ce qui est du dual-opteron à mon de 1000 euros, je dirais plutot moins de 3000 euros.
Pour ce qui est de pulvériser le X86, je dois dire (cf. mon post un peu plus loin sur un bench non représentatif avec Pari/GP) que c'est par expérience réelle et pas des fumisteries ou des phantasmes. Et je pense que beaucoup de personnes amenées à faire des caluls lourds et longs comme moi font comme moi, elle fuient les X86 et attendent qu'un proc alpha se libère pour lancer leurs calculs.Maintenant c'est sur qu'en bureautique et assimilé les X86 mènent la danse, mais est-ce ça la "puissance de calcul"?
De plus je ne comprends pas que Richard Van den boom ne comprenne pas le choix de gcc comme compilateur : Ce que l'on veut c'est savoir si le CPU est bon, pas le compilo !!! dire le P4 fait 1200 moumoutte parceque le compilo Intel casse des briques, est-ce que ça veut dire que le CPU est meilleur? non. En prenant gcc disponible sur les deux plateformes on à un test représentatif des perfs réelles du processeur, intrinsèquement. De plus faut pas pleurer, compte tenu que je ne suis pas développeur gcc mais que personne ne pourra me contredire sur le fait que gcc est clairement plus optimisé pour le X86 que pour le PowerPC, sachant le boulot fournit pour chaque plateforme. Et puis je maintient qu'en tant qu'utilisateur Linux/BSD/logiciels libres c'est parfait pour nous pour savoir à quelles perfs s'attendre plutôt que de rêver à des benchs qui n'accélèrent que Window$, à moins que l'on me présente des gens compilant leur Linux avec le compilo Intel !!!!
[^] # Re: Mouarf...
Posté par Christophe Fergeau . Évalué à 2.
[^] # Re: Mouarf...
Posté par Christophe Fergeau . Évalué à 3.
1) Les applis 'normales' font très peu de calculs sur les flottants, mais plutot du calcul sur des entiers, et passent encore plus de temps à attendre des données en provenance de la mémoire ou des disques
2) Si t'as une appli qu'a réellement besoin de faire pleins de calculs flottants, tu vas pas être trop con, et utiliser le SSE, ca l'accélerera probablement
3) Je l'ai déjà dit qqpart dans cette news, mais la FPU du p4 est une énorme daube (Intel à préféré favoriser le SSE), faut donc arrêter de faire comme si les benchs sur cette fpu étaient représentative des perfs réelles du proc...
[^] # Re: Mouarf...
Posté par gallenza . Évalué à -2.
Effectivement faut pas en parler !!!! on peut compter les pins, comparer les tailles de sockets, donner sont avis sur la couleur !!!!!
KESKECEUNCPUAPARTUNEFPU??????????
Là je suis sur le cul. De plus SSE est une mauvaise implémentation d'unité de calcul vectoriel, si tu veux bencher avec on ressort ALTIVEC et le tu pleure pendant dix ans, puisque c'est au moins dix fois plus performant que SSE !!!
[^] # Re: Mouarf...
Posté par Christophe Fergeau . Évalué à 3.
Comme je le dis avant, un proc c'est essentiellement utilisé pour faire des calculs entiers, et des IO...
Et là j'ai surtout réagi par rapport aux gens qui agitent ce bench comme si ca se ressentirait dans les applis réelles. En pratique, cette note sur la fpu (fp comme flaoting point hein), puisque ton environnement de bureau, ton traitement de texte, ton compilo, ... font quasiment que des calculs entiers.
Et comme dit, pour les trucs qui utilisent des calculs flottants, les mecs se rendront probablement compte que leur truc est hypra lent sur un p4, et s'ils ont besoin de perfs, ils iront voir chez monsieur intel, et verront qu'ils doivent faire du sse (meme si c'est juste pour porter leur code fp betement, sans essayer de le vectoriser ni rien)
[^] # Re: Mouarf...
Posté par gallenza . Évalué à -1.
[^] # Re: Mouarf...
Posté par Christophe Fergeau . Évalué à 2.
Le but principal de mon post était de dire qu'insister lourdement sur le specfpu pour comparer les deux procs étaient un peu débile, vu que c'est connu que le p4 est mauvais en fp, qu'en plus les calculs en fp sont peu utilisés => le bench ne permet absolument pas de savoir ce que ça va donner au niveau des perfs réelles.
On peut effectivement parler du specfpu2000, mais de là à le mettre en avant... C'est un bench, et c'est loin d'être le plus représentatif. Je t'imagine bien en train de faire des plaquettes commerciales, genre "Regardez, notre proc déchire tout an specfpu2000, blah bleh bloh. Oui, il est deux fois plus lent sous q3, et les gens qui l'utilisent le trouvent plus lent que l'ordinateur X, mais regardez, ON A UN SPECFPU2000 QUI TUE SA MERE, NOTRE MACHINE EST FORCEMENT MIEUX!!".
Enfin ça me dérange pas que tu te branles avec les résultats du ppc 970 au specfpu, mais évite d'éclabousser tout le monde avec tes conneries, ça serait sympa
[^] # Re: Mouarf...
Posté par gallenza . Évalué à 0.
Tu redis quelque chose qui me paraît vraiment absurde, dire qu'on sait que le P4 est nul en FPU mais que c'est pas grave il est bien quand même....non, non et non, si le P4 est mauvais en FPU il est mauvais tout court. Dire un truc comme "en plus les calculs en fp sont peu utilisés", c'est de la pure bêtise, toi sous Word tu en fait pas beaucoup mais y'a plein de gens sérieux qui n'arrêtent pas.Voilà.
[^] # Re: Mouarf...
Posté par Christophe Fergeau . Évalué à 1.
L'unité FPU du p4 est mauvaise, MAIS il y a le SSE (même pour des calculs non vectorisables) qu'Intel recommende d'utiliser à la place. Et les gens sérieux qui arrêtent pas de faire des calculs en FP, ils auront probablement avantage à utiliser le SSE aussi, ce coup là en vectorisant leur code... (merci de pas relancer un troll Altivec/SSE)
[^] # Re: Mouarf...
Posté par Moby-Dik . Évalué à 0.
L'itanium n'est pas RISC. C'est même une sacrée usine à gaz....
[^] # Re: Mouarf...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
L'itanium a 2x ou 3x + d'unité de calcul que les autres processeurs. Si le code rentre bien, cela fuse, sinon il passe du temps à executer des nop. Dans les code réguliers flottant, il se débrouille mais pas dans une compilation par exemple.
"La première sécurité est la liberté"
[^] # Re: Mouarf...
Posté par gallenza . Évalué à -1.
L'Itanium est RISC, il est même PA-RISC binairement compatible !!!!
[^] # Re: Mouarf...
Posté par Moby-Dik . Évalué à 1.
[^] # Re: Mouarf...
Posté par gallenza . Évalué à 1.
HP-UX 11i version 1.6 includes the Aries dynamic code translation technology as an integrated component. Aries is built on the close relationship between the PA-RISC and Intel Itanium instruction sets and provides binary compatibility for PA-RISC binaries on the Itanium processor family. Aries can be used where performance is not critical or where it is not possible to create a native Itanium processor family binary.
Met-toi une master-dik où je pense et ferme la merci.
[^] # Re: Mouarf...
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Mouarf...
Posté par gallenza . Évalué à 1.
Master-dick me réponds "L'itanium n'est pas RISC" quand je cite ses perfs, et là je lui réponds par HP (donc le concepteur du processeur lui-même) "the close relationship between the PA-RISC and Intel Itanium instruction sets" pour lui démontrer que c'est bien une conception RISC et j'ai encore tord, alors là je pense que vous êtes soit malhonnêtes soit cons.
[^] # Re: Mouarf...
Posté par Moby-Dik . Évalué à 1.
alors là je pense que vous êtes soit malhonnêtes soit cons.
Amusant...
[^] # Re: Mouarf...
Posté par koopa . Évalué à 1.
il n'y a plus que 2 stations de travails au catalogue de Sun
Sun Blade 150 et la Sun Blade 2000
- une sun blade 150 se fait éclater par n'importe quel pc carrefour
- quand a la Sun Blade 2000, il suffit de prendre une station a base de Xeon chez Dell, c'est 4 fois moins cher et 2 fois plus rapide
(c'est dommage, car moi j'aimais bien Sun et l'architecture Sparc, et puis c'était vraiment du matériel costaud)
Ils ne restent à ces 2 entreprises que la vente de serveurs pour survivre.
[^] # Re: Mouarf...
Posté par thedidouille . Évalué à 2.
Mais il ne faut pas tout miser sur les benchs sorti d'appli, meme pro. Tu prends une application comme CATIA par ex, les UltraSparcIII sont moins rapide que les derniers intel en mono-CPU, car le compilateur Intel procede a de nombreuses simplification arithmetique (n'est pas conforme aux memes normes, meme pas ANSI), ensuite l'aliasing de ptr n'est pas dutout traite pareil. Ca a l'air de rien, mais ca explique certaines surprises que l'on peut observer.
[^] # Re: Mouarf...
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Disons qu'il y a aussi de bonnes raisons architecturales , les processeurs risc sont en général 30% + rapide en entier à fréquence égale. Or la fréquence est double avec les x86.
En flottant, la pile x87 est une vrai merde en comparaison des beaux registres 64 bits des autres cpu, d'où la différence de perf, qui s'amoindrit d'ailleurs avec l'utilisation du SSE scalaire.
"La première sécurité est la liberté"
[^] # Re: Mouarf...
Posté par thedidouille . Évalué à 1.
a=b/c;d=e/c; est simplifie sur Intel, pas sur Sun (pas de traps)... de plus, avec le compilateur de Sun, avec le proto "void f(float *f1, float f2[2])", ya aliasing de pointeur d'ou aucune optimisation faite par le compilateur, une sous utilisation des registres et un mauvais pipelinning du code (barde de ld/st)...
Malheureusment, aujourd'hui le code s'adapte aux options qui ont ete decidees sur Intel. Resultat, le CPI sur Sun est de 1.30 dans les benchs ou il n'y a pas de cache stalls... (un code legerement optimise a un CPI < a 0.5 si il n'y a pas de data cache stalls).
Je ne dis pas que les proc d'Intel sont bon ou mauvais, simplement qu'il n'est pas judicieux de comparer des proc avec des benchs d'appli dont on a pas beaucoups d'informations.
[^] # Re: Mouarf...
Posté par thedidouille . Évalué à 2.
[^] # Re: Mouarf...
Posté par Raphael Junqueira . Évalué à 1.
[^] # Re: Mouarf...
Posté par gallenza . Évalué à 0.
Donc un exemple pas repésentatif mais voilà ce que l'on peut être amené à vivre quand on fait des vrais calculs :
%1 =
[1000000000000000000000000000000000067 1]
[1000000000000000000000000000000000123 1]
%2 = 2565740
Good bye!
%1 =
[1000000000000000000000000000000000067 1]
[1000000000000000000000000000000000123 1]
%2 = 1507866
Good bye!
Bon alors quoi qu'est dont ? ce sont les deux facteurs premiers optenus après factorisation par un logiciel nommé Pari/GP (n'essayé pas avec Maple ou Mathematica...plantage assuré après plusieurs...jours de calculs) et le temps en milisecondes nécessaire pour le faire.
Donc presque 43 minutes pour un Athlon MP 2200+ (1.8Ghz) contre 25 minutes pour un alpha ev67 à 833Mhz..Ce qui amène à un ratio fréquenc/perf 4 fois supérieur pour l'alpha.....et c'est pas ce qu'on appelle une opération en virgule flottante...et bien sûr l'optimisation du code de Pari/GP est loin d'avantager la plateforme alpha.
[^] # Re: Mouarf...
Posté par Troy McClure (site web personnel) . Évalué à 1.
Mais sur des petits problèmes, mon experience est que le x86 est imbattable. Au boulot on a une dec bi-pro (à 667MHz) qui se traine comme une grosse bouse par rapport à un athlon tout pourri à 1.4GHz (le genre de truc qu'on trouve chez carrouf pour 10% du prix de l'alpha), que ce soit sous matlab ou bien sur n'importe quel petit bout de code compilé à la va-vite.
A chaque fois que je vois un bench mettant l'alpha (ou l'itaniumII) en tête des charts je dois dire que je suis très perplexe.
[^] # Re: Mouarf...
Posté par Moby-Dik . Évalué à 1.
1) on parle du PowerPC et tu nous sors l'Alpha
2) l'Alpha est deux fois plus rapide que l'Athlon sur un problème précis, cela veut donc dire que les processeurs "RISC" sont intrinsèquement supérieurs ??
3) au fait, c'est quoi le prix respectif des deux ordinateurs comparés, qu'on rigole ?
[^] # Re: Mouarf...
Posté par reno . Évalué à 3.
Moui, euh vu les ajouts successifs d'opcode pour ajouter telle ou telle feature (MMX,SSE,SSE2)., la densite du code en x86 a du baissé un peu..
Un exemple, pour l'Opteron, pour toute instructions en mode 64bit pour les opterons, il faut ajouter un prefixe d'un octet.
L'augmentation du nombre de registre compensera un peu, moins de load/store a faire pour cause d'utilisation de trop de registre..
Ceci dit tu confonds la densité du code (une des forces des CISC) et la complexité d'analyse des instructions (une des faiblesses des CISC).
La densité est avantageuse du points de vue bande passante mémoire, occupation des caches mais se paye par une complexité des décodeurs d'instructions bien plus grandes.
Si tu regardes tout les CPU non-compatible 80x86 sorti recemment , ce sont tous des RISC (les VLIW sont beaucoup plus proches des RISC que des CISC), dans ce sens les RISC ont "gagné" (a prendre avec des grosses pincettes).
Par contre, la ou je suis d'accord avec toi, c'est que les x86 explosent tout au niveau performances/prix, la compatibilité avec l'existant l'a emporté sur les avantages ou inconvenient du jeux d'instruction.
[^] # Re: Mouarf...
Posté par Moby-Dik . Évalué à 1.
Ben non, au contraire, le SIMD permet de diminuer le nombre d'instructions nécessaires pour une même tâche ;)
Un exemple, pour l'Opteron, pour toute instructions en mode 64bit pour les opterons, il faut ajouter un prefixe d'un octet.
Non, c'est uniquement pour les opérations sur les entiers 64 bits. Ce qui est logique car dans 99% des cas les entiers 32 bits suffisent.
La densité est avantageuse du points de vue bande passante mémoire, occupation des caches mais se paye par une complexité des décodeurs d'instructions bien plus grandes.
Oui mais les architectures super-pipelinées assorties d'une bonne prédiction des branchements permettent de masquer presque totalement la latence de décodage (le trace-cache du P4 est l'expression la plus aboutie de cette orientation).
[^] # Re: Mouarf...
Posté par reno . Évalué à 1.
Tu as raison pour le mode SIMD, mais je pense quand meme que quand le x86 a evolue du x86, au 286, au 386, la densite de code a du baissé un peu.
Une question cependant: j'ai cru comprendre qu'Intel poussait le SSE2pour remplacer totalement le x87, meme pour les operations ou tu ne peux pas exploiter le SIMD, est-ce possible?
Parce que a ce moment la, il y aurait bien une augmentation de taille provoquée par l'architecture pourrie du x87.
>Un exemple, pour l'Opteron, pour toute instructions en mode 64bit pour les opterons, il faut ajouter un prefixe d'un octet.
>Non, c'est uniquement pour les opérations sur les entiers 64 bits. Ce qui est logique car dans 99% des cas les entiers 32 bits suffisent.
Je crois que c'est faux là: pour toute operations ou tu veux acceder aux 16 registres, ou bien si tu veux utiliser un espace d'adresse memoire sur 64 bit, tu as besoin de l'opcode supplémentaire, meme pour des operations 32-bits.
A propos du trace-cache, il m'a toujours parut tres petit (d'autant plus que les instructions y sont stockees en mode "décompressé"), je serai curieux d'avoir des chiffres sur les temps d'attente provoquées par cette petite taille..
[^] # Re: Mouarf...
Posté par Moby-Dik . Évalué à 1.
Oui, oui.
Parce que a ce moment la, il y aurait bien une augmentation de taille provoquée par l'architecture pourrie du x87.
Heu, je n'en sais rien. Comme les opérations peuvent en SSE se faire entre tous les registres (et pas seulement le haut de la pile), ça économise sûrement des chargements de registres...
pour toute operations ou tu veux acceder aux 16 registres, ou bien si tu veux utiliser un espace d'adresse memoire sur 64 bit, tu as besoin de l'opcode supplémentaire, meme pour des operations 32-bits.
- il faut un préfixe uniquement pour les 8 registres supplémentaires (pas les 8 registres de base)
- en mode 64 bits, l'espace mémoire est automatiquement 64 bits (par définition) ; par contre, il y a un nouveau mode d'adressage "PC-relative" pour éviter au maximum de manier des valeurs absolues 64 bits lors de l'initialisation de pointeurs
[^] # Re: Mouarf...
Posté par h fx . Évalué à 1.
(sans etre extremement mauvais non plus)
ADS lui met 20% dans la vue (mais sapusestpaslibre)
[^] # Re: Mouarf...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Pour l'autre au dessus qui me cause de complexité de décodage quand je parle de sauvegarde de bande passante mémoire. Il devrait garder à l'esprit que la différence entre la vitesse du proc et la vitesse mémoire atteind 10x et ne fait que monter. Beaucoup d'algorithme sont limité par ça. Donc Il vaut mieux que le cpu fasse des trucs complexe plutot que d'attendre la mémoire.
Ensuite, l'IPC moyen d'un code est rarement supérieur à 3, donc rajouter plein d'unité de calcul sert dans très peu de cas. Donc, la vrai limite d'un processeurs devient la lattence mémoire.
Pour ceux qui mette en avant la FSB à 900Mhz du PPC970... qu'il relise pour voir que cela ne cause que de la liason cpu <-> chipset et que la lisaison chipset <-> mémoire, c'est de la bète DDRSDRAM à 333. L'opteron utilise une liaison cpu<-> mémoire direct bien plus efficace...
"La première sécurité est la liberté"
[^] # Re: Mouarf...
Posté par reno . Évalué à 1.
Et ce d'autant plus que les caches instructions font pas mal leur boulot..
>Donc Il vaut mieux que le cpu fasse des trucs complexe plutot que d'attendre la mémoire.
Donc tout ceux qui ont conçus des nouveaux CPU ces dernières années sont des billes: ils ont tous concus des RISC a la place de CISC, même Intel! Les VLIW sont des descendants des RISC pas des CISC: architecture load/store, jeux d'instructions facile a decoder, pleins de registres, etc..
>Ensuite, l'IPC moyen d'un code est rarement supérieur à 3, donc rajouter plein d'unité de calcul sert dans très peu de cas. Donc, la vrai limite d'un processeurs devient la lattence mémoire.
Ta logique me parait curieuse là: si l'IPC d'un code est limité, alors on est limité par la latence des unités de calcule, pas par celle de la mémoire! C'est vrai qu'en général un CPU attend la mémoire, mais je ne vois pas quel est le rapport avec l'IPC.
Pour ce qui est de l'opteron, c'est sûr que leur controleur de mémoire intégré a l'air intéréssant, je suis curieux de voir si AMD arrivera a suivre l'évolution rapide des mémoires..
[^] # Re: Mouarf...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Je te dirais de lire un peu Linus par exemple sur comp.arch. Par exemple, pour avoir des perf correct l'itanium a besoin de 6Mo de cache, ce qui forcément en fait un processeurs hors de prix. Et c'est bien à cause de la taille du cache code.
RISC existe depuis les années 80 et l'augmentation de la grosses différence entre la vitesse de la mémoire et la vitesse du cpu est assez rescente.
VLIW vient du principe de virer l'OOO (risc ou cisc) pour le remplacer par des unités de calculs, c'est encore un autre type de cpu.
Concernant les unités de calcul, il y a maintenant plus de 3 unité de calculs et chaque IPC est utilisé. Il faut voir ce qu'est un cache miss L2. Tu as 100 instructions executés en 50 cycles et tu as un cache miss. paf 200 cycles. donc 250 cycles pour 100 instructions (IPC = 0.4). La grosse limite est là.
"La première sécurité est la liberté"
# [RC]ISC
Posté par Julien Viard de Galbert (site web personnel) . Évalué à 7.
Les concepts développés dans les deux type d'architectures ont été appliqué a tous, et on à des RISC avec des instructions typique des CISC comme les ARM qui possèdent des instructions pour lire ou sauver plusieurs registres en une instruction (on est loin d'un cycle par instruction là) ou des pentium 4 qui quand on a passer le décodage des instruction CISC on un pipeline et une façon de gérer le fichier de registre plutôt typique des RISC (même si 20 niveau c'est un peu poussé, mais au moins ça fait des méga hertz, même si ça fait pas de la puissance!)
J'crois que ya du bon de chaque coté, après choisir entre les deux... ben ça relève du troll, comme d'hab!
[^] # Re: [RC]ISC
Posté par aegir_lf . Évalué à 3.
Une différence concrète : comparaison d'une multiplication en virgule flottante :
Sur un pentium 4 ou un xeon, le pipeline ne peut accepter une opération que tout les 2 cycles horloges, et il s'écoule 7 cycles d'horloges entre le moment où l'opération entre dans le pipeline et le résultat en sort.
La même multiplication en virgule flottante sur un power PC s'effectue entièrement en 3 cycles d'horloge, et le pipeline accepte une opération à chaque cycle d'horloge.
Et comme il y a 2 pipelines pour les op en virgules flottantes sur les PPC, cela veut dire que le CPU peut sortir deux résultats par cycle d'horloge.
[^] # Re: [RC]ISC
Posté par Christophe Fergeau . Évalué à 2.
Le nombre d'étage un peu plus, potentiellement tu as moins d'étage dans un proc risc que cisc du fait des instructions moins complexes.
Par contre, je comprends pas trop tes calculs avec les nb de cycles d'horloge porur faire une opération. Un p4 à entre 15 et 20 étages dans son pipeline si je me souviens bien, donc comment fait il pour effectuer une opération en virgule flottante en 7 cycles ? Même question pour un ppc, je pense pas qu'ils aient des pipelines avec seulement 3 étages...
[^] # Re: [RC]ISC
Posté par aegir_lf . Évalué à 0.
"IA-32 Intel Architecture Optimization reference manual", Table C6. : "FMUL : Latency 7, Throughput 2, Execution Unit FP_MUL".
IBM PowerPC 750FX RISC - Microprocesseur User's Manual, table 6-8. (à ma connaissance, le pipeline FPU du 970 est le meme).
[^] # Re: [RC]ISC
Posté par Christophe Fergeau . Évalué à 1.
Ils disaient pas plus tot un truc du genre "en sortie du pipeline, tu as une instruction qui sort tous les ... cycles (dans des conditions optimales evidemment)" ? Là c'est des chiffres qui me choquent pas.
Il faut garder à l'esprit que la fpu d'un p4 est une sombre daube, à mon avis intel n'a jamais eu comme priorité de faire une fpu performante, et mise tout sur le sse
[^] # Re: [RC]ISC
Posté par Richard Van Den Boom . Évalué à 2.
Cordialement,
[^] # Re: [RC]ISC
Posté par aegir_lf . Évalué à 1.
- 1 résultat tous les deux cycles d'horloge
et
- 2 résultats par cycle d'horloge
il y a un rapport de 1 à 4. Donc même si le P4 allait 3 fois plus vite au niveau horloge, il serait encore dans les choux si ce point là.
Le PPC 970 tirant 2GHz, et le P4 étant encore bien loin des 6 GHz, le P4 est bien loin d'avoir une horloge 3 fois plus rapide.
Si tu compares un PPC970 à 2 GHz, et un P4- 4GHz, et que tu supprimes une des deux FPU du PPC 970, et bien les deux auront exactement les mêmes perfs en ce qui concerne la multiplication flottante. Du moins, c'est ce qu'indiquent les docs techniques d'Intel et d'IBM.
[^] # Re: [RC]ISC
Posté par Christophe Fergeau . Évalué à 1.
[^] # Re: [RC]ISC
Posté par peau chat . Évalué à 1.
Passons à la suite.
Division entière, instruction DIV sur Intel x86 : entre 56 et 70 cycles horloges pour que l'ALU exécute l'instruction et fournisse le résultat.
Sur PowerPC, instruction DIVW, exécution en 19 cycles horloges.
On continue ?
Multiplication entière sur intel : MUL : 14 à 18 cycles horloge.
Sur PowerPC : 2 à 6 cycles horloge.
Par contre pour les additions/soustraction entière : autant pour l'un et l'autre.
Actuellement, les pentiums ayant une fréquence de 4,3 GHz contre 2GHz pour les ppc, il est exact qu'une application s'exécutera BEAUCOUP plus vite sur pentium si... elle ne fait appel ni à la FPU, ni aux multiplications/divisions entières :-)
[^] # Re: [RC]ISC
Posté par Moby-Dik . Évalué à 1.
[^] # Re: [RC]ISC
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Ensuite, au risque de me répéter, la latence mémoire fait toute la différence, un _Opteron_ (pas un athlon ou un P4) à un IPC moyen de 1.9...
"La première sécurité est la liberté"
[^] # Re: [RC]ISC
Posté par Moby-Dik . Évalué à 1.
Cela n'a rien à voir avec le caractère CISC/RISC, mais uniquement avec le design du processeur. Tu peux essayer de trouver les chiffres de l'Athlon pour avoir un son de cloche différent (l'Athlon peut sortir trois résultats flottants par cycle d'horloge).
[^] # Re: [RC]ISC
Posté par Anonyme . Évalué à 4.
[^] # Re: [RC]ISC
Posté par reno . Évalué à 3.
Dans RISC ou CISC, IS ça veut dire Instruction Set, ce qui se traduit par Jeu d'Instruction: les instructions *externes* exécutés par le CPU.
L'implémentation n'a RIEN A VOIR la dedans: pour parler technique il y a eu des RISC implementé avec du micro-code, par exemple.
Et RISC == 1 cycle/instruction, cela n'a quasiment jamais été vrai quasiment toutes les RISC ont une instruction de multiplication qui ne s'execute pas en 1 cycle (si je me souviens bien le MIPS est special la-dessus).
Si tu compares les jeux d'instructions d'un ARM, d'un Sparc, d'un Alpha, meme s'ils ont quelques instructions complexes, ils sont quand meme beaucoup plus proches du concept RISC que ne le sera jamais le jeu d'instruction d'un 80x86.
# Re: X86 contre PPC : Un article fait le point
Posté par Annah C. Hue (site web personnel) . Évalué à 1.
Bravo les voteurs consensuels qui ne connaissent que le petit monde du x86 !
Note : ceci n'est, contrairement aux apparences, pas un troll. Mais ouvrir les yeux à la populace n'est pas chose facile.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Laurent Mouillart . Évalué à 1.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Le ppc 970 @ 2Ghz consomme 92W soit plus que le Barton 3200+ ou le P4 3.2Ghz qui sont à ~80W.
L'archi est complexe certe, mais si elle est si pourris pourquoi personne ne fait aussi bien (pour un prix comparrable) ?
"La première sécurité est la liberté"
[^] # Re: X86 contre PPC : Un article fait le point
Posté par pas_moi . Évalué à -2.
Je crois que c'est l'industrie du nucléaire qui a le même genre d'arguments pour dire que: oui oui, notre technologie produit des déchets dont nous ne savons pas quoi faire, mais n'empêche qu'elle coute moins cher...
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Richard Van Den Boom . Évalué à 0.
Cordialement,
[^] # Re: X86 contre PPC : Un article fait le point
Posté par pas_moi . Évalué à 0.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Richard Van Den Boom . É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 pas_moi . Évalué à -1.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par aegir_lf . Évalué à 3.
Euh... tu es sûr de cela ?
En ce qui me concerne, je n'ai pas trouvé les caractéristiques électriques du 2GHz.
Par contre les docs techniques d'IBM donnent le 1,2 GHz à 19W, et le 1,8 GHz à 42W.
On est loin des x86 qui sont à 70-80Watts.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Richard Van Den Boom . Évalué à 3.
C'est ce qui fait toute la différence...
Cordialement,
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Jak . Évalué à 1.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Richard Van Den Boom . É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 Christophe Fergeau . Évalué à 2.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par aegir_lf . Évalué à 1.
Mauvaise comparaison. Sur les 16 niveaux, 9 servent à décoder quelques 8 instructions simultanément en un seul cycle d'horloge, pour en dispacher jusqu'à 5 (toujours dans le même cycle) qui seront traités parallèlement par 5 pipelines (parmis 12 pipelines disponibles).
donc 9 niveaux, mais pour 8 instructions simultanées :-)
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Moby-Dik . Évalué à 4.
Variante argumentaire : « Quoi, mes tomates sont pas mûres ? Pourtant, elles sont plus rouges que les poireaux du voisin ! »
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
(cf artechnica pour les détails du pipeline)
"La première sécurité est la liberté"
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
M'enfin décoder 8 au 4 instructions, cela prends le même temps...
"La première sécurité est la liberté"
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Richard Van Den Boom . É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 peau chat . Évalué à 2.
Oui, le PPC 970 ne peut récupérer que 5 résultats par cycle, mais il peut en dispatcher 8 par cycle, et en traiter jusqu'à 12 en parrallèle (sur autant de pipeline).
Laquelle des 2 formules est la plus intéressante ? J'en sais rien. Faudrait faire de grosses simulations pour en avoir une idée. IBM prétend que c'est pas la peine d'aller au de la de 5, parce qu'on peut difficilement trouver plus de 5 instructions à traiter en parrallèle dont le résultat de l'une ne dépend pas du résultat de l'autre.
En tout cas, tout ceux qui ont tâté du photoshop sous PPC970 disent pour l'instant que par rapport à du x86 ça déménage.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Richard Van Den Boom . É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: X86 contre PPC : Un article fait le point
Posté par peau chat . Évalué à 2.
La doc publiée par IBM indique 12 pipelines :
- 2 load/store (8 stages)
- 2 Integer (7 stages)
- 1 Branch (7 stages)
- 1 Cond. Reg. (7 stages)
- 2 FPU (12 stages)
Auquels on ajoute 4 pipelines pour l'unités vectorielles (ce sont les instructions qui tritent des données de 128 bits) :
- 1 Integer ( 10 stages)
- 1 Permute ( 10 stages)
- 1 Complex ( 13 stages)
- 1 FP ( 16 stages)
8 + 4 = 12
Mais ça c'est la théorie, parce que dans la pratique je doute qu'on puisse faire du code qui va remplir simultanément les 12 pipelines.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Richard Van Den Boom . É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 patrick_g (site web personnel) . Évalué à 2.
PowerPC 970 = 1.8 GHz = 42 Watts
Pentium 4 = 2.8 GHz = 68.4 Watts
sachant que sur des applis réelles (et pas les benchs bidons de SPEC avec compilo ICC hyper-optimisé) le PPC970 éclate le P4 2.8 je crois que le choix est vite fait.
PS : sachant qu'IBM va sortir avant la fin de l'année des ordis à base de PPC970 sous Linux je pense qu'il sera bientot plus facile de comparer vraiment sur des systèmes comparables (GCC+kernel+distrib).
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Christophe Fergeau . Évalué à 2.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Hum ! Sais-tu ce que sont les testes SPEC avant de passer pour une andouille ? Ce sont des testes applicatifs ! Alors certe on peut optimiser, pour mais tout le monde le fait.
Quans à décrier icc... c'est tellement gamin... Demain, je sors un cpu sans multiplication et j'exige d'être comparé avec les autres cpus sans qu'ils aient le droit d'utiliser leur instruction mul...
Un bench est toujours une mesure du couple cpu+compilo. C'est évidement ! Gcc est un compilo non buggé et est sans doute le seul qui respecte la norme c99 completement, mais ce n'est pas le plus performant !
"La première sécurité est la liberté"
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Christophe Fergeau . Évalué à 3.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Richard Van Den Boom . É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 Moby-Dik . Évalué à 2.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Laurent Mouillart . Évalué à 2.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Jak . Évalué à 1.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par aegir_lf . Évalué à 4.
N'empêche qu'il y a un truc de concret qu'on constate facilement : un portable Mac G4 a une autonomie de l'ordre de 4H, tandis qu'un portable x86 est en général de l'ordre de 2h30.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Yann KLIS (site web personnel) . Évalué à 2.
Donc aux chiottes la soi-disant moindre consommation électrique.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Prends le pentium-M ULV qui tourne à la plus basse fréquence, et je pense que tu aura ce genre de perf et de consomation.
"La première sécurité est la liberté"
[^] # Re: X86 contre PPC : Un article fait le point
Posté par patrick_g (site web personnel) . Évalué à 2.
mais oui.... mais oui.....
pourtant il suffit de 4 secondes pour aller sur le site Apple et voir que le Titanium a une NVIDIA GeForce4 440 Go avec 64 Mo de SDRAM DDR.
c'est 4 secondes de trop pour toi ?
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
"La première sécurité est la liberté"
[^] # Re: X86 contre PPC : Un article fait le point
Posté par farib . Évalué à 0.
Bref, les macs et la fnac, c bien (tm).
[^] # Re: X86 contre PPC : Un article fait le point
Posté par - - . Évalué à 3.
oui.. dans des souvenirs moisis, en effet
les derniers portables apple utilisent une geforce 4mx 440 ou 420 ,
les performances pour un portable sont la. et la durée de la batterie est bonne (bien plus que ce que j'ai pu voir avec des portables)
personnellement, j'aimerai écouter l'opinion QUE de gens qui ont un pc ET un mac (ou autre archi ppc) et qui bourlinguent sur osx et linux .
histoire de parler a des gens qui savent de quoi il s'agit, hein.
parce que les préjugés moisis sur apple me gonflent autant que les préjugés moisis linux.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Christophe Fergeau . Évalué à 1.
« les nvidia ca pue, au moins sur les ati on peut avoir des specs pour faire marcher correctement des trucs comme la mise en veille »
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Nicolas Roard (site web personnel) . Évalué à 3.
Pour l'autonomie par rapport aux pc portables, y'a vraiment pas photo. Par contre je n'ai pas utilisé les nouveaux portables centrino, peut être sont-ils bien et valent le coup.
Mais les portables pc m'ont franchement déçus (je parle pas que pour le mien, mais les problèmes que des copains ont eu avec des dell par exemple).
C'est trop tard maintenant : je suis tellement content de l'ibook que je reviendrais pas de si tôt sur PC. Et puis OS X et bien pratique à avoir par moment (merci MacOnLinux).
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Anonyme . Évalué à 2.
Tu noteras que tu compares un Celeron 600 à un G3 600. Ce qui me semble assez incomparable. Déjà en théorie les PPC semblent plus puissant que les Pentium à fréquence égal (mais pas à prix égal !), mais de plus les Celeron sont largement moins puissant que les Pentium.
Mon frangin à un Celeron 550, c'est légèrement plus puissant que mon PII 350... J'oserai pas faire la comparaison avec un PIII 600.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Nicolas Roard (site web personnel) . Évalué à 2.
en fait, c'est pas tant la vitesse qui joue -- franchement, avec les machines récentes, au moins sous linux, "ça va suffisamment vite" (au moins pour moi). Donc effectivement, ça réponds mieux avec le G3 600, mais c'est pas mon critère le plus important.
Pour rappel, les PIII sont moins rapides que les PII à fréquence équivalente, non ?
M'enfin, se prendre la tête sur les processeurs, ça ne fait pas tout -- voila pourquoi je mets l'accent sur les machines entière (et voila pourquoi je préfèrerais à priori un G5 par rapport à un Opteron). Je donne un exemple (classique) : j'ai une Sun Ultra-60, bi-processeur, 360mhz, carte OpenGL, scsi et tout. Et bien, elle me semble plus rapide que l'athlon 1.2Ghz de mon frère. Et ma Silicon Graphics Indigo2, avec son processeur R4400 à 250Mhz, et bien, elle est exceptionnellement réactive sous X11 (à l'utilisation, je la trouve même plus confortable que l'Ultra-60 ! et puis bon Irix est plus agréable en user que Solaris ;-). Ca n'empêche pas qu'en OpenGL elle se fasse exploser par la Sun, et idem en calcul brut.
Bref, tout ça pour dire que comparer uniquement le processeur, c'est valable si l'archi ne change pas en même temps. Hors, le G5 a une archi très sympathique (même si on devrait avoir des machines équivalentes PC bientôt), avec plein de bande passante. C'est pour ça qu'à mon sens, comparer les chiffres SPEC, c'est de l'uroluditélémétrie et rien de plus (jouer à pisser le plus loin). Le seul test, c'est à l'utilisation, devant la machine, avec les programmes que *tu* utilises. La puissance brute n'est qu'un des paramètres à prendre en compte, et pire, en confort d'utilisation ce n'est pas forcèment le paramètre le plus important, loin de là.
Pour moi (l'utilisation que j'en ai), les PC actuels sont "suffisamment" bon depuis 3-4 ans, en terme de vitesse, de place disque et de résolution graphique. Idem pour les Macs. Ce qui joue alors c'est plus l'archi de la machine et l'environnement logiciel. Et c'est ça qui explique que des gens préfèrent encore utiliser des G3 plutôt que le dernier processeur d'Intel.
Voilou... mon opinion histoire de contrebalancer ces prises de têtes sur des benchmarks qui ne veulent pas dire grand chose :-)
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Christophe Fergeau . Évalué à 2.
Pour les celeron qui sont super lents, c'est peut être vrais pour ceux basés sur les p4, mais les vieux celeron étaient de très bons procs, en général, ils étaient pas loin d'être aussi performants que les p3 équivalents.
E
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Anonyme . Évalué à 2.
> aussi performants que les p3 équivalents.
Oui, enfin sauf ceux qui n'avaient pas de cache... Là ça n'allait vraiment pas vite.
Aurélien.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Christophe Fergeau . Évalué à 2.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Anonyme . Évalué à 1.
(si j'ai bien compris et si ma source est exacte)
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
L'opteron à 3 bus dédiés pour faire des IO qui ressemble à celui du PPC ou se connecter à un autre processeurs (lisaison série, 3.2 Go/s ou 6.4 Go/s, il me semble). L'athlon 64 n'aura qu'un seul port IO. Ensuite, l'opteron dispose d'un bus DDRSDRAM 128 directement sur le cpu. L'athlon 64 sera limité à 64 bits.
Dans tous les cas les nouveaux cpu d'AMD ont bien plus de bandes passantes.
"La première sécurité est la liberté"
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Christophe Merlet (site web personnel) . Évalué à 3.
Perso, j'ai 6 babasses chez moi. Je passe 95% de mon temps sur mon iMac Dv SE ( G3 400 MHz) alors qu'a coté j'ai un Duron 1300 et un Athlon XP 1700+. J'utilise Linux sur toutes mes machines.
Soyons clair, à l'usage, un PowerPC est globalement 2 fois plus performant qu'un x86 à fréquence égale. Et si en 2003, je continue à utiliser quotidiennement mon G3 pour Internet, développer, lire des divx, des DVD, etc. c'est qu'il a la puissance pour le faire et pour ne pas me donner un seul instant l'envie de bosser sur mon Athlon XP 1700+.
Attention, je n'ai pas dit que le G3 400 est plus rapide qu'un Athlon XP 1700+, mais à l'usage il vaut bien un pentium III 1 Ghz (que j'utilise au boulot).
Concernant Mac OS X, c'est bien plus lent que Linux. Le gestionnaire de fenetres de Mac OS X est plus fluide, mais globalement, les applis rame (Mozilla est un bon exemple d'appli pour comparer). Cela dit, mon G3 ne bénéficie pas des accélérations Quartz Extreme.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par cornofulgur . Évalué à 1.
Quelle version de Moz ?
Mozilla 1.4 s'est beaucoup amélioré sur osx. Avant ca ramait sévère.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Richard Van Den Boom . É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 Annah C. Hue (site web personnel) . Évalué à 1.
Sans compter ceux de la baie bête 19".
Cherchez l'erreur.
Sans doute une histoire de mode dans le monde merveilleux des serveurs.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Moby-Dik . Évalué à 1.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Richard Van Den Boom . É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: X86 contre PPC : Un article fait le point
Posté par Nicolas Roard (site web personnel) . Évalué à 2.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Anonyme . Évalué à 2.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Pierre Tramo (site web personnel) . Évalué à 3.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Anonyme . Évalué à 2.
Plus que ça, ce qui compte c'est comment ils sont alimentés. Si c'est du 5V, alors on peut les croire quand ils prétendent que c'est silencieux. Mais si c'est du 12, alors je demande à voir.
> Mais la fiabilité à terme me semble moins bonne.
Pourquoi, il y a un problème avec les roulement à billes ?
Aurélien.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Richard Van Den Boom . Évalué à 1.
Je rêve d'une retour à un refroidissement passif, sans ventilos. Ca, ca ne tombe jamais en panne.
Cordialement,
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Anonyme . Évalué à 1.
> en panne.
Un cluster dans un frigo ? :-)
Enfin, il y a deux sortes de refroidissement pour les frigos, il faut prendre celui qui est silencieux bien sûr.
Aurélien.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Anonyme . Évalué à -1.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Anonyme . Évalué à -3.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Jak . Évalué à 1.
http://www.presence-pc.com/news/commentairev3.php?consul=2&p=10(...)
Je serais curieux de savoir comment ça se passe dans la vraie vie avec ce truc.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Anonyme . Évalué à 1.
Et encore, je connais des frigos vieux de 15 ou 20 ans qui marchent toujours sans problèmes. Donc si la sécurité se résume à changer le frigo tous les dix ans, c'est toujours plus économique.
Ceci dit, c'est un concept intéressant. Mais cher ;-)
Aurélien.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Anonyme . Évalué à 0.
Puisqu'il s'agit toujours d'évacuer la même quantité de kJ.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par - - . Évalué à 2.
c'est moins bruyant qu'un G4
au démarrage, on entend du bruit ,oui, mais très vite les ventilos ralentissent ou s'arretent
un peu comme certains portables G4 ,il y a parfois des coup de ventilo subitement pour ventiler puis plus rien pendant des heures
au final :
le G5 est plus silencieux que les derniers powermac G4 .
plus silencieux que les derniers PC HP que j'ai pu cotoyer par exemple.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Anonyme . Évalué à 1.
Mais ça ne garanti rien. Tout comme une voiture est silencieuse sortie du garage, un ordi neuf est silencieux. Mon PIV à presque 1 ans et son volume sonore commence à se faire sentir, alors qu'il était tout à fait silencieux neuf.
Quand aux fait que les ventilos s'arrêtent par moment, en sachant que les portables Thinkpad d'IBM d'il y a 3/4 ans savent faire cela, j'imagine que c'est plutot fréquent de nos jours.
[^] # Re: X86 contre PPC : Un article fait le point
Posté par Anonyme . Évalué à 1.
> était tout à fait silencieux neuf.
Solution : rajouter de l'huile (pour chaîne de vélo par exemple) dans les ventilateurs, et retour à la case départ pour le bruit.
> Quand aux fait que les ventilos s'arrêtent par moment, en sachant que les portables
> Thinkpad d'IBM d'il y a 3/4 ans savent faire cela,
J'ai même un copain qui a un portable équipé d'un celeron 333 qui le fait.
Aurélien.
# Re: X86 contre PPC : Un article fait le point
Posté par NebuchadnezzaR . Évalué à 2.
http://h18002.www1.hp.com/alphaserver/(...)
[^] # Re: X86 contre PPC : Un article fait le point
Posté par NebuchadnezzaR . Évalué à 1.
hé hé ;-)
[^] # Trop chaud, trop gourmant
Posté par Dalton joe . Évalué à 1.
Crusoe c'est mieux.
http://www.transmeta.com/technology/advantages/cooler.html(...)
# Re: X86 contre PPC : Un article fait le point
Posté par Anonyme . Évalué à 0.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.