Articles précédents : Articles
- [19] PostgreSQLFr (l'association et le site .org) cherche graphiste...
- [23] Sortie d'Authentic 0.5
- [45] Définition du processus de rédaction de la GPL version 3
- [200] Pilotes binaires dans Linux: quel est le problème ?
- [18] Création de la fondation MapServer
- [33] Support des chipsets bcm-43xx
- [62] Dépêche numéro 20 000
- [137] Pétition EUCD.info « Non au projet de loi DADVSI ! »
- [22] Firefox et DADVSI dans Le Monde
- [47] Les Européens de l'année sont...
Liens connexes
- Opensparc (1287 hits)
- Solaris et la CDDL (346 hits)
- GNUsolaris (601 hits)
- Libérations de brevets par SUN (345 hits)
- Le weblog de Gilles Gravier (634 hits)
Dépêche modérée par
Dépêche éditée par
Articles : SUN libère ses processeurs SPARC
Posté par CyrrusSmith (page perso, ). Modéré le 13 décembre 2005.SUN s'oriente de plus en plus vers le service, la vente de support, autour de ses plateformes de logiciels et matériels.
Après avoir libéré Solaris (il existe même un OS GNU/Solaris, GNU avec un noyau Solaris), SUN a annoncé le 6 décembre 2005 la création de OpenSPARC, c'est à dire la mise en open-source du c½ur de leur plateforme hardware.
Chacun pourra, s'il en a les moyens, produire des processeurs "compatibles SPARC".
Étant données les performances de ce matériel, les ordinateurs "compatibles SPARC" pourraient connaître un succès comparable aux x86. Les cartes graphiques spécifiques SUN sont particulièrement remarquables. Leurs pilotes sont naturellement libres (d'autres machines SUN utilisent du nvidia).
GNU/Linux tourne déjà sur les machines SUN, que ce soit celles équipées de processeurs AMD ou de processeurs SPARC.
Opensparc (1287 hits)
Solaris et la CDDL (346 hits)
GNUsolaris (601 hits)
Libérations de brevets par SUN (345 hits)
Le weblog de Gilles Gravier (634 hits)
> Lire la suite (113 commentaires, moyenne: 3,2). [dépêche : 1585 caractères]
En fait d'après un de ses responsables, Gilles Gravier: « Sun part du principe que le logiciel peut être libre et gratuit ».
En libérant ses produits, logiciels et matériels, SUN espère augmenter le nombre de ses clients, qui pourront ainsi adapter les produits SUN à leurs besoins, et vendre plus de support sur des systèmes qu'ils connaissent bien.
SUN a aussi la capacité de résoudre plus facilement des problèmes sur leur architecture, comme de créer un module spécifique du noyau, etc.
SUN espère aussi naturellement une augmentation des contributions, rapports de bugs, etc...
C'est dans ce cadre que SUN a signé la pétition contre la loi DADVSI. Il s'agit explicitement de soutenir le libre par cet acte.
Actuellement il n'y a pas de DRM sur les machines SUN.
(J'ai posé 3 fois la question formulée différemment ! Ils sont patients...)
Il n'est pas prévu d'en mettre dans l'immédiat. Peut être seront elles utilisées un jour dans le cadre de la diffusion de documents, pour s'assurer que le destinataire est bien le bon.
Dans ce cas ces fonctions DRM seront vraisemblablement désactivables/activables selon le choix de l'utilisateur ou du propriétaire de l'ordinateur.
Solaris est sous Licence CDDL, inspirée de la licence de Mozilla. Cette licence sera étendue à d'autres logiciels SUN. Elle remplacera les autres licences libres ou apparentées pour simplifier leur gestion.
Les spécifications pour le port de systèmes libres comme GNU/Linux ou NetBSd sur Machines SUN sont naturellement disponibles.
C'est bien mais..
Moi personnellement ce que j'attend le plus c'est une carte graphique aux spécifications libre. Pour cela il y a le projet open graphics[1], donc j'attend...
Enfin saluons tout de même cette belle action de sun. Moi j'ai juste envie de dire merci :)
1. http://lists.duskglow.com/mailman/listinfo/open-graphics
-
[^]Re: C'est bien mais..
Posté par nayco (page perso, ) le 13/12/2005 à 14:37. (lien). Évalué à 3.Faut-t-il créer la FHF(*) ? On y nommerait comme président Richard Halman, et on pourrait enfin faire du DRM que l'on saurait comment il fonctionne. On pourrait même l'adapter à ses propres besoins !
Bien sûr, les grincheux vont être obligés de préciser que la jouissance d'un bien matériel est à tendance exclusive, et que les coût de reproductions ne sont pas nuls, de se lancer dans explications. Et bien, je l'ai fait exprès, voilà !
Accessoirement, une carte 3D libre, ouais, je suis preneur, mais alors pas à 450euros, hein...
(*) Free Hardware Fondation
Quelques journaux pour commencer...
Pour mémoire, vous pouvez utilement consulter les deux journaux :
http://linuxfr.org/~jahrynx/20188.html (journal de deuxième page)
https://linuxfr.org/~Jeanuel/20206.html (journal de première page)
-
[+] [^]Re: Quelques journaux pour commencer...
Posté par GhZaaark3 () le 14/12/2005 à 14:58. (lien). Évalué à -1.petit hs:
Les rédacteurs pourraient revoir leur formulation toutes faites:
Sun "libère" ses processeurs SPARC.
Pourquoi? étaient-ils prisonniers de leur créateur.
Je préfère plutôt la formulation:
SUN partage, dévoile, offre...
Je trouve que "libèrer" dans ce sens - car evidement il y a différent degré - a toujours une conotation un peu négative. Ils n'ont pas l'obligation de fournir leur travail.
Tout comme ceux qui critiquent que Open Solaris ne soit en fait qu'une partie du Solaris commercial.
Ils ont tout d'même offert des trucs non négligeables: OpenSolaris, ZFS, Oo, specs Java etc, etc, etc...
C'est du marketing, oké, mais c'est déjà moins béliqueux.
Excusez Sun d'avoir quand même jenvie de gagner un tant soit peu leur vie avec ce qu'ils créent.
En résumé, utilisons des termes moins ambigües.--
moué...
Assez gros...
Étant données les performances de ce matériel, les ordinateurs "compatibles SPARC" pourraient connaître un succès comparable aux x86
On a dit la meme chose pour les PPC... Le succès de l'architecture x86 repose essentiellement sur sa large base d'utilisateurs, et beaucoup moins sur ses qualités techniques propres. Qu'en sera t-il des SPARC ? Je pense que ca peut être une architecture exotique de plus, bien sûr le fait qu'elle soit maintenant libre est intéressant, mais est ce que ce sera suffisant pour la faire (re)vivre...
Ce qui me gêne moi, dans l'attitude de SUN par rapport au libre, c'est qu'ils semblent ne libérer que des produits en fin de vie. Ils croient au libre comme on croit en sa roue de secours. Je prends pour exemple java, sans aucun doute LE produit de chez sun qui bénéficierait d'une libération !
#define MAGIC 0xdefaced /* I should've patented this number -cliph */
-
[^]Re: Assez gros...
Posté par Zanton (page perso, ) le 13/12/2005 à 12:44. (lien). Évalué à 2.Question de "newbe" : en quoi Java n'est pas libre ? On peut faire des machines virtuelles libres il me semble, gcj par exemple et tout le monde peut utiliser Java. Que faut-il pour qu'un langage de programmation, voire plus que ça dans le cas de Java avec ses jvm, soit libre ?
-
[^]Re: Assez gros...
Posté par Cali_Mero () le 13/12/2005 à 12:50. (lien). Évalué à 4.Eh bien, que les sources de la VM officielle soient distribuées serait déjà un bon début... non ?
--
#define MAGIC 0xdefaced /* I should've patented this number -cliph */-
[^]Re: Assez gros...
Posté par Zanton (page perso, ) le 13/12/2005 à 14:42. (lien). Évalué à 2.Oui mais si on utilise une jvm libre type gcj, ne peut-on pas dire qu'on fait du "java libre" ?
-
[^]Re: Assez gros...
Posté par yoho (page perso, ) le 13/12/2005 à 16:51. (lien). Évalué à 2.On ne peut pas reproduire les comportements de la JVM de Sun dans ses moindres détails si elle n'est pas ouverte. Par exemple, elle comprend des bugs bien connus des programmateurs Java qui font des "workaround" ou qui tirent parti de ces bugs (volontairement ou non) -> du coup, ces programmes ne sont pas portables sur gcj, la JVM de IBM, ou autre...
Je ne sais pas si les specs de Java sont publiques par contre (attention, j'ai bien dit Java, pas J2EE ou autre...).-
[^]Re: Assez gros...
Posté par Sylvain Sauvage () le 14/12/2005 à 07:40. (lien). Évalué à 7.Porten'imwak !
http://java.sun.com/docs/books/vmspec/
http://java.sun.com/docs/books/jls/index.html
Disponibles depuis le début (= très, très longtemps).-
[^]Re: Assez gros...
Posté par yoho (page perso, ) le 14/12/2005 à 15:56. (lien). Évalué à 2.Ce sont les specs... (il me semblait bien qu'elles étaient ouvertes, mais je n'en était pas sûr). Ca ne change rien que le code n'est pas ouvert et qu'on ne peut donc pas reproduire la jvm dans ses moindres détails : les specs laissent toujours des flous.
-
-
-
[^]Re: Assez gros...
Posté par Mark Havel () le 13/12/2005 à 17:05. (lien). Évalué à 6.Libre, mais loin d'être à jour...
-
[^]Re: Assez gros...
Posté par pvincent () le 14/12/2005 à 16:03. (lien). Évalué à 1.En effet, la version 1.5 de Java n'est pas encore disponible à ma connaissance sous une forme libre. Et c'est bien dommage :-(
En plus, la blackdown Java qui un temps suivait quand même les specs d'assez près a été engloutie je ne sais comment par la version de Sun. Et depuis ma-cash, on est fortémment dépendant de la JVM officielle Sun.
Au final, installer la dernière version de Java sur une distro libre c'est franchement galère (ubuntu, debian, gentoo, ...) si ce n'est impossible car binaire oblige la version pour des architectures alternatives genre PPC ou SPARC ne sont pas disponibles.-
[^]Re: Assez gros...
Posté par boubou (page perso, ) le 14/12/2005 à 16:16. (lien). Évalué à 2.La version de blackdown étant produite à partir du code de Sun, elle n'est pas plus libre que celle de Sun.
Le support de 1.5 par GCJ et Classpath avance très bien, ceci dit.
-
[^]Re: Assez gros...
Posté par nicodache () le 14/12/2005 à 16:57. (lien). Évalué à 5.sous debian, ya un truc qui s'appelle make-jpkg, et qui permet de faire un .deb à installer via pdkg -i très simplement...
genre suffit de faire make-jpkg jre-machin.bin, d'appuyer une fois sur F8, et puis de taper quelques fois sur enter.
(pour gentoo, et autres, chépo)
concernant Java sur Sparc, il est également disponible en .bin, mais uniquement pour solaris.
et je suppose que la version linux ne marche pas sur sparc, bien qu'aucune archi matérielle ne soit spécifée sur le site concernant la version linux
-
-
-
-
-
[^]Re: Assez gros...
Posté par FredCL (page perso, ) le 13/12/2005 à 12:52. (lien). Évalué à 2.Que faut-il pour qu'un langage de programmation, voire plus que ça dans le cas de Java avec ses jvm, soit libre ?
Que SUN fournisse le code du JRE!-
[^]Re: Assez gros...
Posté par stef () le 13/12/2005 à 16:33. (lien). Évalué à 2.La raison n'est pas là.
Sun a d'ailleurs déjà rendu public son code source (à l'époque, c'était java 1.1.6, je crois) sans que java ne soit libre. C'était assez fouillis d'ailleurs, et les specs de la JVM (heureusement disponibles) sont bien plus utiles que le code source de Sun.
Les raisons pour lesquelles java n'est pas libre ont été exposées dans LMF il n'y a pas longtemps.
-
-
[^]Re: Assez gros...
Posté par boubou (page perso, ) le 13/12/2005 à 13:08. (lien). Évalué à 9.Si tu as le temps, tu peux lire mon "gros" article à ce sujet. Il est un peu vieux (un an), mais il reste d'actualité : http://apiacoa.org/publications/vulgarisation.html#lm-java-d(...)
-
[^]Re: Question de "newbe"
Posté par Julien () le 13/12/2005 à 14:36. (lien). Évalué à 6.Un article était passé dans GNU Linux Magazine France à ce sujet.
Ce qu'il m'en reste est que Sun a posé trois conditions pour obtenir le droit de développer une machine virtuelle. Aucune n'interdit de faire une machine virtuelle libre.
C'est par contre quasiment impossible. En effet, une de ces conditions interdit de fournir une machine virtuelle qui n'est pas 100% compatible aux normes de SUN. Il faut donc finir le produit avant de le distribuer, ce qui est très compliqué
En espérant ne pas avoir trop déformé le fameux article.-
[^]Re: Question de "newbe"
Posté par patrick_g (page perso, ) le 13/12/2005 à 15:51. (lien). Évalué à 1.>> En espérant ne pas avoir trop déformé le fameux article.
ben le fameux article boubou vient de poster le lien juste au dessus de ton message.
-
[^]Re: Question de "newbe"
Posté par Yannick (page perso, ) le 14/12/2005 à 11:02. (lien). Évalué à 2.C'est par contre quasiment impossible. En effet, une de ces conditions interdit de fournir une machine virtuelle qui n'est pas 100% compatible aux normes de SUN. Il faut donc finir le produit avant de le distribuer, ce qui est très compliqué
En fait, je crois que dans la plupart des cas, ils se foutent de la condition sur les API (surtout pour une implementation libre), il veulent juste éviter qu'on leur refasse le sale coup de microsoft : Faire une API qui n'a rien a voir avec l'officiel, et s'arranger pour qu'elle devienne un standard. Ou éviter d'avoir un bordel d'APIs de base qui arrivent de partout.
-
-
-
[^]Re: Assez gros...
Posté par Jeanuel (Jabber id, page perso, ) le 13/12/2005 à 12:56. (lien). Évalué à 3.Ce qui est certain, c'est que les produits moribonds libérés font les beaux jours de la communauté et sont parfois des produits phares. Deux des meilleurs exemples sont quand même firefox/thunderbird (petit, petit, petit fils de netscape) et OOo (petit fils de star office).
Qu'importe la raison, pourvu que l'code reste...-
[^]Re: Assez gros...
Posté par Antoine () le 13/12/2005 à 13:03. (lien). Évalué à 5.Deux des meilleurs exemples sont quand même firefox/thunderbird (petit, petit, petit fils de netscape)
L'ensemble de Mozilla est une réécriture from scratch, le code libéré par Netscape ayant été considéré comme irrécupérable avec quelques mois d'essais.
Lire les écrits passionnants de Jamie Zawinsky à ce sujet :
http://www.jwz.org/gruntle/nomo.html-
[^]Re: Assez gros...
Posté par Jeanuel (Jabber id, page perso, ) le 13/12/2005 à 15:25. (lien). Évalué à 2.Tout le code à été réécrit, soit. Mais il n'en reste pas moins que sans netscape, pas de mozilla. L'application à servi de cataliseur, ce qui n'est pas la moindre des choses.
-
[^]Re: Assez gros...
Posté par Antoine () le 13/12/2005 à 15:37. (lien). Évalué à 7.Ce n'est pas l'application qui a servi de catalyseur, ce sont les ressources fournies et la communauté impulsée par Netscape. Simplement libérer du code ne sert en soi pas à grand'chose.
Un article que j'ai écrit à ce sujet : http://www.libroscope.org/Liberer-les-logiciels-
[^]Re: Assez gros...
Posté par Jeanuel (Jabber id, page perso, ) le 13/12/2005 à 16:55. (lien). Évalué à 3.article très intéressant, qui corrobore complètement le point de vue selon lequel, même avec une réécriture complète, mozilla est bien le descendant de feu netscape.
Nous somme d'accord.
-
-
-
[+] [^]Re: Assez gros...
Posté par grmbl (page perso, ) le 13/12/2005 à 16:14. (lien). Évalué à -3.>L'ensemble de Mozilla est une réécriture from scratch
Ils ont réécrit Gecko "frome scratche" ?
Ah bin ça alors !
-
-
-
[^]Re: Assez gros...
Posté par vosgien_ () le 13/12/2005 à 15:49. (lien). Évalué à 10.Ce qui me gêne moi, dans l'attitude de SUN par rapport au libre, c'est qu'ils semblent ne libérer que des produits en fin de vie.
L'architecture liberée par sun concerne les nouveaux processeurs UltraSparc T1 : nom de code Niagara (sun4v) dont les premiers exemplaires seront disponibles début 2006 dant les modèles SunFire T1000 et T2000. Ce ne sont PAS les produits en fin de vie.
Pour info ces modèles sont des 4/6/8 cores dont chacun des cores, comme tout processeur risc peut faire tourner 4 threads.
Ce qui fait jusque 32 threads dans un seul processeur !
confusion...
Depêche approximative et fantaisiste sur beaucoup de points.
Chacun pourra, s'il en a les moyens, produire des processeurs "compatibles SPARC".
Cela fait longtemps que c'est le cas. Ainsi le processeur LEON est un processeur compatible SPARC dont les sources sont livrés sous licence libre.
cf. http://www.gaisler.com/cms4_5_3/index.php?option=com_content(...)
Ce qui est nouveau, c'est que Sun va fournir le code source de certains de ses propres processeurs, dont le processeur Niagara qui vient juste de sortir.
Étant données les performances de ce matériel, les ordinateurs "compatibles SPARC" pourraient connaître un succès comparable aux x86.
Là ça devient n'importe quoi. Une telle possibilité existe depuis des années, elle ne s'est toujours pas matérialisée... La compatibilité binaire, notamment, est un point critique.
Chacun pourra, s'il en a les moyens, produire des processeurs "compatibles SPARC".
Oui, s'il en a les moyens... Or, produire à bon marché des processeurs performants demande de très gros investissements. Surtout s'il s'agit d'être compétitif sur le marché grand public (Intel dépense des milliards en R&D chaque année).
Les cartes graphiques spécifiques SUN sont particulièrement remarquables.
On ne voit pas trop le rapport avec le choix d'un processeur, puisque la connexion de la carte graphique avec le reste du système passe par des bus graphiques aujourd'hui standardisés (AGP, PCI Express).
-
[^]Re: confusion...
Posté par ccomb (Jabber id, page perso, ) le 13/12/2005 à 14:31. (lien). Évalué à 4.oh le lourd, juste au moment où on commence à rêver d'un monde meilleur, tu casses tous nos espoirs...
-
[^]Re: confusion...
Posté par nicodache () le 13/12/2005 à 15:06. (lien). Évalué à 7.effectivement, il est méchant ;)
tu noteras cependant que Intel, malgré ses milliards en R&D tous les ans, nous a pondu une grosse bouse nommée NetBurst (aka P4), au point qu'ils sont en train de faire machine arrière pour suivre les ingénieurs du petit AMD.
si même le numéro un des processeurs arrive à cafouiller comme ca, je me dis que quelques gens bien formés et informés sont à même de faire quelque chose d'intéressant du Sparc, quitte à ne jamais faire voir le jour à leur puce, coût de fabrication oblige ;)-
[^]Re: confusion...
Posté par boubou (page perso, ) le 13/12/2005 à 16:02. (lien). Évalué à 5.Oui, enfin, grosse bouse, il ne faudrait tout de même pas exagérer. La grosse bouse en question propose un hyperthreadnig fort agréable en pratique. Elle a certe de nombreux défauts (consommation éléctrique délirante et ratio performances/fréquence assez faible), mais de la à dire que c'est de la merde... Par contre, c'est une voix sans issue, d'où le retour d'IBM vers l'architecture des PIII par l'intermédiaire du pentium M et de ces successeurs. Il est vrai que les PIII ressemblent aux AMD (pipeline court), mais encore une fois, dire qu'Intel suit AMD, c'est encore un peu exagéré...
-
[^]Re: confusion...
Posté par nicodache () le 13/12/2005 à 16:20. (lien). Évalué à 3.Ca n'est pourtant pas Intel qui a introduit le 64 bits (qui ne sert à rien), ni le dual core, ni le controleur ram intégré, dans les processeurs grands publics x86 (je ne parle pas des G5 ni des Power IBM hein ;))
M'enfin, j'avoue que j'aime bien troller hardware, et que je suis légèrement plus attiré par AMD que par Intel ;)
Quant à l'hyperthreading, il est désactivé dans de nombreux serveurs, pour des questions de sécu (un pseudo proc peut espionner l'autre), et aussi parce que l'overhead nécessaire pour émuler les deux proc est supérieur au bénéfice qu'on peut en tirer dans de nombreux environnements...
Mais j'avoue que sur une station de travail, ca doit etre sympa.
J'ai jamais testé par contre :D-
[^]Re: confusion...
Posté par boubou (page perso, ) le 13/12/2005 à 18:32. (lien). Évalué à 3.Le 64 bits grand public a en effet été introduit par AMD, mais le 64 bits existait bien avant ça (processeurs alpha, Itanium d'Intel, etc.). Le dual core est un argument marketing (très joli, il est vrai) mais en aucun cas une véritable innovation technique. Quand le cache sera partagé entre les cores, on en reparlera, pour l'instant c'est simplement du bi-processeur un peu plus facile à mettre en oeuvre qu'avant (j'ai eu un bi-pro intel (P III) et un bi-pro AMD, j'espère qu'AMD a fait des progres depuis...). Le contrôleur RAM intégré est un vaste débat. Est-ce vraiment utile, difficile à dire puisqu'on ne peut pas comparer deux solutions strictement équivalentes exceptées le contrôleur, donc pas de conclusion.
Dans l'autre sens, seul Intel est capable de fournir une vraie plateforme basse consommation avec son Centrino. Le Turion consomme assez peu (un peu plus que le pentium M), mais les chipsets ne suivent pas ce qui fait qu'un portable Turion a une autonomie beaucoup plus faible qu'un portable Pentium M à fonctionnalités comparables.
Bref.-
[^]Re: confusion...
Posté par Vincent Pelletier () le 13/12/2005 à 21:22. (lien). Évalué à 5.> mais le 64 bits existait bien avant ça
Par exemple... SPARCv9 qui date de 1995 et qui est à l'origine des processeurs UltraSPARC de Sun (64 bits bien entendu).-
[^]Re: confusion...
Posté par Serge Julien () le 14/12/2005 à 09:04. (lien). Évalué à 9.Ou DEC Alpha, dès 1992 : des processeurs incroyablement innovants (64bits et RISC) dont on ne peut que regretter la disparition.
-
[^]Re: confusion...
Posté par Jul (page perso, ) le 14/12/2005 à 14:12. (lien). Évalué à 2.non, ils n'ont pas totalement disparu. J'en ai récupéré (une DEC 500 une UE2) : les 64bits font des chauffages électriques combinés avec des serveurs de pages web/mysql honorables. Le soucis c'est que c'est comme tous les gadgets qui sont sensés faire deux choses à la fois, ça en fait aucune des deux bien.
D'ailleurs, je sais pas si c'est debian ou les archi 64 bits, mais à fréquence égale elles se font latter par un céléron en temps de première réponse. Depuis, j'ai arrêté de fantasmer sur les vieux clous.-
[^]Re: confusion...
Posté par Antoine () le 14/12/2005 à 20:50. (lien). Évalué à 2.D'ailleurs, je sais pas si c'est debian ou les archi 64 bits, mais à fréquence égale elles se font latter par un céléron en temps de première réponse.
Ca doit être gcc qui ne doit pas super optimiser le code sur ces architectures...
Sans compter que le code 64 bits peut être plus lent que le code 32 bits (les pointeurs étant plus gros, les structures de données augmentent en taille, et donc le cache et la mémoire sont plus sollicités).-
[^]Re: confusion...
Posté par reno () le 16/12/2005 à 21:28. (lien). Évalué à 2.Ca et puis les Alpha étaient pendant une période des 'speed daemon' à la P4: ils ne faisaient pas grand chose par cycle, mais ils montaient en fréquence beaucoup plus haut que leur concurrents (qu'ils torchaient d'ailleurs surtout en FP), d'ou d'ailleurs des conso importantes (dans mon école on avait un proto d'Alpha: la pièce qui l'hébergeait était plus chaude que les autres..).
Donc à fréquence égale un CPU peut torcher un Alpha de cette période.
Et puis il faut voir le reste du systeme: Digical a essayé de pousser un AlphaPC a un moment, pour réduire les prix réduction de la taille des caches, du sous-système mémoire, etc.
Même un bon CPU a du mal a lutter avec une mémoire inférieure..
-
-
-
-
-
[^]Re: confusion...
Posté par ragoutoutou () le 14/12/2005 à 10:25. (lien). Évalué à 8.Le dual core est un argument marketing (très joli, il est vrai) mais en aucun cas une véritable innovation technique.
Euh, là c'est idiot ce que tu dis. Le dual core a un réel avantage car il permet de mettre deux vrais processeurs dans un, ce qui permet d'avoir un coût infrastructure par processeur bien plus bas pour les workstations et pour les serveurs. Aucune comparaison possible avec des astuces de dernier espoir comme l'hyperthreading.
C'est particulièrement intéressant dans le cas où tu bosses avec des serveurs compactes de type blade où il devient très simple d'avoir un quadri-proc sans augmenter la taille des machines.
Je ne sais pas si tu as déjà vu beaucoup de systèmes 8 processeurs mono-core, mais crois moi sur parole que du dual core sur une carte mère 4 sockets est une solution bien plus élégante.
Pour l'affaire du contrôleur de ram intégré, c'est vrai qu'il y a débat car celà réduit les possibilités de changer le type de ram.
Par contre, en multi proc, le contrôleur intégré permet d'avoir une configuration mémoire NUMA avec une augmentation de la bande passante totale simultannée avec la ram proportionnelle au nombre de processeurs, ce qui est bien plus intéressant que les xeons préhistoriques qui en sont encore à partager un bus de mono-processeur entre plusieurs processeurs pour accéder à la ram.
Quand le cache sera partagé entre les cores, on en reparlera
Une cache unifiée entre les deux cores nécessiterait soit de mettre un contrôle transactionnel multiclient sur l'allocation, la désallocation et l'accès à la cache, soit de limiter les accès à un seul processeur à la fois. Dans le premier cas, ça coûterait plus cher, dans le second, ça réduirait sérieusement les performances.
La solution de la cache séparée assortie d'une interconnexion directement à la sortie de la cache est en revanche une solution très efficace, et c'est ce qui est utilisé chez amd.
Pour le reste, je te recommande vivement de lire des tests et benchmarks plutôt que de donner dans les croyances populaires.-
[^]Re: confusion...... disgression & précision sur le NUMA
Posté par EraZerg () le 14/12/2005 à 13:39. (lien). Évalué à 8.Juste une petite remarque en passant par rapport au NUMA, je fait référence à ta phrase (tu vas dire que je coupe les pattes de mouche en quatre, mais bon):
<<Par contre, en multi proc, le contrôleur intégré permet d'avoir une configuration mémoire NUMA avec une augmentation de la bande passante totale simultannée avec la ram proportionnelle au nombre de processeurs, ce qui est bien plus intéressant que les xeons préhistoriques qui en sont encore à partager un bus de mono-processeur entre plusieurs processeurs pour accéder à la ram.>>
Cela fait plusieurs fois que je vois ça dans la presse et dans les têtes des gens et j'ai l'impression que tout le monde pense que le NUMA c'est le rêve absolu... etc .. etc.
Le NUMA (Non Uniform Memory Architecture, man wikipedia pour plus d'info) c'est un MOYEN de contournement (workaround) d'un problème industriel/physique: Effectivement,aujourd'hui, on ne sait pas fabriquer des machines avec beaucoup de processeurs et beaucoup de mémoire (et ceci de manière performante) sans casser la __magnifique__ symétrie des architectures SMP. Augmenter la performance nécessite de casser la symétrie des système. le NUMA c'est le moyen le moins pourave qu'on a trouvé pour que cela ressemble encore un peu à une machine performante.
Maintenant, il suffit de regarder un peu la complexité pas possible qu'induit l'architecture NUMA (hardware, mais aussi OS) pour se rendre compte que le rêve ce serait une bonne perfo sur une architecture symétrique.
Comme tout n'est jamais complètement négatif, je dirais pour terminer que le NUMA c'est un super moyen de sauvegarder nos emplois d'ingénieurs en info, une machine NUMA c'est toujours le bordel au niveau perf. Et dire que bientôt j'aurai (enfin je veux dire on aura tous) une machine NUMA à la maison....
Le plus drôle c'est que :
- avec l'hyperthreading c'était le bordel.
- Avec le NUMA c'est le MEGA bordel.
Alors en dessert, vous reprendrez bien les deux mélangés ? hein ? (cf Montecito sur des machines cellulaires par ex) je sais pas si il y aura 10 personnes sur la planête capables de tirer la quintessence (en perf) de l'architecture.
conclusion: NUMA, CACA, mais on fait pas mieux pour le moment.-
[^]Re: confusion...... disgression & précision sur le NUMA
Posté par ragoutoutou () le 14/12/2005 à 14:00. (lien). Évalué à 5.C'est vrai que question gestion, le Numa n'est pas des plus aisé (enfin bon, on te demande généralement pas non-plus de migrer les processus à la main)...
Dans le cas l'amd64, on travaille en mode hybride SUMO (sufficiently uniform memory organization), ce qui permet si l'on est avec un OS stupide (comme windows), de travailler comme si on était en bête SMP (avec tout de même un système d'interconnexion très performant comparativement à ce qu'on a chez Intel), et si l'on est avec un os plus évolué, de travailler avec un kernel optimisé capable de gérer les affinités entre les processus et les processeurs.
Avantage du SUMO ?
- La migration de processus peut se faire de manière transparente (alors que dans une config NUMA standard, la migration nécessite plus de préparation pour envoyer un processus sur un autre processeur)
- les échanges entre processus situés sur des processus différents se font aussi de manière transparente, le partage de mémoire peut se faire exactement comme pour du smp.
Donc oui, le Numa, c'est pas évident, mais dans le cas de l'amd64, c'est tout de même beaucoup plus intéressant.
Sinon, je vois pas ce que le pauvre hyperthreading vient faire là dedans...-
[^]Re: confusion...... disgression & précision sur le NUMA
Posté par EraZerg () le 14/12/2005 à 14:50. (lien). Évalué à 4.J'ai pas bien capté le SUMO, je vais me documenter....C'est un truc d'AMD ou d'un constructeur en particulier ?
Par contre, sur toutes les plateformes NUMA que je connais, on peut configurer la RAM en mode interleaved ce qui permet d'avoir un comportement uniforme et évite de créer des "points chauds" dans les crossbar. Le top c'est lorsqu'on peut configurer une partie de la RAM de manière entrelacée et l'autre partie en NUMA pure, si tu ajoutes un kernel récent là dessus tu peux avoir des comportement géniaux du genre:
-pagecache --> interleaved node
-OpenMP shared data --> interleaved node
-process/MPI private data --> NUMA
.....
...
bref, l'extase de l'ingé, tu peux faire plein d'erreurs, tu passes plein d'heures à profiler.... .... Et l'humanité perd un temps fou.... mais nous qu'est-ce qu'on s'éclate !!!
J'en reviens à mes moutons: <<Quand tu dis OS stupide comme windows, je suis d'accord pour stupide en général (et hop une caresse au troll) mais il me semble qu'elle est NUMA aware(comme dirait jean-claude) c't'usine à gaz.... >>
<<Sinon, je vois pas ce que le pauvre hyperthreading vient faire là dedans...>>
moi non plus :-) Ah si ! c'était à propos de la sauvegarde de nos emplois avec des technologies qu'on pousse en avant comme étant des réelles innovations (Hyperthreading, NUMA, multicore) alors qu'en fait ça devrait plutôt être profil bas, on sait pas mieux faire..... :-)))) Du coup j'ai rajouté le multi-core dans le tas.... :-)
-
[^]Re: confusion...... disgression & précision sur le NUMA
Posté par ragoutoutou () le 14/12/2005 à 15:31. (lien). Évalué à 3.
C'est un truc d'AMD ou d'un constructeur en particulier ?
Je crois que c'est du pur amd, une solution indispensable pour garder une compatibilité parfaite pour les systèmes x86.
bref, l'extase de l'ingé, tu peux faire plein d'erreurs, tu passes plein d'heures à profiler.... .... Et l'humanité perd un temps fou.... mais nous qu'est-ce qu'on s'éclate !!!
Yesss... au fait, tu bosses sur quelle architecture?
-
-
-
-
[^]Re: confusion...
Posté par boubou (page perso, ) le 14/12/2005 à 14:45. (lien). Évalué à 3.Euh, là c'est idiot ce que tu dis.
Si tu apprenais à lire, ça te semblerait moins idiot et ça t'éviterait de répondre à côté de la plaque.
Le dual core a un réel avantage car il permet de mettre deux vrais processeurs dans un, ce qui permet d'avoir un coût infrastructure par processeur bien plus bas pour les workstations et pour les serveurs.
Oui, c'est ce que j'ai dit, c'est un argument marketing, du multi-processeur plus facile à mettre en oeuvre.
Aucune comparaison possible avec des astuces de dernier espoir comme l'hyperthreading.
En effet et alors ? J'ai dit que ça avait un rapport ?
Par contre, en multi proc, le contrôleur intégré permet d'avoir une configuration mémoire NUMA avec une augmentation de la bande passante totale simultannée avec la ram proportionnelle au nombre de processeurs, ce qui est bien plus intéressant que les xeons préhistoriques qui en sont encore à partager un bus de mono-processeur entre plusieurs processeurs pour accéder à la ram.
Tu confonds la gestion de la communication entre les processeurs et avec le chipset (contrôleur mémoire inclus), et l'intégration de cette gestion dans le processeur. AMD a depuis des années des choses intéressantes pour la communication du processeur avec l'extérieur (hyper transport et compagnie), avant ce n'était pas intégré au processeur, c'est tout.
Une cache unifiée entre les deux cores nécessiterait soit de mettre un contrôle transactionnel multiclient sur l'allocation, la désallocation et l'accès à la cache, soit de limiter les accès à un seul processeur à la fois. Dans le premier cas, ça coûterait plus cher, dans le second, ça réduirait sérieusement les performances.
La solution de la cache séparée assortie d'une interconnexion directement à la sortie de la cache est en revanche une solution très efficace, et c'est ce qui est utilisé chez amd.
Il y a eu du cache partagé sur les machines SMP depuis très longtemps. Les futurs multi-core d'Intel et d'AMD prévoient d'intégrer du cache partagé. Nous verrons dans le futur si les ingénieurs des entreprises cités sont aussi nuls que tu le penses ou non.
Pour le reste, je te recommande vivement de lire des tests et benchmarks plutôt que de donner dans les croyances populaires.
De quoi parles-tu ?-
[^]Re: confusion...
Posté par ragoutoutou () le 14/12/2005 à 15:27. (lien). Évalué à 5.Oui, c'est ce que j'ai dit, c'est un argument marketing, du multi-processeur plus facile à mettre en oeuvre.
Je dirais que c'est surtout un argument technique. L'intéret n'est pas juste de mettre un bel autocollant "dual core" sur son boîtier, mais de mettre un maximum de processeurs dans un minimum de place, et si possible en évitant un maximum les complications.
Tu confonds la gestion de la communication entre les processeurs et avec le chipset (contrôleur mémoire inclus), et l'intégration de cette gestion dans le processeur.
Je pense que c'est toi qui confond...
L'intégration du contrôleur de mémoire dans le processeur permet d'avoir autant de fois la bande passante proc<->mémoire que de socket occupé. Dans le cas de l'AMD64, l'hypertransport est utilisé pour communiquer avec le chipset et les autres processeurs, mais chaque processeur peut dialoguer directement avec sa propre ram sans passer par le bus, d'où un gain énorme d'efficacité dans les communications (on est à presque 95% de la bande passante théorique de 6,4Gb/sec alors qu'en passant par un contrôleur externe éventuellement partagé, on tombe sous les 70%)
Dans le cas d'une machines bi-Xeon ou bi-athlon xp, les deux processeur passent par le même northbridge pour atteindre la ram, ce qui rajoute des problèmes de collisions et de partage.
Il y a eu du cache partagé sur les machines SMP depuis très longtemps.
Dans quel film tu as vu ça?
Comment veux-tu avoir de la cache vraiment partagée et accédée sans intermédiaire entre deux processeurs physiquement distincts?
Sur du smp classique (xeon/athlon mp) avec deux processeurs physiquement séparés, les caches ne peuvent communiquer qu'en passant par le bus, ce qui correspond presque avec la méthode d'interconnexion utilisée pour l'amd64 x2 sauf que l'amd64 x2 a l'interconnexion directement en sortie du processeur au lieu de faire un détour par le bus.
Les futurs multi-core d'Intel et d'AMD prévoient d'intégrer du cache partagé.
C'est fort possible, il ne faut jamais dire jamais, mais le problème de sécurité du P4 HT a soulevé pas mal de questions au sujet de la cache partagée, et sans réponses valable à ce sujet, il serait risqué de la part de l'un ou de l'autre de lancer un processeur multi-core à cache partagée.-
[^]Re: confusion...
Posté par Nicolas Boulay () le 14/12/2005 à 16:48. (lien). Évalué à 4.AMD lit dans le cache L2 de l'autre processeur depuis l'athlon MP. C'était plus rapide d'aller lire dans le cache que dans la rame.
Depuis, c'est ce qui rends les processeurs opteron multicore largement supérieur à la techno Intel. chez intel, il s'agit juste de 2 processeurs sur la même puce. Contrairement à AMD, ou les caches sont partagé.-
[^]Re: confusion...
Posté par ragoutoutou () le 14/12/2005 à 17:06. (lien). Évalué à 3.AMD lit dans le cache L2 de l'autre processeur depuis l'athlon MP. C'était plus rapide d'aller lire dans le cache que dans la rame.
ah, ça c'est sûr que lire dans la cache plutôt que dans la ram, c'est un gain (même si ça passe par le bus), mais notre ami boubou faisait le reproche suivant aux dual cores "Quand le cache sera partagé entre les cores, on en reparlera" ...
Hors, une vrai cache partagée (donc un bloc unique de mémoire cache accessible de manière uniforme par deux cores), ça n'existe pas dans le monde x86, c'est compliqué, et surtout ça pose des problèmes de sécurité (l'hyperthreading l'a démontré sans qu'on ait besoin d'aller jouer avec deux vrais cores).
Dans les amd64, les caches communiquent via le crossbar qui se situe entre les caches, les trois cannaux hypertransport et les deux cannaux de contrôleur ram.
En aucun cas ce ne sont des caches partagées, elles communiquent, mais ce sont bien deux blocs distincts qui ne peuvent être accédés par le processeur en face au même titre que par leur processeur.-
[^]Re: confusion...
Posté par Nicolas Boulay () le 14/12/2005 à 18:59. (lien). Évalué à 2.Cela serait super con de faire un cache partagé. Cf le cache L3 des power 5.
Il suffit de gérer le cache au niveau du controleur mémoire.-
[^]Re: confusion...
Posté par nicodache () le 14/12/2005 à 20:18. (lien). Évalué à 2.tu pourrais expliquer le fonctionnement du cache L3 du G5 ?
tout le monde n'a pas ta connaissance des PPC ;)-
[^]Re: confusion...
Posté par Nicolas Boulay () le 14/12/2005 à 21:56. (lien). Évalué à 3.Un power 5 est bi core. Le L3 du machin est commun au 2 core.(128 Mo de eDRAM escusez du peu).
C'est finalement assez bète, au cas de demande pour aller lire la DRAM,il regarde d'abord le contenu du cache suplémantaire. Il n'y a pas plus de problème de cohérence que entre les L2 et la RAM.-
[^]Re: confusion...
Posté par nicodache () le 14/12/2005 à 23:14. (lien). Évalué à 1.l'avantage étant que la cache est sur la puce (donc à 10cm de moins), et que bien qu'elle ne tourne surement pas aussi vite que le proc (faut pas déconner non plus), elle tourne cependant plus vite que la ram du système.
c'est donc une sorte de ram avant la ram, juste ?
à quand les slots sodimm sur les proco IBM ? :D-
[^]Re: confusion...
-
[^]Re: confusion...
Posté par nicodache () le 15/12/2005 à 08:55. (lien). Évalué à 2.Bah vi
mais vu ta remarqueCela serait super con de faire un cache partagé. Cf le cache L3 des power 5.
, j'avais compris qu'il était légèrement mal optimisé, mal conçu, trop petit, trop lent, ou foireux, d'où ma demande d'explication ;-)-
[^]Re: confusion...
Posté par Nicolas Boulay () le 15/12/2005 à 09:01. (lien). Évalué à 2.oups, c'est vrai que la phrase est ambigue.
Je dis super con à faire, dans le sens super simple, pas dans le sens "débile".
-
-
-
-
-
-
-
-
-
-
-
-
-
[^]Re: confusion...
Posté par ragoutoutou () le 14/12/2005 à 10:32. (lien). Évalué à 1.un pseudo proc peut espionner l'autre
D'après ce que j'ai lu, il semble que le problème soit surtout que les réactions d'un pseudo proc permettent de mesurer dans certains cas le comportement de l'autre pseudo-proc et du même coup de déterminer la vitesse d'exécution d'opérations crypto, ce qui permet de faire des attaques basées sur les mesures des temps d'exécution pour faire un profile du cryptage.
Au boulot on a des serveurs de crypto à ultra basse latence, et sur ces machines, l'hyperthreading est impérativement désactivé sinon le temps de réaction du serveur devient trop instable, ce qui mène à des timeouts dans les transactions.-
[^]Re: confusion...
Posté par ragoutoutou () le 14/12/2005 à 11:11. (lien). Évalué à 4.Je viens de prendre le temps de lire le rapport de Colin Percival, en fait, grâce aux attaques de timing, il est carrément possible de deviner des données de la cache avec un taux d'erreur de 25% à 400k/s sur un P4 2,8ghz... Encore un bon argument pour ne pas avoir de partage de cache dans les dual-cores.
-
[^]Re: confusion...
Posté par Nicolas Boulay () le 14/12/2005 à 16:52. (lien). Évalué à 1.non, c'est pas un argument. Il suffirait de rajouter un brouilleur, cela ne doit pas être bien dure à mettre en place.
-
[^]Re: confusion...
Posté par nicodache () le 14/12/2005 à 17:00. (lien). Évalué à 2.Commencer à foutre des brouilleurs dans ce qui reste quand même le centre d'un ordi, ca fait cochon.
enfin, c'est mon avis quoi ;)-
[^]Re: confusion...
Posté par Nicolas Boulay () le 14/12/2005 à 18:43. (lien). Évalué à 2.Cela existe déjà pour les cpu de carte à puce, donc bon.
-
-
[^]Re: confusion...
Posté par ragoutoutou () le 14/12/2005 à 19:35. (lien). Évalué à 2.ben, je suis certain qu'un brouilleur, ça ferait fureur sur la cache L2 d'un processeur, l'étape suivante c'est de rajouter des sièges baquets et un frigo...
Sans rire, je sais pas ce que tu entend par "brouilleur", mais tout chipotage à ce niveau ne ferait que faire plonger les perfs du processeur... et ne dis pas que la carte à puce en a un, la carte à puce n'a ni la finalité ni la puissance d'un microprocesseur généraliste.-
[^]Re: confusion...
Posté par Nicolas Boulay () le 14/12/2005 à 21:59. (lien). Évalué à 2.Tu peux imaginer des tas de truc pour lisser l'execution : la désactivation du cache, un comportement aléatoire à ce niveau. Evidement tu plombes les perf du cache pour le bout code mais bon.
-
[^]Re: confusion...
Posté par ragoutoutou () le 15/12/2005 à 07:53. (lien). Évalué à 3.Tu peux imaginer des tas de truc pour lisser l'execution
Si, si, je peux parfaitement m'imaginer, ça a été mon boulot pendant quelques années.
Par contre, ce qui m'échappe, c'est l'intéret d'une cache de second niveau partagée dans de telles conditions, et j'ai beau regarder, j'en vois pas. Une cache séparée évite bien des problèmes tout en évitant de devoir faire mumuse avec des techniques qui n'ont pas leur place dans le contexte d'une mémoire cache L2.
De plus, sur les amd64, il y a le protocole moesi qui permet une communication intercache directe entre les divers processeurs d'un même système, qu'ils soient en dual core, en multi proc ou en multi dual core.-
[^]Re: confusion...
Posté par Nicolas Boulay () le 15/12/2005 à 08:41. (lien). Évalué à 2.Partagé le cache de niveau 2 est simplement un moyen d'aller plus vite que d'attendre la ram. Et cela évite aussi d'avoir besoin d'un cache write "though" qui à chaque écriture devrait mettre à jour la ram au cas ou l'autre cpu veuille y accéder.
-
[^]Re: confusion...
Posté par ragoutoutou () le 15/12/2005 à 09:14. (lien). Évalué à 2.Partagé le cache de niveau 2 est simplement un moyen d'aller plus vite que d'attendre la ram.
La communication intercache ne passe pas par la ram, donc c'est pas un argument.
Et cela évite aussi d'avoir besoin d'un cache write "though" qui à chaque écriture devrait mettre à jour la ram au cas ou l'autre cpu veuille y accéder.
Encore une fois, il y a déjà un protocole de communication intercache avec contrôle d'intégrité (même sur les intels), donc pas un argument non-plus.
-
-
-
-
-
-
-
-
-
[^]Re: confusion...
Posté par ragoutoutou () le 14/12/2005 à 08:16. (lien). Évalué à 7.La grosse bouse en question propose un hyperthreadnig fort agréable en pratique.
Ben si je disais que l'hyperthreading dans pas mal de cas c'est une grosse bouse aussi :P
Plus sérieusement, le P4 est un processeur qu'Intel a jeté sur le marché beaucoup trop tôt, sans laisser le temps aux ingés de le finaliser (le développement initial du P4 n'a duré que trois ans au lieu des 5 initialement prévus, ce qui en fait un grand prématuré). Dans les défauts de base du P4, on retrouve d'ailleurs un gros problème de fluidité entre les unités de décodage et les unités d'exécution, du coup, ces dernières n'étaient pas correctement alimentées en instructions.
L'hyperthreading est venu pour masquer ce problème en créant un système de pseudos-processeurs se partageant les unités d'exécution afin de réduire l'inoccupation chronique de celles-ci. Malheureusement, il est fréquent qu'un pseudo-processeur doive exécuter du code mais ne trouve pas d'unité d'exécution libre pour le traiter, ce qui rajoute des micro latences aléatoires dans l'exécution et rend l'hyperthreading particulièrement préjudiciable aux applications temps-réel.
D'un point de vue "processeur juste assez bon pour des trucs à haute latences ou pour le consommateur de base qui marche au marketting", le P4+HyperThreading est bon, pour le reste, c'est un processeur de merde qui a besoin de presque un ghz et pas mal de jus de plus que la concurrence pour faire la même chose.
D'un point de vue architecturale, le P4 est mal torché, c'est tout.-
[^]Re: confusion...
Posté par Nicolas Boulay () le 14/12/2005 à 17:03. (lien). Évalué à 2.Disons que le P4 s'est pris le mur de la chaleur dans la gueule.
Sans les problèmes de conso statique du 90nm, les P4 tourneraient à 5 Ghz.
Le SMT (hyperstring) permet de diminuer globalement les latences. Alors certe, c'est non prédictif mais bon, pour un serveur ou une station de travail c'est déjà ça de pris.
Les benchs d'appli Bi-cpu montrait une augmentation de 30% des perf, ce qui n'est pas négligeable. SUN mets 4 threads sur un Proco sans doute également très pipeliné (cf l'archi du proco XBOX360 qui est aussi bi-thread/cpu).-
[^]Re: confusion...
Posté par ragoutoutou () le 14/12/2005 à 19:50. (lien). Évalué à 2.Sans les problèmes de conso statique du 90nm, les P4 tourneraient à 5 Ghz.
Monter à 5ghz en P4, ça a autant de sens que de pousser un moteur de voiture à 15000 tours/minute en 3è vitesse. En plus, à 5ghz, l'électricité commence à avoir de sérieux problèmes de propagation (sur le temps d'un cycle, la lumière ne parcours que 6cm, l'électricité est beaucoup plus lente dans un processeur en surchauffe, les transistores ont eux-mêmes leurs latences, ce qui rend la propagation du signal dans le processeur beaucoup plus difficile dans une fenêtre de temps aussi réduite)
Pour l'hyperthreading sur le P4, le constat est simple: sur les applications optimisées P4, le gain est quasi nul, pour les applications otpimisées pour le PIII le gain peut monter effectivement dans les cas les mieux adaptés à 30%, mais c'est loin d'être une généralité, et au final ça ne rivalise pas avec la puissance par cycle d'un PIII, d'un Dothan ou d'un AMD64.-
[^]Re: confusion...
Posté par Antoine () le 14/12/2005 à 20:58. (lien). Évalué à 2.sur le temps d'un cycle, la lumière ne parcours que 6cm
Aucun impact sur la fréquence de pointe d'un pipeline de quelques millimètres de "longueur", et partagé en plus de 10 voire 20 étages.
et au final ça ne rivalise pas avec la puissance par cycle d'un PIII, d'un Dothan ou d'un AMD64
La "puissance par cycle" n'a aucune importance, ce qui compte c'est les performances réelles.-
[^]Re: confusion...
Posté par ragoutoutou () le 14/12/2005 à 21:20. (lien). Évalué à 2.La "puissance par cycle" n'a aucune importance, ce qui compte c'est les performances réelles.
les performances réelles, la conso électrique et la chaleur émise... et étonnemment, un manque d'efficacité par cycle semble tout de même mener à un manque d'efficacité electrique et à un manque d'efficacité thermique.
Chaque cycle a un coût.-
[^]Re: confusion...
Posté par Nicolas Boulay () le 14/12/2005 à 22:08. (lien). Évalué à 2.Chaque cycle a un cout certe, mais le cout des cycles des différents processeurs ne sont pas comparrable.
-
[^]Re: confusion...
Posté par ragoutoutou () le 14/12/2005 à 22:20. (lien). Évalué à 2.Dans le cas du P4, on constate en tout cas que le coût à fini par rattraper, les ambitions d'Intel...
-
-
-
-
[^]Re: confusion...
Posté par Nicolas Boulay () le 14/12/2005 à 22:09. (lien). Évalué à 2.L'analogie avec la voiture n'a pas lieu d'être.
A 5ghz, il serait plus rapide que la concurence. Il suffit de voir les overclocking extrème pour comprendre que le pb du P4 ce n'est pas la vitesse de propagation mais bien la chaleur (donc tes pbs lié au temps de propagation ne s'applique pas)-
[^]Re: confusion...
Posté par ragoutoutou () le 14/12/2005 à 22:31. (lien). Évalué à 3.A 5ghz, il serait plus rapide que la concurence.
et la concurrence à 4Ghz enterrerait le P4 à 5Ghz...
tu espères démontrer quoi?
La meilleure unité de mesure serait encore la consommation électrique: quel processeur fait le plus par watt, et encore une fois c'est pas le P4 qui gagnerait.
Le design du P4 est malheureusement trop éloigné des réalités physiques pour qu'on puisse dire qu'il est bon. Et puis, il me semble qu'intel promettait les 10Ghz lorsque le P4 est apparu... plutôt raté.
Au final, le coup du netburst ressemble plus à un coup de pocker manqué qu'à une architecture correctement ficelée.-
[^]Re: confusion...
Posté par Nicolas Boulay () le 15/12/2005 à 08:40. (lien). Évalué à 2.C'est clair que le marketing est passé par là.
Mais le pipeline extrème du P4 (40 étages !) présageait une bien plus grande monté en fréquence que la concurence (~20 étages).
Ensuite niveau consomation ou chaleur c'est identique puisque la chaleur c'est la conso d'un cpu.-
[^]Re: confusion...
Posté par nicodache () le 15/12/2005 à 08:53. (lien). Évalué à 2.je me souviens avoir lu 28 pour le NorthWood, et 32 pour le Prescott
contre 13 pour le Pentium M premier du nom, et 16 pour un Athlon 64.
Ca fait pitet pas 40 et 20, mais le rapport est le bien le même ;)-
[^]Re: confusion...
Posté par Nicolas Boulay () le 15/12/2005 à 09:04. (lien). Évalué à 3.en général, on regarde la longueur du pipe entier. Le pipe FPU et celui d'acces mémoire est en général bien plus long.
Je ne me rappelle plus la longuer de l'athlon 64, mais le 1er athlon était à 14 niveau et battait le PIII qui était à seulement 10 niveau (un peine rallongé pour le pentium M).
Le P4 était pour moi à 20 avec doublement du nombre d'étage ensuite.-
[^]Re: confusion...
Posté par ragoutoutou () le 15/12/2005 à 09:32. (lien). Évalué à 2.L'athlon64 a 12 étages de pipeline pour les entiers et 17 pour la fpu si ma mémoire est bonne.
20 étages nécessitent déjà une super bonne prédiction de branchements, 40 étages, j'ose même pas imaginer la gamelle à chaque prédiction ratée...
-
-
-
-
-
-
-
[^]Re: confusion...
Posté par reno () le 16/12/2005 à 22:03. (lien). Évalué à 2.> Disons que le P4 s'est pris le mur de la chaleur dans la gueule.
Il s'est surtout pris le mur des 'marketeux' dans la gueule: l'architecte principale du P4 a démissioné pour protester sur la direction que prenait le P4!
Ca veut tout dire.. Je pense que les ingénieurs de chez Intel sont aussi bon qu'ailleurs, mais encore faut-il les laisser bosser!
Si Intel n'a pas fait le x86-64 en premier, c'est problablement qu'ils avaient décidé de pousser l'Itanium a la place: leur design a eux (ok avec HP), plus besoin de lutter avec les clones..
-
-
[^]Re: confusion...
Posté par Ontologia (page perso, ) le 19/12/2005 à 21:15. (lien). Évalué à 2.Les perf décevantes du P4 ne viendrait pas aussi de la nullité des compilateurs ?
-
[^]Re: confusion...
Posté par ragoutoutou () le 20/12/2005 à 18:09. (lien). Évalué à 2.Celà m'étonnerait, Intel est le roi de l'optimisation compilateur.
Par contre il faut noter qu'avec le P4, le code optimisé pour les autres processeurs tourne plus mal que sur P3, Pentium M ou Athlon XP/64 ...
En compilant les applications de manière optimale pour le P4, ce dernier reste plus lent que la concurrence (mais regagne à peu près en perfs que que l'hyperthreading peut récupérer)... En fait du code optimisé p4 ne gagne rien avec l'hyperthreading (car tout le cpu est utilisé), alors que le code optimisé PIII, PM, AMD, peut gagner avec l'hyperthreading vu que le processeur est moins bien alimenté en instructions.-
[^]Re: confusion...
Posté par Ontologia (page perso, ) le 21/12/2005 à 10:41. (lien). Évalué à 2.Celà m'étonnerait, Intel est le roi de l'optimisation compilateur.
Il ne sont tout de même pas capable d'écrire un compilateur qui remplisse le pipeline, qui sache utiliser le SIMD à fond, etc...
Je me pose quelques questions...-
[^]Re: confusion...
Posté par ragoutoutou () le 21/12/2005 à 12:56. (lien). Évalué à 2.Quand tu vois les benchmarks des compilos intel face à gcc, tu te dis que tout de même ils s'en sortent vraiment bien question compilateur.
Tout n'est pas mauvais chez intel, loin de là. Le P4 est une bouse, mais le Yonah est vraiment un processeur exceptionnel si on en croit les benchs.
-
-
-
-
-
-
-
rien ne dit que SUN ouvre toutes les specs de l'UltraSPARC
Sun announced [...] and publish CERTAIN specifications for the UltraSPARC-based chip[...]
Ce qui veut dire que les specs intéressantes seront peut-être squizées par SUN, comme un utilisateur l'a fait remarqué sur son journal:
http://linuxfr.org/~jahrynx/20188.html
L'avis d'OpenBSD
L'avis de theo de raadt sur la question est interessant, vu que le projet OpenBSD a longtemps tente d'obtenir de la doc pour ameliorer le support des SUNs.
Voila sa premiere intervention sur misc@openbsd.org a ce sujet:
> We don't need processor docs. That stuff is trivial.
>
> We need *chipset docs*.
>
> And those are still not available under Sun's new program.
>
> So it is STILL a complete matter of reverse engineering.
>
> Same as with Apple, of course: powerpc is trivial. But the chipsets
> on every Apple machine are subtly different, full of bugs, and reading
> Darwin is a terrific waste of time since the code is so horrid, and of
> course, it is all just a maze of workarounds.
>
> Verilog for ultrasparc? Give me a break. We don't care.
En gros, aujourd'hui la majorite de la fonctionnalite d'un systeme est compose d'un processeur et de tous les chipsets l'entourant. Par extension il semble donc plus pratique d'avoir une documentation complete des fonctionnalites d'un CPU et des chipsets qui viennent avec plutot que les 'sources' d'un CPU.
Le mot de la fin de mr de raadt:
>> David Weaver has posted some more stuff, which you might want
>> to read.
>
> None of which matters at all. Years ago Sun refused us
> documentation.
> Nothing has changed.
>
> All Sun is trying to do is act fluffy, when they are not.
-
[^]Re: L'avis d'OpenBSD
Posté par briaeros007 () le 14/12/2005 à 12:53. (lien). Évalué à 0.We don't need processor docs. That stuff is trivial.
Il devrait en parler a l'équipe de fcpu si c'est si trivial que ca ...--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: L'avis d'OpenBSD
Posté par neriki (page perso, ) le 14/12/2005 à 13:22. (lien). Évalué à 4.Je pense qu'il parle de son point de vue de développeur d'OS,et il n'a pas totalement tort, quand les T1000 et T2000 sortiront, l'équipe d'OpenBSD devra quand même aller à la pêche au information sur les chipset de ceux ci pour pouvoir implémenter OpenBSD dessus, alors que (paradoxalement?) les CPU seront Open Source.
-
[^]Re: L'avis d'OpenBSD
Posté par vosgien_ () le 14/12/2005 à 13:35. (lien). Évalué à 3.Je ne vois pas le rapport, le projet F-CPU vise à créer un processeur risc aux spec libres, pas d'écrire du software qui tournera sur une architecture.
Il y a une grosse différence entre concevoir de A à Z une architecture, et écrire du software qui tournera dessus.
Par exemple pour écrire un driver, il n'y a pas besoin de connaître les schémas électriques de la carte : de la *bonne* doc suffit.
Enfin je pense que Théo a suffisement contribué aux architectures sparc (que ce soit sous NetBSD à l'époque où il en faisait partie ; ou OpenBSD) pour dire qu'un processeur est trivial à comprendre comparé aux chipsets.-
[^]Re: L'avis d'OpenBSD
Posté par Yann Hodique (page perso, ) le 14/12/2005 à 14:15. (lien). Évalué à 2.Je ne vois pas le rapport, le projet F-CPU vise à créer un processeur risc aux spec libres, pas d'écrire du software qui tournera sur une architecture.
Justement, je trouve que sur ce point précis, l'opinion de Theo de Raadt me rappelle un peu trop une transposition de l'argumentaire selon lequel les utilisateurs finaux n'ont que faire que le code soit libre, seules les fonctionnalités les intéressent.
C'est sans doute vrai, mais l'initiative de libérer le code n'est pas pour autant inutile, ni sans impact.
Dans le cas présent, je pense que l'étude du code des processeurs sera très instructive pour les gens qui développent du hardware, et en ce sens c'est une excellente chose.
Que ça n'ait pas d'utilité directe pour les développeurs de soft (ou utilisateurs de processeurs), je veux bien le croire, mais je ne vois vraiment pas en quoi ça justifie de rejeter le geste de Sun.
-
[^]Re: L'avis d'OpenBSD
Posté par briaeros007 () le 14/12/2005 à 14:19. (lien). Évalué à 0.comme il a dis que linux c'etait mal codé?
Si tu as le code vérilog tu as TOUTE les doc que tu veux (ca peut prendre du temps certe) sur le proc ...
Oui le code du chipset est aussi important,
mais monsieur theo de raadt a "l'engeulade" un peu facile amha.
Oui c'est pas parfait dans le meilleur du monde.
Oui il y a encore beaucoup de choses a faire.
Mais merde c'est déja un pas dans le bon sens. Et c'est pas en critiquant ce genre d'initiative que ca apporte quoi que ce soit.
Et non faire la doc d'un process c'est pas forcement "trivial" comme il le dis.
Quel que soit sa contribution.
Il ne faut pas oublier que la libération ne s'adresse pas qu'a monieur theo , mais a toute la communaute, donc ca interesse AUSSI la communaute qui développe du hard libre, etc...
Et non adapter du code pour qu'elle utilise au maximum un processeur ce n'est pas trivial si tu n'as pas la doc qu'il faut.--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: L'avis d'OpenBSD
Posté par vosgien_ () le 14/12/2005 à 15:28. (lien). Évalué à 6.Ce n'est pas du tout le débat. Je n'ai jamais dit que l'initiative était à rejetter... justement l'attitude de Sun depuis quelques temps est excellente.
Je ne comprend pas pourquoi tu dis que je critique...
Et non faire la doc d'un process c'est pas forcement "trivial" comme il le dis.
Quel que soit sa contribution.
Il a été le responsable du port sparc à l'époque ou il était encore dans NetBSD, et ses sontributions au port OpenBSD sont très importantes (comme le fait de booter un seul même kernel pour toutes les machines sun4, sun4c, et sun4m alors que Solaris n'en est pas capable).
Alors il me semble - sans vouloir te froisser - qu'il connaît un peu mieux le sujet que toi.
Il ne faut pas oublier que la libération ne s'adresse pas qu'a monieur theo , mais a toute la communaute, donc ca interesse AUSSI la communaute qui développe du hard libre, etc...
Oui, c'est justement pourquoi Théo réclame un tas de documentations aux différents constructeurs. Ce n'est pas QUE pour OpenBSD, c'est tout le monde qui bénéficie des différentes actions qu'il mène.
Et non adapter du code pour qu'elle utilise au maximum un processeur ce n'est pas trivial si tu n'as pas la doc qu'il faut.
C'est ce que je dis depuis le début... Il faut de la *bonne*.
C'est dommage que chaque discussion sur OpenBSD et Théo devienne tout de suite agréssive.-
[^]Re: L'avis d'OpenBSD
Posté par briaeros007 () le 14/12/2005 à 16:10. (lien). Évalué à 0.Je n'ai jamais dit que l'initiative était à rejetter... justement l'attitude de Sun depuis quelques temps est excellente.
Jene parlais pas de toi mais de lui : avec par exemple ce style de phrase :
All Sun is trying to do is act fluffy, when they are not.
Alors il me semble - sans vouloir te froisser - qu'il connaît un peu mieux le sujet que toi.
D'un point de vue logiciel (portabilité) etc.. sans aucun doute, et je n'ai jamais dit le contraire.
D'un point de vue matériel, besoin spécifiques, etc... peut etre pas (il ne connais pas forcément MES besoins).
Encore une fois : ce n'est pas parce que ca n'interesse pas monsieur theo que ca n'interesse personne ! Et c'est tout ce que je voulais dire (peut etre maladroitement je le reconnais)
Il a sans doute besoin AUSSI des docs des chipsets, mais NON -toute la- doc d'un processeur n'est pas trivial.
Peut etre que la partie qui l'interesse l'est elle. Mais la doc dans l'ensemble n'est pas trivial. Sinon tous les constructeurs de cpu publieraient leurs verilogs car ca serait "trivial" de l'avoir...
Oui, c'est justement pourquoi Théo réclame un tas de documentations aux différents constructeurs. Ce n'est pas QUE pour OpenBSD, c'est tout le monde qui bénéficie des différentes actions qu'il mène.
Et je l'en suis tres reconnaissant ;)
C'est ce que je dis depuis le début... Il faut de la *bonne*.
Et c'est ce que j'ai dis aussi : si on a le code verilog : on les a toutes (sans doute en prenant beaucoup de temps), on a donc la bonne par extension ;)
C'est dommage que chaque discussion sur OpenBSD et Théo devienne tout de suite agréssive.
Bof la discussion pas encore trop je trouve ;)--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
-
[^]Re: L'avis d'OpenBSD
Posté par Farvardin (page perso, ) le 14/12/2005 à 21:01. (lien). Évalué à 2.Theo de Raad a dit que linux c'est de la merde, que Darwin c'est de la merde, c'est étonnant qu'il n'ait pas encore dit que Solaris aussi c'était de la merde. Même avec aussi peu de sens diplomatie, sans doute que Theo espère quand même avoir ses docs sur les chipsets Spac ?
--
You can't grep dead trees...
-
-
-
-
[^]Re: L'avis d'OpenBSD
Posté par CyrrusSmith (page perso, ) le 14/12/2005 à 13:49. (lien). Évalué à 1.Gilles Gravier, m'a confirmé que dans le cas de NetBSD, le port s'était fait sans problème.
Leur politique serait plutôt de favoriser l'adaptation d'OS à leurs machines.
Je lui soumes donc l'avis de Théo en espérant qu'un progrés en sorte-
[^]Re: L'avis d'OpenBSD
Posté par CyrrusSmith (page perso, ) le 14/12/2005 à 15:37. (lien). Évalué à 5.Voici une réponse officielle de la part de Gilles Gravier ("Chief Technology Strategist for Security" de Sun):
<<La citation de Theo fait reference a une situation d'il y a plus d'un
an. Depuis (ce n'etait pas le cas a l'epoque) Solaris a ete mis en open
source. Maintenant, mieux que la doc des chipsets, il y a un source qui
peut etre considere comme une implementation de reference
particulierement bien optimise. La license qui vient avec permet aux
developeurs d'OpenBSD - ou tout autre OS libre - de re-utiliser ce code,
et meme de le modifier, afin de l'adapter a leur OS. Il semble que la
citation de Theo ne soit pas d'actualite... ou que quelqu'un doive lui
expliquer que le monde a change. Contrairement a Apple, Solaris est en
open source. Donc toute l'info necessaire pour acceder a nos
plateformes, dans leur integralite, est disponible publiquement, ainsi
que l'implementation de reference correspondante, avec une license tres
permissive. Il n'est plus necessaire de faire du reverse engineering,
comme il le pretend.>>
Peut être que Théo tient à faire ce reverse enginering, ou mieux accéder à une documentation complète, pour être sur de ce qu'il fait. (Le coté paranoïaque de OpenBSD).
Je comprend ce souci. Je pense aussi qu'il faut saluer des gestes positifs de libération de code ou d'architecture et encourager la suite. Cela ne doit pas empècher de demander cette suite.
Surtout j'espère que ce débat permettra de faire avancer les choses, amener effectivement plus d'information à être publiée, sans perdre de vue que Sun doit aussi vendre quelque chose quelque part pour payer ses employés.
-


Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.