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. On peut aussi trouver d'autres benchmarks allant dans le même sens sur le site d'Anandtech qui s'est récemment lancé dans les benchmarks sous Linux avec des résultats intéressants.
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.
Aller plus loin
- Le test sur LinuxHardware.org (10 clics)
- Anandtech (4 clics)
# Pour les modos.
Posté par Xavier Teyssier (site web personnel) . Évalué à 4.
[^] # Re: Pour les modos.
Posté par arnaudus . Évalué à 9.
[^] # Re: Pour les modos.
Posté par Jacquot Raphael . Évalué à -4.
[^] # Re: Pour les modos.
Posté par Stéphane Brunner . Évalué à -4.
[^] # Re: Pour les modos.
Posté par Yusei (Mastodon) . Évalué à 1.
(j'suis sûr que le gain de temps sur un apt-get est minime)
[^] # Re: Pour les modos.
Posté par Eric Heintzmann . Évalué à 1.
[^] # Re: Pour les modos.
Posté par un_brice (site web personnel) . Évalué à 2.
[^] # Re: Pour les modos.
Posté par Gniarf . Évalué à 10.
# scripts de build ?
Posté par 007 . Évalué à 3.
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 . Évalué à 2.
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?
Posté par ʭ ☯ . Évalué à 1.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Build scripts?
Posté par Croconux . Évalué à 4.
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 . Évalué à 8.
mais heureusement que plus personne n'utilise autre chose que
sizeof(int) pour déterminer ça...
[^] # Re: Build scripts?
Posté par Colin Leroy (site web personnel) . Évalué à 4.
[^] # Re: Build scripts?
Posté par Christophe Fergeau . Évalué à 2.
[^] # Re: Build scripts?
Posté par B. franck . Évalué à 1.
"fichier binaire cross plateform"
?
la portabilité ne concerne pas les binaires mais les mécanismes
pour les générer. (ou alors j'ai rien compris à la portabilité...)
[^] # Re: Build scripts?
Posté par 007 . Évalué à 3.
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 . Évalué à -1.
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 . Évalué à 1.
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 . Évalué à 4.
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 (site web personnel) . Évalué à 2.
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.
[^] # Re: Build scripts?
Posté par Caeies . Évalué à 2.
Manque juste de temps en temps des dépendances, et quelques segfault (XPrint) de temps en temps, à part ça, ça roule.
Google -> AMD64-HOWTO
Caeies, qui bosse sur un AMD64 ...
[^] # Re: Build scripts?
Posté par 007 . Évalué à 5.
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 . Évalué à 2.
[^] # Re: Build scripts?
Posté par 007 . Évalué à 2.
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 . Évalué à 1.
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 . Évalué à 1.
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 . Évalué à 1.
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 . Évalué à 0.
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 . Évalué à 1.
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 . Évalué à 3.
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 . Évalué à 0.
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 . Évalué à 2.
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 . Évalué à 1.
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 . Évalué à 2.
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 . Évalué à 1.
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 . Évalué à 1.
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 . Évalué à 1.
> 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 . Évalué à 1.
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 . Évalué à 2.
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 . Évalué à 1.
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 . Évalué à 1.
[^] # Re: Build scripts?
Posté par 007 . Évalué à 4.
[^] # Re: Build scripts?
Posté par Benoît Sibaud (site web personnel) . Évalué à 2.
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 . Évalué à 1.
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 . Évalué à 1.
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 . Évalué à 1.
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 . Évalué à 4.
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
[^] # Re: Build scripts?
Posté par Pooly (site web personnel) . Évalué à 1.
--> CVS plante a cause d'un chemin codé en dur abérant, etc...
[^] # Re: Build scripts?
Posté par Gwenole Beauchesne . Évalué à 2.
# 30% d'écart : voulu !
Posté par idiotduvillage . Évalué à 7.
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 . Évalué à 3.
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 . Évalué à 3.
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 . Évalué à 2.
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 . Évalué à 2.
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 F (site web personnel) . Évalué à 5.
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 . Évalué à 3.
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 . Évalué à 0.
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 ckyl . Évalué à 2.
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 . Évalué à 2.
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...
[^] # Re: 30% d'écart : voulu !
Posté par reno . Évalué à 2.
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 . Évalué à 1.
# AMD64 ou autre raison ?
Posté par Xmanu . Évalué à 3.
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 . Évalué à -1.
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 ?
Posté par renoo . Évalué à 5.
[^] # Re: AMD64 ou autre raison ?
Posté par godflesh . Évalué à 4.
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 (site web personnel) . Évalué à 4.
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 (site web personnel) . Évalué à 6.
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>
[^] # Re: AMD64 ou autre raison ?
Posté par kd . Évalué à 2.
Sauf que la hp48, elle tient dans la poche alors que le Cray... :-p
[^] # Re: AMD64 ou autre raison ?
Posté par Christophe Fergeau . Évalué à 2.
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 . Évalué à 3.
Patcher gcc ?
[^] # Re: AMD64 ou autre raison ?
Posté par matt . Évalué à 2.
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 . Évalué à 3.
[^] # Re: AMD64 ou autre raison ?
Posté par Gwenole Beauchesne . Évalué à 3.
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 . Évalué à 2.
Je suis juste curieux quoi ;)
[^] # Re: AMD64 ou autre raison ?
Posté par matt . Évalué à 2.
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 . Évalué à 1.
# Et le rapport perf/prix ?
Posté par cliklik . Évalué à -3.
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 (site web personnel) . Évalué à 4.
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).
[^] # Re: Et le rapport perf/prix ?
Posté par Xmanu . Évalué à 1.
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 ?
Posté par jeko . Évalué à 1.
# Le plus complet ?
Posté par ckyl . Évalué à 2.
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.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.