Articles précédents : Articles
- [125] La robustesse de nombreux navigateurs web mise en cause
- [10] Automates Intelligents prend position en faveur des Logiciels Libres
- [123] 10 ans d'OpenStep
- [23] Linux à Paris mais à petite dose pour le moment
- [8] Le logiciel libre selon ObjectWeb
- [11] Le courrier électronique, AOL et les autres
- [27] Conférences Brevets Logiciels au Parlement Européen
- [5] Sortie de BZFlag v1.10.8
- [0] La plate-forme libre PHP se présente devant le gouvernement
- [13] Annonce du Livre" Programmation OpenOffice.org - Macros OOoBasic et API"
Liens connexes
- Le test sur LinuxHardware.org (3693 clics)
- Anandtech (900 clics)
Dépêche modérée par
Dépêche éditée par
Mais aujourd'hui est sorti un des tests le plus complets à ce jour proposant une comparaison sous GNU/Linux des plateformes Intel en 32bits et AMD en 64bits, ainsi qu'une comparaison des chipset Via K8T800 Pro et NForce3, et leur support sous Linux.
L'avantage de la plateforme AMD est dorénavant très net.
![[en]](../../../images/en.png)
Le test sur LinuxHardware.org (3693 clics)-
Anandtech (900 clics)
> Lire la suite (82 commentaires, moyenne: 2,2). [dépêche : 657 caractères]
Ces différents tests amènent au mêmes résultats : les différences sont très clairement en faveur de l'AMD64.
Est-ce que cette grande différence de performance va entraîner une accélération du développement des versions 64 bits des distributions ?
NdM : À noter que de nombreuses distributions (gentoo, Slackware, Suse, Debian, Mandrake, Redhat, TurboLinux, Fedora) fournissent déjà des build scripts prêts pour l'AMD64.
Pour les modos.
sebian : c'est une nouvelle distribution, ou une faute de typographie ? ;-)
-
[^]Re: Pour les modos.
Posté par arnaudus () le 21/10/2004 à 07:58. (lien). Évalué à 9.C'est la contraction de "c'est bien debian", comme quoi nous sommes tous d'accord là dessus. :-) (on est jeudi on a pas le droit de répondre, nananère)
-
[+] [^]Re: Pour les modos.
Posté par Jacquot Raphael () le 21/10/2004 à 08:34. (lien). Évalué à -4.en fait, sur ce genre de plateforme, vaut mieux Gentoo :D
-
[+] [^]Re: Pour les modos.
Posté par Stéphane Brunner () le 21/10/2004 à 08:45. (lien). Évalué à -4.Peut tu développer ou es-ce un bête troll
-
[^]Re: Pour les modos.
Posté par Yusei () le 21/10/2004 à 09:43. (lien). Évalué à 1.Pour leurs benchs ils font un "emerge mozilla-firefox", et en concluent que l'Athlon64 est mieux, donc il faut utiliser Gentoo :)
(j'suis sûr que le gain de temps sur un apt-get est minime)-
[^]Re: Pour les modos.
-
[^]Re: Pour les modos.
Posté par Brice Arnould ( un_brice ) (page perso, ) le 21/10/2004 à 17:42. (lien). Évalué à 2.C'est beaucoup plus complexe que cela: il te faut un jeu complet de bibliothèques/appels système en 64 bits et qui va poser de gros problèmes aux programes 32 bits.
--
Respect à RMS.
-
-
-
-
-
-
[^]Re: Pour les modos.
scripts de build ?
> À noter que de nombreuses distributions (gentoo, Slackware, Suse, sebian, Mandrake, Redhat, TurboLinux, Fedora) fournissent déjà des build scripts prêts pour l'AMD64.
Pour Mandrake, Gentoo, SuSE, Red Hat, Fedora, ce ne sont pas des scripts de build mais des distributions complètes qui s'installent, s'utilisent comme n'importe quelle distribution.
Pour les autres distributions, j'en sais rien. Et sebian que je ne connais pas.
-
[^]Re: scripts de build ?
Posté par Mark Havel () le 21/10/2004 à 18:37. (lien). Évalué à 2.A ma connaissance, il n'y a pas encore de Slackware AMD64. Peut-être que si je m'étais payé une de ces merveilles l'année dernière il y en aurait eu une remarque, mais là, rien à part peut-être de quoi compiler tout ça pour de l'AMD64.
Sinon, sur ce test, il serait intéressant de connaitre les performaces des Intel E64MT, qui est la copie conforme du 64 bits d'AMD.
Build scripts?
dit comme ça, ça a l'air geek, alors qu'au moins pour Mandrake, ce sont de ISO de CD qui sont directement disponibles!
-
[^]Re: Build scripts?
Posté par Croconux () le 21/10/2004 à 08:26. (lien). Évalué à 4.alors qu'au moins pour Mandrake, ce sont de ISO
Sur tes isos il y a des paquets binaires et pour générer ces paquets, il faut un makefile ou assimilé (parce qu'on ne fait pas ça à la main). Par défaut gcc compile du code 32bits sur x86. Il faut ajouter l'option "-m64" pour qu'il génère du code 64bits. De plus les soft qui n'ont été testés qu'en 32bits par leurs auteurs ne compilent pas forcément out of the box (taille d'un int différente, etc).-
[^]Re: Build scripts?
Posté par B. franck (Jabber id, ) le 21/10/2004 à 09:00. (lien). Évalué à 8.(taille d'un int différente, etc).
mais heureusement que plus personne n'utilise autre chose que
sizeof(int) pour déterminer ça...-
[^]Re: Build scripts?
Posté par Colin Leroy (page perso, ) le 21/10/2004 à 09:46. (lien). Évalué à 4.ça ne suffit pas pour certaines choses - comme lire et écrire dans un fichier binaire que l'on veut cross-platform (c'est à dire 64bit-clean et endian-clean).
-
[^]Re: Build scripts?
Posté par Christophe Fergeau () le 21/10/2004 à 14:23. (lien). Évalué à 2.En tout cas, c'est pas ça qui pètera la compil (cf message de croconux). C'est bien plus chiant ce genre de bugs, faut trouver d'où ça sort ;)
-
[^]Re: Build scripts?
-
-
-
[^]Re: Build scripts?
Posté par 007 () le 21/10/2004 à 09:13. (lien). Évalué à 3.> Sur tes isos il y a des paquets binaires et pour générer ces paquets, il faut un makefile ou assimilé (parce qu'on ne fait pas ça à la main).
Comme sur i386. Dingue.
Oui il y a des scripts de build. Mais il y a mieux. Les isos déjà compilées et installables en x68-64. Linux n'est pas au stade ou il faut se taper des scripts de build pour bootstraper vers un système AMD64 contrairement à ce que sous-entend la news.-
[+] [^]Re: Build scripts?
Posté par godflesh () le 21/10/2004 à 09:26. (lien). Évalué à -1.MandrakeLinux
FedoraCore
Suze
Debian
Gentoo
Tous les grandes distrib existent toutes en versions compilés spécifiquement pour le 64bits.
D'ailleurs a mon avis cela enleve de l'interet a la Gentoo, car pour le coup, meme la debian est hyper optimisé niveau flags de compilation. Alors autant utilisé les pacquets deja tout pret, non ?
Ok, ok on pert un peu du controle tres fin qu'aime les Gentooiste. Je dis pas qu'il faut pas l'utiliser, juste que l'argument "performance" perd beaucoup de pertinence.-
[^]Re: Build scripts?
Posté par 007 () le 21/10/2004 à 10:07. (lien). Évalué à 1.Debian ?
Où tu as vu ça ?
Selon mes dernières infos (qui ne sont pas toutes fraiches), il n'y a pas d'iso AMD64 pour Debian et AMD64 n'est pas dans stable.-
[^]Re: Build scripts?
Posté par Fred Albrecht (page perso, ) le 21/10/2004 à 10:18. (lien). Évalué à 4.J'avais téléchargé un ISO AMD64 Debian à l'époque (il y a 3 ou 4 mois) où je cherchais un truc à mettre sur ma nouvelle machine mais c'était très très en Beta et très très casssé au niveau des dépendances. J'ai rapidement laissé tomber et je ne sais pas où c'en est. Finalement j'ai du me rabattre sur Gentoo qui est la seule a bien marcher sur ma config.
Mais tout le monde commence à s'y mettre doucement donc d'ici un an amd64 sera probablement une alternative praticable (c.à.d. simple à mettre en oeuvre). Pour l'instant il faut quand même être préparé à bidouiller un peu.
Quand à Mandrake que j'utilise habituellement sur le desktop, ils vendent leur version amd64 deux fois plus cher que la version i586. Pas cool. Et elle n'est pas dispo pour les membres de base du club.
Enfin bon, j'ai un truc qui marche même si e trouve Gentoo un peu laborieuse à mon goût, je vais pas trop me plaindre non plus :)-
[^]Re: Build scripts?
Posté par twisla (page perso, ) le 21/10/2004 à 10:39. (lien). Évalué à 2.à noter que SuSE fournit les 2 versions dans la boite de la 9.1 Pro, j'ai été bien content de pouvoir "garder" ma distro en passant d'un athlon xp à un athlon 64.
Crashdisk quelques jours plus tard, et geek oblige, c'est maintenant FreeBSD 5.3_STABLE qui tourne admirablement dessus.
J'ai eu l'occasion de comparer l'amd 64 3000+ à un P4E 3200, les perfs sont vraiment équivalantes (en termes de temps de compilation).
Je l'ai pas été plus loin, ni fait fait de 'benchs' entre linux/amd64 et FreeBSD/amd64.
Bien entendu, NetBSD et OpenBSD suportent aussi cette plateforme.--
twisla
-
[^]Re: Build scripts?
-
[^]Re: Build scripts?
Posté par 007 () le 21/10/2004 à 12:08. (lien). Évalué à 5.> Mais tout le monde commence à s'y mettre doucement
Faut arrêter ...
RHEL 3 (pour entreprise) a AMD64 depuis 1 an "out of the box".
Fedora Core a AMD64 depuis 1 an aussi (FC1).
SuSE depuis 1 an et Mandrake aussi.
Ce n'est plus au stade de laboratoire mais de déployement depuis une bonne année. Le remarquable c'est quand une distribution n'a pas d'AMD64 et pas l'inverse.-
[^]Re: Build scripts?
Posté par Gwenole Beauchesne (page perso, ) le 21/10/2004 à 23:17. (lien). Évalué à 2.SuSE et Mandrakelinux depuis 1 an et demi au moins. En fait, ils étaient d'ailleurs respectivement les premier et deuxième acteurs à soutenir Linux/AMD64 en fournissant des distributions natives 64-bit. Red Hat est venue après.
-
[^]Re: Build scripts?
Posté par 007 () le 22/10/2004 à 07:32. (lien). Évalué à 2.> Red Hat est venue après.
C'est facile...
Red Hat a beaucoup plus fait pour AMD64 que Mandrakelinux qui a au maximum 4 développeurs pour gcc et linux toutes architectures confondues.
être le premier avec une personne à mi-temps...
De plus amd64 est apparu dans Rawhide _bien avant_ Cooker. Entre autre car il fallait modifier rpm pour être bi-architecture et c'est RedHat qui a fait ce boulot pour rh9 (qui a donc un rpm bi-arch :-)) qui était la base de RHEL 3 (qui est dispo pour AMD64). Par contre Mandrake c'est mis à vendre des boîtes un peu avant tout le monde.
Le boulot, c'est principalement SuSE et Red Hat qui l'a fait. Peut-être plus SuSE que Red Hat (surtout au début). Mais Mandrake ne compte pour rien ou presque dans l'histoire. Désolé, c'est une réalité.-
[^]Re: Build scripts?
Posté par Gwenole Beauchesne (page perso, ) le 22/10/2004 à 08:24. (lien). Évalué à 1.Il existait zéro support x86_64/amd64 dans rpm quand SuSE et Mandrakesoft ont commencé.
Il n'y a rien de fait initialement et de manière significative par Red Hat concernant le kernel/gcc/glibc/xf86 sur x86_64. C'est SuSE + AMD. C'est une chose.
L'autre chose, c'est la correction des programmes pour 64-bit + lib64 + spécificités mises en exergue sur x86_64. Là, Mandrakesoft était un acteur important: Mozilla, Kaffe, OOo au début, etc. et plus d'une centaine de fixes 64-bit par distrib en moyenne. Même pour gnome2 c'était SuSE et MDK, c'est dire...-
[^]Re: Build scripts?
Posté par 007 () le 22/10/2004 à 09:51. (lien). Évalué à 1.Une employé (ou ex-employé?) de Mandrake vient casser du Red Hat ici.
Très surprenant...
> Il existait zéro support x86_64/amd64 dans rpm quand SuSE et Mandrakesoft ont commencé.
_TU_ a dis que Mandrakesoft a commencé il y a un an et demi. Or il y a un an et demi rpm avais le support bi-arch (Version 4.2 de rpm, qui était dans RH9 qui est sorti en mars 2003).
Du changelog de rpm (4.1 à 4.2) :
- elfutils: avoid gcc-3.2 ICE on x86_64 for now.
- add explicit -L/lib64 -L/usr/lib64 for libtool mode=relink on x86_64.
- calculate dependency color and refernces.
- add per-arch canonical color, only x86_64 enabled for now.
En août 2003, Red Hat avais une beta pour AMD64 :
http://www.redhat.com/archives/taroon-beta-list/2003-July/msg00003.(...)
- Date: 29 Jul 2003 11:18:53 -0400
Red Hat Enterprise Linux 3 Beta 1 is available for the following
architectures:
- x86 (i686/Athlon 32-bit)
- ia64 (Intel Itanium2 64-bit)
- x86_64 (AMD64 64-bit)
- ppc (IBM iSeries and pSeries 64-bit)
- s390 (IBM S/390 31-bit)
- s390x (IBM zSeries 64-bit)
C'est basé sur RH9 qui est sorti en mars 2003 !
> à, Mandrakesoft était un acteur important
Puisque que tu le dis.
Mais c'est "bizarre" quand je fais des "egrep -i @mandrake" j'ai pratiquement rien.
Quand je fais des "egrep -i @((redhat)|(suse))" J'en ai des tonnes.
Exemple pour gcc :
find . -type f -print0 | xargs -0 env LANG=C egrep -i "@((redhat)|(suse))" | wc -l
13121
find . -type f -print0 | xargs -0 env LANG=C egrep -i "@mandrake" | wc -l
4 <=
Je te laisse le soit de séparer redhat de suse si tu veux. Tu verras que je suis "gentil" de les mettre à égalité.
Fais ça aussi pour Linux, c'est très instructif. gcc est le projet où il faut le plus travailler pour faire le portage vers un nouveau cpu. Après c'est Linux.-
[^]Re: Build scripts?
Posté par Gwenole Beauchesne (page perso, ) le 22/10/2004 à 10:20. (lien). Évalué à 1.Mandrakesoft a commencé en mai 2002, et il y avait déjà des démos sur divers salons, notamment Linux World 2002 à Frankfurt (une 9.0).
Pour kernel/gcc/glibc/xf86, j'ai explicitement parlé de SuSE + AMD, si tu pouvais relire. D'ailleurs, je pense que tu n'as pas du lire les docs de SuSE pour le portage de ces outils.-
[^]Re: Build scripts?
Posté par 007 () le 22/10/2004 à 10:43. (lien). Évalué à 0.> Mandrakesoft a commencé en mai 2002
Suse et Red Hat plus de 18 mois avant !
> Pour kernel/gcc/glibc/xf86, j'ai explicitement parlé de SuSE + AMD
Fichtre, j'ai dit :
- "Le boulot, c'est principalement SuSE et Red Hat qui l'a fait. Peut-être plus SuSE que Red Hat (surtout au début)."
D'accord, j'ai oublié AMD. Désolé pour AMD qui a eu l'énorme gentillesse de donner un excellent coup de main et de fournir les specs. J'ai aussi oublié TurboLinux...
> si tu pouvais relire.
Même conseil.
> D'ailleurs, je pense que tu n'as pas du lire les docs de SuSE pour le portage de ces outils.
Tout juste.
Qu'on soit bien d'accord. J'ai rien à repprocher que Mandrake bosse beaucoup ou pas sur tel ou tel projet. C'est une petite boîte, les temps sont dures, etc... Mandrake fait, je n'en doute pas, du mieux qu'ils peuvent avec leur moyen et compte tenu qu'il faut bien finir l'année avec de l'argent en caisse :-). De plus c'est un acteur du logiciel libre. Donc elle a mon respect pour ça.
Par contre je n'aime pas qu'on s'attribue le boulot des autres.
-
[^]Re: Build scripts?
Posté par 007 () le 22/10/2004 à 10:48. (lien). Évalué à 1.> Mandrakesoft a commencé en mai 2002
Oui.
> notamment Linux World 2002 à Frankfurt (une 9.0).
Non.
http://www.mandrakesoft.com/company/press/briefs?n=/mandrakesoft/ne(...)-
[^]Re: Build scripts?
Posté par Gwenole Beauchesne (page perso, ) le 22/10/2004 à 12:10. (lien). Évalué à 3.AMD Developer Symposium, je ne vois pas Red Hat:
http://www.amd.com/us-en/Weblets/0,,7832_8366_7595~56764,00.html(...)
Linux World à la même date:
http://www.mandrakesoft.com/company/community/mandrakesoftnews/news(...)-
[^]Re: Build scripts?
Posté par 007 () le 22/10/2004 à 14:06. (lien). Évalué à 0.> http://www.amd.com/us-en/Weblets/0,,7832_8366_7595~56764,00.html(...)
C'est un "show" en _Allemagne_ qui est la place gardée de SuSE. Red Hat est basé aux USA. Tu veras que Red Hat est dans plein de "manifestations" aux USA et pas Mandrake. C'est normal. Prends gcc ou Linux et regardes le nombre de modif faites par Red Hat. C'est ça qui compte.
Regardes ici :
http://www.amd.com/us-en/Weblets/0,,7832_8366_7595~62592,00.html(...)
Et ici (la page Red Hat n'existe plus) :
http://www.x86-64.org/news_year?year=2002(...)
- * August 13, 2002
Red Hat And AMD Announce Red Hat Linux Advanced Server Operating System For AMD's Hammer Technology
Red Hat n'était pas en train d'attendre que Mandrake fasse le portage ...
> http://www.mandrakesoft.com/company/community/mandrakesoftnews/news(...)
Mandrake Linux 9.0 est en cours de portage sur Hammer, la nouvelle génération de processeur 64-bit d'AMD.
Mais t'as pas tord. Quand j'ai mis le lien au dessus, je pensais (à tord) que Mandrake 9.0 était sortie en même temps pour i386 et x86_64. Et donc qu'il n'y avais pas de béta avant 2003 (en considérant 3 mois de béta).
Notes qu'il y avait une preview x86_64 de Red Hat en même temps que la sortie de Mdk 9.0 AMD64. :
http://lwn.net/Articles/30923/(...)
Et j'ai _déjà_ dit que Mandrake a fait des offres avant tout le monde. Et même avant SuSE qui a fait le plus de boulot !-
[^]Re: Build scripts?
Posté par Gwenole Beauchesne (page perso, ) le 22/10/2004 à 17:54. (lien). Évalué à 2.> Prends gcc ou Linux et regardes le nombre de modif faites par Red Hat. C'est ça qui compte.
Bon sang, lis tout s'il te plaît. C'est normal que Red Hat travaille beaucoup plus que quiconque sur GCC, ils ont phagocyté Cygnus. Pour x86_64, je te redis encore que le portage est fait par SuSE (spécification et implémentation de l'ABI), et c'est toujours eux qui le maintiennent en grande partie. Ensuite, il existe des corrections de bugs habituels, comme sur n'importe quelle distrib, sur n'importe quelle architecture avec l'évolution des versions, etc.
> Red Hat And AMD Announce Red Hat Linux Advanced Server Operating System For AMD's Hammer Technology
Et puis as-tu vraiment vu ce produit tourner au moment de l'annonce de l'intention de supporter RHAS sur x86_64? C'est ça la différence. Sur quels shows RHAS x86_64 a-t-il été montré? Remarque en outre, que Mandrakesoft faisait également des démos de la distrib aux US, sur le stand AMD.
Tu sais, Apple avait également annoncé l'ordinateur personnel le plus rapide au monde. Mais là, je tombe dans le troll. ;-)-
[^]Re: Build scripts?
Posté par 007 () le 22/10/2004 à 19:46. (lien). Évalué à 1.Je ne vois pas où tu veux en venir.
Au début tu dis :
- "SuSE et Mandrakelinux depuis 1 an et demi au moins. En fait, ils étaient d'ailleurs respectivement les premier et deuxième acteurs à soutenir Linux/AMD64 en fournissant des distributions natives 64-bit. Red Hat est venue après."
Pourquoi "Red Hat est venue après." ? Pour sous-entendre que Red Hat ne soutenait pas AMD64 ? Ben c'est faux.
Puis :
- "Là, Mandrakesoft était un acteur important: Mozilla, Kaffe, OOo au début, etc. et plus d'une centaine de fixes 64-bit par distrib en moyenne. Même pour gnome2 c'était SuSE et MDK, c'est dire..."
Pourquoi ? Pour sous-entendre que Red Hat est opportuniste et attend que les autres fassent le boulot ? C'est faux.
Si tu veux dire que Mandrake a packagé (et débugger aussi biensûr) en premier AMD 64, je suis d'accord et je l'ai déjà dit. Si ton intention est de dire que Red Hat n'a rien foutu en attendant, alors je ne suis pas d'accord. Si Mandrake avait _réellement_ bossé sur le portage dès le début, il n'y aurait pas que 4 malheureux "@mandrake" dans les sources de gcc. Je me trompe ?
Si, comme tu le sous-entends plus loins, Red Hat a la main mise sur gcc, alors Red Hat a fait le portage de gcc pour AMD64 (ce qui est le plus difficile (au moins techniquement) à réaliser). Faut choisir.
Mandrake a sorti une distribution avec Linux 2.6 avant Red Hat (si tu mets de côté Fedora, Mandrake aura 1 an (!) d'avance). Tu vas encore conclure que Red Hat n'a rien foutu pour Linux 2.6. Ben si je regarde les changelog de Linux 2.6, je vois _0_ (ou presque), nada, contribution de Mandrake. Moi, je m'en fous. Mandrake est une petite boîte et est libre de bosser sur ce qu'ils veulent. Mais ce n'est pas car Mandrake sort quelque chose avant tout le monde qu'il ont _forcément_ bossés plus que les autres et que les autres sont des branleurs.
Ça te ferait plaisir si je dis "Red Hat depuis 2 ans au moins est le premier acteur à soutenir utf8 en fournissant des distributions utf8. Mandrake est venue après et d'ailleur Red Hat a fixé plein de bugs sans Mandrake..." ? (sous-entendu, Mandrake s'en fous et profite du boulot des autres).
J'image que ça ne te ferait pas plaisir. Et j'image que pour toi (et pour moi aussi) ça n'est que du troll.
A ma connaissance Mandrake est utf8 seulement depuis Mandrake 10.0.
Je peux multiplier les exemples avec NPLT, Gnome 2.8, xorg, etc...
Pour AMD64, Fedora a AMD64 et i386 synchrone (depuis FC2T2). Le debuggage/mise au point pour AMD64 est fait via Fedora. Ça te ferait plaisir si je dis "Red Hat corrige plein de bug sans Mandrake qui arrive après" ?
J'essaie de troller à ton niveau.
> Bon sang, lis tout s'il te plaît. C'est normal que Red Hat travaille beaucoup plus que quiconque sur GCC
Oui.
> ils ont phagocyté Cygnus.
Et ? C'est du FUD ou quoi ?
Que Mandrake fork gcc et fasse le boulot Red Hat si ça te plait pas.
Il y a bien une grosse participation de SuSE dans gcc ou je me trompe encore ?
Red Hat a "phagocyté Cygnus" depuis les origines de gcc ? (gcc qui existait bien bien avant Linux et Red Hat et Cygnus).
Pour ton info, il y a 55 000 adresses mail dans les sources dont "seulement" 10 000 @redhat. Il y a de la place pour Mandrake et Mandrake sera plus que bienvenu pour contribuer à gcc. Tu cherches de fausse excuse.
Durant le portage de Mandrake vers AMD64, j'image que vous avez eu des bugs avec gcc. Es-ce que les développeurs gcc de Red Hat vous ont envoyé bouller lorsqu'il y avait un bug à corriger ? N'ont-ils pas essayé dans la mesure de leur disponibilité de fixer les bugs de gcc pour que Mandrake pour AMD64 sorte ?
Ou Mandrake a fait son propre gcc dans son coin pour _son_ portage vers AMD64 ?
> Et puis as-tu vraiment vu ce produit tourner au moment de l'annonce de l'intention de supporter RHAS sur x86_64?
Puisqu'on est au niveau troll :
Mandrake annonce qu'il vont bosser sur un truc quand le boulot est déjà fait par les autres pour avoir "On annonce commencer à travailler sur bidule et bidule est déjà disponible en béta. Champagne, on est trop fort ! vive nous !".
L'engagement de Red Hat (et surtout SuSE) date de l'année 2000 et pas 2002 comme Mandrake ! Le portage vers un nouveau processeur demande un énorme travail de fond.
Ce n'est pas : "tiens, et si on portait Linux sous AMD64. Plop : 1 mois après une distribution complète qui tourne".
J'ai pas envis de m'"énerver" avec Mandrake. J'ai rien à reprocher à Mandrake sur ça. Mais tu trolles, tu FUD et ça me souâle.
PS : désolé d'avoir trollé comme un con dans ce post.-
[^]Re: Build scripts?
Posté par Gwenole Beauchesne (page perso, ) le 22/10/2004 à 20:30. (lien). Évalué à 2.> Pourquoi "Red Hat est venue après." ? Pour sous-entendre que Red Hat ne soutenait pas AMD64 ? Ben c'est faux.
Et
> * August 13, 2002
> Red Hat And AMD Announce Red Hat Linux Advanced Server Operating System For AMD's Hammer Technology
Tu veux sans doute parler de:
http://www.amd.com/us-en/Weblets/0,,7832_8366_7595~41287,00.html(...)
"Red Hat and AMD will demonstrate the 32-bit Red Hat Linux Advanced Server operating system on a 64-bit AMD Athlon processor based on Hammer technology at LinuxWorld 2002, San Francisco August 13-15 (AMD Booth #747)."
i.e. ils n'avaient pas encore de version 64-bit à montrer, alors que SuSE et Mandrakesoft si.
> Si, comme tu le sous-entends plus loins, Red Hat a la main mise sur gcc, alors Red Hat a fait le portage de gcc pour AMD64 (ce qui est le plus difficile (au moins techniquement) à réaliser). Faut choisir.
Il n'y a aucun raisonnement logique dans cette hypothèse. Je t'ai déjà dit plusieurs fois que c'était SuSE qui l'a fait. Y compris pour kernel, glibc, xf86. Au moins un bonhomme chaque (Jan, Andi, Andreas, Egbert). J'ai l'impression que quand je parle de SuSE, tu penses MDK. M'enfin bon.
Les premières plate-formes matérielles à être "largement" diffusées sont apparues vers Q2 2002. Auparavant SuSE travaillait d'abord via SimNow!, puis Simics qui est plus rapide. FreeBSD était développé sous Simics aussi d'ailleurs. En d'autres termes, il fallait être très patient. i.e. le portage d'une distribution complète était conditionné par le déploiement des plate-formes matérielles en quelque sorte.
Il faut arrêter de croire que tout débute par Red Hat. Pour l'AMD64, c'était clairement SuSE. D'ailleurs AMD les payait pour le faire justement, si je me rappelle bien. J'espère que tu saisis maintenant.-
[^]Re: Build scripts?
Posté par 007 () le 23/10/2004 à 10:18. (lien). Évalué à 1.> Il faut arrêter de croire que tout débute par Red Hat.
Je n'ai pas dit ça.
> Pour l'AMD64, c'était clairement SuSE.
Et ce n'est pas ce que j'ai dit ? Le travail de SuSE, ont le voit dans les sources !
> J'espère que tu saisis maintenant.
Que t'as des méthodes "trollesques". Oui, je saisis.
-
-
-
-
-
-
-
-
-
-
-
[^]Re: Build scripts?
Posté par 007 () le 22/10/2004 à 07:58. (lien). Évalué à 1.> SuSE et Mandrakelinux depuis 1 an et demi au moins.
amd64 c'est plus vieux et SuSE et Red Hat bossent sur amd64 depuis 4 ans:
Aout 2000 :
http://www.amd.com/us-en/Weblets/0,,7832_8366_7595~704,00.html(...)
- Linux Developers Support AMD's x86-64™ Technology
"We are excited to be working with AMD to provide AMD's "Hammer" family of processors to the Linux community," said Paul McNamara, VP of Products and Platforms, Red Hat, Inc. "As leaders in the Linux space, our expertise will help AMD provide a solid foundation for this technology."
"AMD's x86-64™ architecture provides the perfect platform for SuSE to pursue its enterprise strategy," said Volker Wiegand, president of SuSE Inc.
http://investors.redhat.com/ireye/ir_site.zhtml?ticker=RHAT&scr(...)
15 Août 2000 :
- "AMD is thrilled with the prospect of leveraging Red Hat's expertise in the Linux community and is looking forward to working closely with them on the development of an x86-64 powered Linux distribution," said Richard Heye, vice president and general manager, AMD's Athlon Product Division. "Since AMD's x86-64 architecture adds 64-bit extensions to the existing x86 code base, Linux users will have the advantage and ability to continue using all of Red Hat's existing 32-bit software as they migrate to 64-bit applications."
-
-
[^]Re: Build scripts?
Posté par Fred Albrecht (page perso, ) le 22/10/2004 à 11:54. (lien). Évalué à 1.> Faut arrêter ...
> RHEL 3 (pour entreprise) a AMD64 depuis 1 an "out of the box".
> Fedora Core a AMD64 depuis 1 an aussi (FC1).
> SuSE depuis 1 an et Mandrake aussi.
C'est pas au niveau des distributions, là il n'y a généralement pas de problème, après tout les Unix 64 bits ce n'est pas franchement nouveau, c'est plutôt les gadgets autour : pas d'acrobat reader (quoiqu'on peut faire tourner la version 32 bits en bricolant), pas de Flash, pas de jeux, pas de pilotes ATI, etc.
C'est là qu'il y a un petit effort à faire et je pense que ça viendra une fois que le parc se sera étoffé. Sinon pour travailler au quotidien sur amd64 je confirme qu'il n'y a effectivement pas de problèmes particuliers. Et de nos jours pratiquement n'importe quel logiciel compile sans problèmes (et tourne ensuite).
-
-
[^]Re: Build scripts?
Posté par zeSixty4Douille () le 21/10/2004 à 13:06. (lien). Évalué à 1.pour Mdk, tu peux downloader gratos la beta 2 de la 10.1 pour AMD 64. puis tu as les sites ftp avec les pkg qui sont en acces libre pour la 10.0 (encore heureux, pkg = CD) ... La seule diff, c'est que les drivers OpenGL en 32-bit sont dispo que pour la distrib vendue en boite (mais qu'est-ce qu'on s'en fout ).
De plus, tu as egalement la beta 1 pour ppc avec des pkg recents. Puis tu as Fedora qui doit proposer le meme genre de chose.
Enfin bref, pour l'utilisateur final la seule chose qui manque en 64-bit c'est flash (par contre il a java 1.5 pour amd64 ... ), ce qui ne me gene pas trop. Pour la reste ce sont des distrib standards, en plus rapide.
Ce qui est d'ailleurs paradoxal, c'est le temps de lancement des appli me semble + court, alors que les lib sont 1 peu plus grosse.-
[^]Re: Build scripts?
Posté par Gwenole Beauchesne (page perso, ) le 21/10/2004 à 23:23. (lien). Évalué à 2.En fait le plug-in Flash 32-bit tourne avec un Konqueror 64-bit et un nsplugins 32-bit. Cela parce que le support des plug-ins type Netscape4 dans Konqueror se fait via un processus séparé, qui peut donc être 32-bit.
Il existe également un JDK 1.4.2 pour x86-64. D'ailleurs la nouvelle -fcs est disponible sur les miroirs depuis fin septembre. Le plug-in OJI mozilla 64-bit ne fonctionnera pas avec les distribs compilées avec GCC 3.4. Ce sera normalement possible avec la prochaine release du 1.4.2 et les autres 1.5.0 fournies par Blackdown.org.-
[^]Re: Build scripts?
Posté par zeSixty4Douille () le 22/10/2004 à 09:59. (lien). Évalué à 1.ok, merci pour ces infos. je n'ai meme pas flash d'installe en 32-bit.
je downloaderai ce soir la Beta2 de la 10.1.
Question en passant :
Je n'ai pas reussit a trouver les pkg necessaires sur plf pour compresser un DVD. Y a t-il un site ftp ou je puisse les recupperer ? j'essaierai les src.rpm. Y a t-il des difficultes pour ces pkg ?-
[^]Re: Build scripts?
Posté par Gwenole Beauchesne (page perso, ) le 22/10/2004 à 21:37. (lien). Évalué à 1.Tu voudras sans doute utiliser la version 32-bit de PLF. Certains packages contiennent des optimisations spécifiques MMX, SSE qui sont directement écrits en assembleur inline. Si le développeur n'a pas utilisé des intrinsics proprement, ou bien prévu le coup pour les modes d'adressage x86_64, ben ces optimisations ne passent pas donc ça utilise du code générique.
-
-
-
-
-
-
-
-
[^]Re: Build scripts?
Posté par 007 () le 21/10/2004 à 09:15. (lien). Évalué à 4.Les int sur x86-64 font 32 bits. -m64 indique que les long et les adresses font 64 bits (contrairement à i386 où c'est aussi 32 bits).
-
[^]Re: Build scripts?
Posté par Benoît Sibaud (Jabber id, page perso, ) le 21/10/2004 à 12:52. (lien). Évalué à 2.Solaris Ultrasparc
char 1 short 2 int 4 long 4 long long 8 float 4 double 8 long double 16
Linux x86
char 1 short 2 int 4 long 4 long long 8 float 4 double 8 long double 12-
[^]Re: Build scripts?
Posté par zeSixty4Douille () le 21/10/2004 à 13:50. (lien). Évalué à 1.En C :
Sur UltraSparc :
si xarch=v9[ab] (64-bit)
=> int = 4 octets, pointeur = 8 octets, long = 8 octets.
si xarch=v8* (32-bit)
=> comme d'habitude.
Donc c'est comme avec gcc avec ou sans "-m64".
tu peux jouer sur l'alignement, et tout et tout, et de nombreuses options te montrent qu'optimiser, c'est pas seulement choisir l'optimisation par defaut, ou l'architecture par defaut (du style i686, surtout avec gcc). Donc Gento => boff.
Sous MINDOM$ :
=> long = 4 octets
-
-
-
[^]Re: Build scripts?
Posté par zeSixty4Douille () le 21/10/2004 à 11:29. (lien). Évalué à 1.int = 32-bit en 64-bit, tu dois confondre avec les long. il y a d'autres problemes, du style manipulations d'uint converti en long.
Lorsque l'on commence a optimiser un programme, avec des compilateurs recents, il y a d'autres problemes qui surgissent et qui sont bien plus emmerdant que ca. Je parle juste de compiler une appli en 64-bit, et pas de modifier une application pour qu'elle profite a fond du 64-bit.
RH et Mdk, tu as les lib deja compile, ainsi que certaines lib en 32-bit sur le CD (openGL en + pour Mdk).
Enfin, j'ai plus mon v20z sous la main, mais il me semble que le "-m64" est active par defaut si tu utilises une plateforme AMD64.-
[^]Re: Build scripts?
Posté par 007 () le 21/10/2004 à 12:04. (lien). Évalué à 1.> int = 32-bit en 64-bit, tu dois confondre avec les long.
Certains cpu ont int = 64 bits.
J'ai vu ça pour DEC-UNIX sur alpha (si j'ai bonne mémoire car c'est vieux...) avec long = 64 bits aussi.-
[^]Re: Build scripts?
Posté par imalip (page perso, ) le 21/10/2004 à 12:23. (lien). Évalué à 4.J'ai vu encore plus rigolo sur un DSP Analog Device :
char = short = long = int = 32 bits
Dans ce cas-la, c'est bon de travailler a cote sur quelque chose de plus classique pour ne pas prendre de mauvaises habitudes--
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal
-
-
-
-
[^]Re: Build scripts?
Posté par Pooly (page perso, ) le 21/10/2004 à 12:50. (lien). Évalué à 1.qui sont d'ailleurs compilés avec les pieds... (enfin la 9.2)
--> CVS plante a cause d'un chemin codé en dur abérant, etc...-
[^]Re: Build scripts?
Posté par Gwenole Beauchesne (page perso, ) le 21/10/2004 à 23:27. (lien). Évalué à 2.Il faut rapporter les bugs, sinon tu as zéro chance que ce soit corrigé sauf si tu le fais toi-même et que tu gardes tout ça dans ton coin.
-
30% d'écart : voulu !
Je crois en effet que l'écart de performances en mode 64bits a été voulu par Intel !
Intel a toutjours affirmé qu'il n'y avait aucun intérêt à passer au 64bits pour le grand public sauf après 2010 ou plus tard encore. Ils ont cependant été obligés de sortir un CPU 32/64bits comme l'Opteron/Athlon64 à cause de l'efficacité (performance, prix, compatibilité) des processeurs AMD. AMD a donc ouvert une brèche dans le segment des serveurs pour des processeurs 64bits compatibles au niveau code avec les 32bits sans que les performances ne s'effondrent.
En face, Intel n'avait que l'Itanium taillé pour les serveurs et le haut de gamme professionnel. Le problème c'est que cette nouvelle architecture a mis beaucoup de temps à mûrir, qu'elle coûte considérablement plus chers que les Opterons tout en étant incompatible avec l'existant.
En d'autres termes, plus Intel propose un proc 32/64bits performant, plus il faut de l'ombre à la famille Itanium.
Quoiqu'il en soit, Intel sait aussi qu'AMD a des moyens très limités, aussi bien en recherche-développement qu'en capacité de production. AMD ne pourra pas accaparer plus de 10% du marché des serveurs à moyen terme.
L'ironie de l'histoire c'est que AMD (faisant 1/10è d'Intel) a su leur imposer leur jeu d'instructions X86-64 même si, pour sauver la face, l'ont purement et simplement renommé sous EMT64.
-
[^]Re: 30% d'écart : voulu !
Posté par zeSixty4Douille () le 21/10/2004 à 10:03. (lien). Évalué à 3.AMD a deja plus de 10% du marche des serveurs (il doit se vendre 50 fois plus d'Opteron que d'Itanium). Malheureusement je n'ai pas de liens.
Il y a un autre effet de bord autours du succes du x86-64 : l'interet de .NET (du moins a court terme). Microsoft a inventer .NET en partie pour qu'un programme puisse fonctionner OPTIMISE pour toutes les plateformes HW ou serait present Windows. Hors si il n'y a que l'x86-64, quel est l'interet par rapport a compiler classiquement son programme ?-
[^]Re: 30% d'écart : voulu !
Posté par idiotduvillage () le 21/10/2004 à 11:08. (lien). Évalué à 3.Oui, il se vend beaucoup plus d'Opteron que d'Itanium, mais les deux ne jouent pas exactement dans la même cours : le Xeon, t'en fais quoi ? Il ne faut pas oublier que c'est une puce pour serveur très utilisée (non compatible 64bits jusqu'à il y a peu).
Là où AMD fait le plus de ventes, c'est dans les serveurs bas-milieu de gamme pendant qu'Intel essaie de s'approprier le marché du haut-très haut de gamme.
Cependant, l'Opteron est suffisamment polyvalent pour s'attaquer à tous ces marchés mais il y a encore de nombreuses (grande majorité) d'entreprises qui ne jurent que part Intel.
Il est en tout cas clair que le chemin que l'Athlon-MP a mis a parcourir en plusieurs années, l'Opteron l'a dépassé en termes de part de marché en beaucoup moins de temps.
C'est un excellent signe pour la santé financière d'AMD qui n'a pas les moyens de se dissiper dans plusieurs projets de grande envergure (tels que l'Itanium justement)-
[^]Re: 30% d'écart : voulu !
Posté par zeSixty4Douille () le 21/10/2004 à 11:41. (lien). Évalué à 2.A propos des part de marche, il faut ajouter qu'il y a un partenariat d'AMD avec IBM pour fondre certains Opterons. Donc meme si AMD est petit par rapport a Intel, il pourrait approvisionner le marche sans trop de probleme.
Enfin il y a aussi le prix qui me semble un facteur important : les Opterons haut de gamme sont plus couteux que les Xeon (j'en ai jamais achete, c'est juste ce que l'on m'a raconte). Puis la necessite de passer en 64-bit, puis les Unixes qui tassent leurs prix ...-
[^]Re: 30% d'écart : voulu !
Posté par Mark Havel () le 21/10/2004 à 18:57. (lien). Évalué à 2.Non, parce que ce contrat porte sur de l'échange de technologies de fonte de processeur, pas sur de la sous-traitance éventuelle à IBM pour fabriquer des puces. Donc, moyennant quelques miyons de dollars, IBM leur file quelques techniques de fabrication, mais AMD se démerde toujours pour le fabriquer lui même à Dresde, voire peut-être à Austin. Cela fait pour l'instant 2 usines (et j'ai entendu dire que celle d'Austin n'était plus utilisée) et 3 dans quelques années (ils en refont une autre à Dresde) grand maximum, ce qui est toujours bien moins qu'Intel.
Donc, en cas de problème sur une technologie de gravure comme ils en ont avec le 90 nm actuellement, ils sont dans la merde. Enfin de toutes façons, depuis 1999 et les Athlons, ils n'arrêtent pas de bouffer de la part de marché à Intel. S'ils continuent comme ça, ils peuvent prendre encore plus de place à l'avenir. D'autant qu'Intel n'a pas trop intérêt judiciairement à être en quasi monopole sur le marché, je pense.
-
-
-
-
[^]Re: 30% d'écart : voulu !
Posté par Philippe Fremy (page perso, ) le 21/10/2004 à 10:34. (lien). Évalué à 5.J'avais lu il y a 5 ans un article sur un site de hardware qui predisait exactement ce qui est en train de se passer aujourd'hui : AMD depasse Intel grace a son architecture 64 bits, notamment parce que l'architecture d'AMD est plus pensee pour etre compatible avec les optimisations des compilateurs pour les architectures precedentes.
L'article (que j'aurai du bookmarker) faisait remarquer que les optimisations de compilateurs ont 3 a 4 ans de retard sur les fonctinnalites des derniers CPU. Et que donc le CPU le mieux est celui qui marche bien avec les anciennes optimisations.
Je salue ce visionnaire dont j'ai tout oublie sauf le message.-
[^]Re: 30% d'écart : voulu !
Posté par TSelek () le 21/10/2004 à 11:17. (lien). Évalué à 3.ArsTechnica (ou un du même style) ?
En fait Intel avait déjà fait la même bétise sur un proc dédié embarqué, le même genre que l'itanium : parallelisme, oui, mais dont le support commence dans le compilo lui même. comme il faut 2/3 ans pour faire un compilo optimisé, ben ce chip n'a jamais eu le succes voulu (ni les perfs d'ailleurs).
ArsTechnica avait alors dit que cet echec se reproduiserait sur Itanium, dont acte.
surtout qu'on savait déjà à l'époque qu'il valait mieux passer 1 an sur le compilo pour gagner encore et encore 5 ou 10% de perf, plutôt que sur un nouveau chip 10% plus rapide, car si ces 10% dépendent aussi du compilo, ben on se reprend un cycle de dev, software cette fois ci, en plus dans les dents.
et paf Intel.
c'est beau de voir des échecs prédits sur des bases faciles à appréhender se réaliser effectivement ;) ça m'emeut, allez, vive le keyword management \o/-
[^]Re: 30% d'écart : voulu !
Posté par reno () le 21/10/2004 à 20:21. (lien). Évalué à 0.>c'est beau de voir des échecs prédits sur des bases faciles à appréhender se réaliser effectivement ;)
Bof, c'est facile mais pas toujours agreable a voir:
- facile de voir que la bulle internet allait se casser la figure, c'est arrivé mais bon, ce n'est pas agreable pour autant,
- j'ai parié que l'UMTS ne se generaliserait pas avant 2007 (sauf au Japon qui sont technophiles), m'ont l'air a peu pres dans les temps: devrait etre disponible avant mais pas forcement utilisé --> pas tres agreable a voir quand tu bosses pour un fournisseur telecom!
Pour l'Itanium c'est plus marrant (pour moi :-): on a eu au boulot il y a un an une presentation de commerciaux d'HP qui vendaient leur beurre, ils étaient tout fier de nous presenter la premiere station de travail a base d'Itanium, j'avoue que le plus dur c'était de garder son sérieux, mais on a bien rigolé au café après..
Je crois qu'HP ne vend plus de station de travail avec Itanium maintenant..-
[^]Re: 30% d'écart : voulu !
Posté par cykl () le 21/10/2004 à 21:07. (lien). Évalué à 2.> Je crois qu'HP ne vend plus de station de travail avec Itanium maintenant..
Je sais pas s'ils en vendent encore mais par contre je sais qu'ils proposent encore deux TER (master) pour bosser sur les compilo pour itanium. Donc ils doivent encore avoir des interets dedans. Je vais tenter de voir les sujets de cette annee savoir de quoi il en retourne.
En même temps qu'ils fassent devel/valider des trucs par des incompetents ayant du mal avec bases comme la gestion mémoire n'est pas forcement bon signe non plus :-)
-
[^]Re: 30% d'écart : voulu !
Posté par imalip (page perso, ) le 22/10/2004 à 15:49. (lien). Évalué à 2.j'ai parié que l'UMTS ne se generaliserait pas avant 2007 (sauf au Japon qui sont technophiles), m'ont l'air a peu pres dans les temps: devrait etre disponible avant mais pas forcement utilisé --> pas tres agreable a voir quand tu bosses pour un fournisseur telecom!
l'UMTS fonctionne en Angleterre et va etre bientot commercialise. J'ai un telephone UMTS sur mon bureau, il est fonctionnel, je fais du streaming, du download et de la videophonie. Il l'est d'ailleurs deja pour les cartes PCMCIA. Pour faire les tests en France et en Italie, on le fait sur reseau existant.
Je crois qu'HP ne vend plus de station de travail avec Itanium maintenant..
Et que sgi vient d'entrer sur ce marche...--
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal-
[^]Re: 30% d'écart : voulu !
Posté par reno () le 22/10/2004 à 16:30. (lien). Évalué à 2.Pour l'UMTS, par generaliser, je voulais dire: avec des clients qui l'utilisent vraiment et avec des tarifs normaux, pas seulement disponible..
Pour la disponibilite, effectivement ca commence, pour l'utilisation on va voir..
Deux ans pour "eduquer le consommateur", ce ne sera pas de trop!
-
-
-
-
-
[^]Re: 30% d'écart : voulu !
Posté par Gwenole Beauchesne (page perso, ) le 21/10/2004 à 23:33. (lien). Évalué à 1.L'Itanium n'est pas incompatible avec l'existant. OpenOffice.org et Mozilla 32-bit fonctionnent très bien grâce à l'émulateur IA-32 intégré au processeur. Sur des processeurs récents dépourvu de l'émulateur hard, il existe une solution logicielle plus rapide: IA-32 EL. C'est également disponible sous Linux. Les performances mesurées sont de l'ordre de 70% en moyenne d'un Xeon cadencé à la même fréquence.
AMD64 ou autre raison ?
Les performances sont-elles réellement à attribuer au passage aux 64 bits ou bien viennent-elles de l'architecture K8 ? Un contrôleur de mémoire intégré, ça aide. Un bus HyperTransport à 1GHz sur les dernières CPU aussi.
Ces deux observations ne retirent rien de la qualité des puces d'AMD, simplement elles replacent les tests dans leur contexte.
-
[+] [^]Re: AMD64 ou autre raison ?
Posté par B. franck (Jabber id, ) le 21/10/2004 à 09:14. (lien). Évalué à -1.le principal intérêt du 64bit ne se situe pas dans les performances
mais dans la quantité de mémoire allouable.
Monter l'intégralité d'une base de donnée en mémoire donne les meilleures performances.-
[^]Re: AMD64 ou autre raison ?
-
-
[^]Re: AMD64 ou autre raison ?
Posté par godflesh () le 21/10/2004 à 09:29. (lien). Évalué à 4.Une des raisons tient au fait que le proc a plus de registres en 64bits.
Néanmoins, peut importe les raisons, l'interet est de voir que sous Linux, utiliser une distrib en 64bits permet d'avoir des perfs tres supérieures au 32bits que ca soit sur le meme proco ou sur une architecture Intel.-
[^]Re: AMD64 ou autre raison ?
Posté par Xavier Teyssier (Jabber id, page perso, ) le 21/10/2004 à 10:23. (lien). Évalué à 4.Une des raisons tient au fait que le proc a plus de registres en 64bits.
Des registres 64 bits ? Ça me rappelle le bon vieux temps : c'est ce qu'on avait sur le Saturn, le processeur de la HP-48, il y a plus de 10 ans !-
[^]Re: AMD64 ou autre raison ?
Posté par Jean-Max Reymond (Jabber id, page perso, ) le 21/10/2004 à 10:49. (lien). Évalué à 6.Et sur Cray, il y a 20 ans...
Ouf, j'ai pris un coup de vieux :-(
Plaisanterie mise à part, les très bonnes perfs de l'AMD64 viennent majoritairement du controleur mémoire intégré sur le chip ce qui fait que le CPU est bien alimenté en permanence.
Plus de registres, c'est bien pour le compilateur (et l'esprit) mais ça pénalise les context switch car plus de registres à sauver.
<troll mode on>
et quand on voit que Linux se sert toujours sur plate-forme Intel de ce bon vieux gcc au lieu du compilo special optim Intel, on se dit qu'on peut encore gagner ;-)
</troll mode off>--
CKR Solutions Open Source-
[^]Re: AMD64 ou autre raison ?
-
-
-
[^]Re: AMD64 ou autre raison ?
Posté par Christophe Fergeau () le 21/10/2004 à 14:29. (lien). Évalué à 2.Cool, je pensais que j'étais le seul à avoir conscience que le code 64bits en tant que tel avait probablement peu d'intérêt (ne serait-ce que parce qu'un truc compilé en 64bits bouffe probablement plus de cache que le même truc compilé en 32bits), mais que par contre le plus grand nombre de registres (et le contrôleur mémoire intégré, auquel je n'avais pas trop pensé) devaient y être pour beaucoup dans les 30% de perfs en plus.
Il y a d'autres gens qui réfléchissent au delà du 32bits<64bits sur linuxfr, c'est rassurant :)
Qqu'un sait si y a moyen de générer du code 32 bits en utilisant les registres supplémentaires pour voir le rôle que ça jour dans l'augmentation de perfs ?-
[^]Re: AMD64 ou autre raison ?
Posté par imalip (page perso, ) le 21/10/2004 à 14:39. (lien). Évalué à 3.Qqu'un sait si y a moyen de générer du code 32 bits en utilisant les registres supplémentaires pour voir le rôle que ça jour dans l'augmentation de perfs ?
Patcher gcc ?--
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal-
[^]Re: AMD64 ou autre raison ?
Posté par matt () le 21/10/2004 à 15:36. (lien). Évalué à 2.vu qu'il faut passer dans un mode processeur special pour utiliser le code amd64 (un peu comme le mode protegé a partir des 386), il faut donc obligatoirement passer en 64 bits pour que les registres suplementaires soient activés.
Mais bon c'est vrai qu'apres y'a peut etre des bidouilles possible, mais a ma connaissance, meme sur des 386 il est impossible d'utiliser les registre 32bits (genre EAX) sans etre passer en mode protegé.-
[^]Re: AMD64 ou autre raison ?
Posté par pasBill pasGates () le 21/10/2004 à 19:33. (lien). Évalué à 3.Tu peux utiliser EA/B/C/DX sans aucun probleme sans etre en mode protege.
-
-
-
[^]Re: AMD64 ou autre raison ?
Posté par Gwenole Beauchesne (page perso, ) le 21/10/2004 à 23:43. (lien). Évalué à 3.Il est possible de générer du code 32-bit en utilisant les registres supplémentaires. Par contre, il faut créer une nouvelle ABI ILP32 pour que ce soit plus intéressant. Un peut comme les modes o32/n32 sur IRIX/mips. Ca induit de patcher kernel, binutils, gcc, glibc.
L'intérêt est une meilleure occupation du cache mais si le gain est inférieur à 5%, à mon avis, ça ne vaut pas l'effort. Si ça se fait en toy project, Mandrakelinux est très facilement retargetable en plate-forme triarch au niveau packaging. ;-)-
[^]Re: AMD64 ou autre raison ?
Posté par Christophe Fergeau () le 22/10/2004 à 10:49. (lien). Évalué à 2.Je suis juste intéressé par des résultats de benchs sur une telle plateforme comparé à la même chose mais en activant le mode 64bits. C'est clair que c'est probablement peu intéressant de maintenir une distrib IA32+registres supplémentaire par contre.
Je suis juste curieux quoi ;)
-
-
-
-
[^]Re: AMD64 ou autre raison ?
Posté par matt () le 21/10/2004 à 15:31. (lien). Évalué à 2.En fait c'est du en tres grandes parties aux 8 registres suplementaires : ca evite d'incessant acces en memoire.
Il suffit de regarder l'asm cree par un compilo 64 bits pour s'en rendre compte.
Donc si un compilo compile en amd64 mais en utilisant seulement 8 registres, a mon avis y'a quasiment pas de gain de perf : faudrais tester.
L'architecture nouvelle aporte aussi un peu de perf, mais la c'est tout a fait visible entre un 3000+ et un 3000+64 dans un environement 32bits-
[^]Re: AMD64 ou autre raison ?
Posté par Gwenole Beauchesne (page perso, ) le 21/10/2004 à 23:48. (lien). Évalué à 1.Il faut aussi noter qu'avec 16 GPRs et FPRs, on peut créer une ABI décente.
-
[+] Et le rapport perf/prix ?
Je n'ai aucune idée des différences de coûts entre ces architectures :
AMD Athlon 64 3800+ - 2.4 GHz, Cache L2 512 Ko Socket 939 (version boite) 649,00 EUR
Intel Pentium 4 550 (3.4 GHz) Socket 775 0.09 micron FSB800 (version boîte - origine distributeur agréé Intel - garantie Intel 3 ans) 279,51 EUR
Intel Pentium 4 560 (3.6 GHz) Socket 775 0.09 micron FSB800 (version boîte - origine distributeur agréé Intel - garantie Intel 3 ans) 429,01 EUR
AMD à l'air plus cher de 30% ?
-
[^]Re: Et le rapport perf/prix ?
Posté par riri le breton (page perso, ) le 21/10/2004 à 10:39. (lien). Évalué à 4.Comparons ce qui est comparable:
AMD Athlon 64 3500+ Socket 939 (Box + ventilo) : 358,00 EUR
AMD Athlon 64 3700+ Socket 754 (Box + ventilo) : 519,00 EUR
AMD Athlon 64 3800+ Socket 939 (Box + ventilo) : 645,90 EUR
(source multe-pass.com)
A vitesse 'annoncée', c'est en gros le même prix (l'AMD 3500+ se trouve entre les prix des P4 3400 et 3600).--
La liberté d'une personne s'arrête là où commence celle des autres.
-
[^]Re: Et le rapport perf/prix ?
Posté par Xmanu () le 21/10/2004 à 10:43. (lien). Évalué à 1.c'est vrai, vous n'avez aucune idée des différences de coûts entre ces (micro-)architectures... mais alors d'où viennent ces chiffres ?
Sérieusement, les prix que vous indiquez sont réalistes, mais notez bien que dans les tests il y a un Pentium4 EE 3.4 GHz et là on dépasse les 1000 euro(s) sur le marché.
Par ailleurs, le but n'était pas de faire une étude d'appel d'offre, mais simplement de comparer les performances (sans limitation de budget) et de montrer l'intérêt d'utiliser les apports de l'architecture K8 dans les distributions gnu/linux. Le test aurait pu prendre en compte d'autres machines d'architectures différentes POWER5 ou Itanium pour parler de la concurrence sérieuse en matière de performances. Et là encore les prix peuvent faire débat...-
[^]Re: Et le rapport perf/prix ?
-
Le plus complet ?
> un des tests le plus complets à ce jour
http://www.thejemreport.com/modules.php?op=modload&name=News&am(...)
Ca date juste de mars 04...
Et c'est bien plus interessant que des graphes a deux balles qui sortent dont ne sait où amha.
Cette page a été générée par Templeet en 0.3198s (dont 0.0808 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
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.