Un billet pour "fêter" le remplacement de mon vieux PC. Un excellent Athlon 1600 XP qui m'a bien rendu service. D'ailleurs c'est sur ce dernier que je fais ce journal (je n'ai pas encore tout migré vers le nouveau PC).
Pour noël on m'a offert un PC d'occasion à base de Intel Core 2. D'occasion, mais de belle qualité, avec une fabuleuse carte mère Asus P5B, et "garnie" (disques, boîtier, carte graphique, mémoire, excellente alimentation)). Tous les composants "amoureusement" choisis auprès d'un assembleur (évidemment sans passer par la taxe Windows).
Certes, j'aurais probablement dû acheter un autre PC. M'enfin, mon vieux Athlon marchait et basta. Hors la technologie VT pour la virtualisation, rien ne me manquait.
Le cadeau fait (merci), j'ai un premier défit. Caser 5 disques SATA, 2 disques EIDE et un lecteur de DVD. Ça n'a pas été facile (les câbles), mais c'est fait. Le boîtier étant de belle qualité, le tout est convenablement ventilé (sans être bruyant).
Puis une grosse interrogation a envahi mon cerveau. i386 ou x86_64 ?
Etant un malade mordu de Fedora (pour ceux qui n'auraient pas deviné), j'avais en mémoire que cette dernière est utilisé à 20 % sur x86_64 :
http://smolts.org/stats
C'est rassurant. L'intérêt de passer à x86_64 vu l'utilisation que je fais de mon PC est assez limité pour ne pas dire nul. Mon instinct d'aventurier a pris le dessus et j'ai foncé pour x86_64 [musique d'Indiana Jones en fond].
L'installation c'est faite depuis une clée usb (il faut y "graver" en une poignée de seconde une petite images de quelques Mo). Le reste de l'installation étant récupéré via réseau (sur mon vieux PC).
Je prend l'installation par défaut proposé par Fedora (profile bureautique), j'ajouterai le reste à coup de "yum install". L'installation des paquets se fait en 10 minutes ! Damned ! L'installation occupe 3,5 Go.
Petit conseille, lors de l'installation ajoutez le dépôt des mises à jours, comme ça tout est installé avec les dernières versions "qui vont biens".
Que dire ? Ben tout marche. Il y a cohabitation i386/x86_64 pour les cas exotiques (comprendre les trucs proprios qui ne sont pas passés à x86_64). J'ai goûté à la virtualisation (KVM/Qemu plus spécifiquement) => c'est que du bonheur.
Bref, faites le saut vers x86_64. Idéalement avec une Fedora évidemment, mais utilisez pire si ça vous chante sinon. x86_64 est l'avenir (en tout cas plus que le i386) et ça le fait les doigts dans le nez.
La carte graphique est une NVidia. Je me refuse à utiliser les drivers proprio, donc pas de compizzz et toussa. Ça ne me manque pas (sauf pour FlightGear, on va voir si je résiste à la tentation :-)).
J'ai un Intel Core 2 (malgré moi si j'ose dire). Intel est un "gentil" dans le monde du libre. M'enfin, préférez un AMD (le rapport performance/prix est au moins aussi avantageux). Mais surtout AMD via ATI bosse sur un driver libre pour que le libre ait des cartes graphiques de haute volée.
M'acheter une carte ATI est tout en haut de mes priorités même si ce n'est pas mieux que ma nouvelle carte Nvidia "d'occasion" (mon vieux Athlon avait une vieille Matrox G400 avec driver libre). 2008 devrait voir l'arrivé en libre de la partie 3D des cartes ATI.
Notons que le projet Nouveau avance (pour moi : ne pas oublier de le tester).
Linuxiens, linuxiennes, bonne année et vive linuxfr.org.
Journal x86_64
30
déc.
2007
# pire?
Posté par tfeserver tfe (site web personnel) . Évalué à 1.
Pire qu'une fedora? il faut vraiment tomber bas.
[^] # Re: pire?
Posté par Snarky . Évalué à 3.
[^] # Re: pire?
Posté par IsNotGood . Évalué à -2.
Ubuntu ?
[^] # Re: pire?
Posté par Gwenole Beauchesne . Évalué à 1.
C'est tout à fait possible, et Fedora est déjà assez bas, mais ça s'améliore petit à petit. Les pires de toutes sont Ubuntu, Debian, Gentoo, dans cet ordre (vers la pire) et selon mes critères d'un point de vue utilisation, organisation, et développement.
[^] # Non, tu ne peux pas...
Posté par Natja . Évalué à 1.
[^] # Re: Non, tu ne peux pas...
Posté par mats . Évalué à 1.
[^] # Re: Non, tu ne peux pas...
Posté par Gniarf . Évalué à 2.
# soixante-quatre bites powaaaa !
Posté par Snarky . Évalué à 2.
Avant, il y avait bien encore des soucis de compatibilité de logiciels, même libre, mais ça c'est bien arrangé. Il ne reste que les trucs proprio que j'utilise qui posent encore des problèmes :
Opera -> Mais la 9.5 béta est sortie en 64bits, donc, ça ira maintenant
Flash -> La pire chose qui puisse exister.... Ça me fait planter tous mes navigateurs... Je suis obliger de l'utiliser sur un firefox qui tourne sous wine.
Codec nvidia -> Mais bon, ça fait un bail qui sont correctement supporté en x86_64.
Donc, plus la peine de réfléchir maintenant, opter pour le 64bits.
Juste une question aux développeur ici présent. Quel genre d'optimisation logiciel il est possible de faire pour tirer partie du 64bits ? Parce que personnellement, je développe toujours de la même façon sur cette plateforme.
[^] # Re: soixante-quatre bites powaaaa !
Posté par IsNotGood . Évalué à 2.
Il n'y a rien à faire !
C'est le compilateur qui gère ça.
Si tu as besoin d'un int (un mot machine), utilise un int (s'il est 32 bits sous un OS 64 bits, ce n'est pas un problème de performance, c'est même souvent un atout (moins de pression sur le cache)).
Utilise un short si ça te suffit. Notons que ça fait depuis des années que le bus de donnée des pentium et équivalent est sur 64 bits. Le x86_64 n'a rien changé ici (à ma connaissance).
Faire des calculs en long alors que int suffit, n'apportent rien. C'est seulement pour des optimisations très très spécifiques (pour dans certain cas faire un calcul en long au-lieu de deux en int).
Pour la mémoire, c'est comme d'habitude, size_t/ptrdiff_t (32 bits sur OS 32 bits, 64 bits sur OS 64 bits).
Surtout, ne rien faire de spécifique pour 32 bits et 64 bits. Il suffit de programmer selon les règles de l'art et tout baigne.
Tu peux avoir des gains plus "massif" en utilisant MMX/SSE/etc (que je ne connais pas :-)).
> Parce que personnellement, je développe toujours de la même façon sur cette plateforme.
Continu. OS 32 bits ou 64 bits, je programme toujours de la même façon et je ne vois pas de raison de changer.
[^] # Re: soixante-quatre bites powaaaa !
Posté par Zenitram (site web personnel) . Évalué à 3.
Donc si on a 2 Go de RAM, quelle est l'utilité de s'embéter avec le 64 bits qui peut poser probleme sur des softs non testés pour, si on ne gagne ni en vitesse (les calculs sur des entiers 64 bits marchent déja pas mal sur des archis 32 bits... le CPU sait faire), ni en fonctionnalités?
Tu codes de la même façon, OK, mais du coup je ne vois aucun interet de passer en 64 bits si c'est pour avoir xactement la même chose.
Si quelqu'un dans la salle peut me donner une raison de passer en 64 bits...
PS : en dehors des applis réclamant plus de 2 Go de RAM, la le gain est évident : on peut utiliser plus de RAM pour un seul programme, mais 99% de nos softs n'ont pas besoin d'autant... :)
[^] # Re: soixante-quatre bites powaaaa !
Posté par IsNotGood . Évalué à 1.
Ben oui, il n'y a aucun raisons "évidentes" de passer à 64 bits. Je n'ai jamais dit le contraire.
Le 64 bits se justifie si on a un gros besoin de mémoire (plus de 4 Go (ou 2 ?) par processus ou plus de 64 Go pour le système (i686 a le mode PAE)).
> PS : en dehors des applis réclamant plus de 2 Go de RAM
Plus de 2 Go (ou 4?) de mémoire virtuelle (pas seulement de RAM).
> Tu codes de la même façon, OK, mais du coup je ne vois aucun interet de passer en 64 bits si c'est pour avoir xactement la même chose.
Quel est le coût de passer à 64 bits ?
Un peu plus de mémoire consommé (les pointeurs sont sur 8 octets et non 4).
Donc passons à 64 bits, ainsi ça marche aussi dans le cas (même si actuellement peu probable) où on a un gros besoin de mémoire.
S'il y a beaucoup de uniquement x86_64, on pourra peut-être avoir des cpu moins chez. Actuellement ils doivent supporter x86_64 ET i686. Partout ou le i686 peut-être utilisé, le x86_64 peut-être utilisé.
[^] # Re: soixante-quatre bites powaaaa !
Posté par Fabimaru (site web personnel) . Évalué à 1.
A part ça, ça peut être utile pour un programme ayant besoin de beaucoup d'espace d'adressage, par exemple si il mappe un fichier en mémoire (fonction "mmap") de grosse taille (plus de 2 ou 3Go).
[^] # Re: soixante-quatre bites powaaaa !
Posté par M . Évalué à 2.
Aucune : les perfs sur x86_64 par rapport à i386 sont surtout du aux différences d'architectures (plus de registre en 64bits qu'en 32 bits, ...).
Sur les autres bi-architectures 32/64 bits (sparc, ppc) les perfs sont meilleures avec des appli 32 bits qu'en 64 bits.
Pourquoi ? Parce que dans ce cas l'archi est quasiment la même, seul la taille du bus change. Et comme la plupart des appli n'utilisent pas de données 64 bits le 32 bits leur suffit (et elles n'ont pas à ce trimballer du code plus gros, des datas plus grosses (pointeurs 2 fois plus gros, ...), ...).
Si on osait caser la compatibilité i386, je pense que l'on pourrait aussi avoir un mode 32 bits plus rapide que le 64 bits sur x86_64.
[^] # Re: soixante-quatre bites powaaaa !
Posté par IsNotGood . Évalué à 1.
La compatibilité est déjà cassée. Le "truc" est que les amd64 ou Intel Core 2 supportent les deux jeux d'instructions. Évidemment, parfois on retourne les mêmes instructions. Inutile de réinventer la roue.
[^] # Re: soixante-quatre bites powaaaa !
Posté par IsNotGood . Évalué à 1.
s/retourne/retrouve/
[^] # Re: soixante-quatre bites powaaaa !
Posté par Obsidian . Évalué à 2.
[^] # Re: soixante-quatre bites powaaaa !
Posté par Gwenole Beauchesne . Évalué à 1.
Il n'est pas possible d'utiliser les nouveaux registres en mode 32-bit. IIRC, il avait existé un tel mode dans les premiers prototypes mais personne n'en voulait à l'époque...
Cependant, on pourrait imaginer une ABI ILP32 en long mode, donc avec tous les registres, en utilisant le préfixe ADDR32 pour forcer des load/stores en 32-bit d'adresse[*]. Mais ce genre de LCP n'est pas un usage recommandé et nécessite quelques cycles supplémentaires pour le décodage, dans mon souvenir sur de l'Intel en tout cas. Par contre, il me semble que la nouvelle ABI de vxworks suive un modèle similaire de nos jours.
[*] Au niveau organisation des libs, j'avais imaginé que cela se case dans du */lib32 (comme les équivalents mips N32) vs du */lib (mips O32), et le x86_64 dans */lib64, classiquement. C'est pour ça, et pour d'autres raisons, que je maudis toutes les distributions qui bâtardisent ce système en conservant les libs 64-bit dans */lib et poussent le vice à créer spécialement du */lib32 pour du i386 legacy, ce qui est un total non-sens...
[^] # Re: soixante-quatre bites powaaaa !
Posté par Pierre Tramo (site web personnel) . Évalué à -1.
[^] # Re: soixante-quatre bites powaaaa !
Posté par superna (site web personnel) . Évalué à 1.
De méme, le pas de "casser" la compatibilité i386 serait evidemment simple, il suffirait d'inventer un assembleur trés proche des microcodes intel et amd.
Mais est-ce que le """"""""monopole""""""""" est prêt et à les couilles de changer ? Est-ce que leurs dev sont assez compétents pour faire un Rosetta-like ?
Pour moi le principal avantage de x86_64 est le nombre de registre, et la plus grosse faiblesse des instructions i686 est le nombre de registre limité même si par derrière le cpu optimise a mort et le compilo aussi ! Pourquoi ne pas se voiler la face et enlever ces deux optimisations qui sont comme un frein....
(Imaginez que l'internet soit composé que de tunnel qui compressent en amont et décompressent sur le routeur et rebelotte entre chaque routeur...)
[^] # Re: soixante-quatre bites powaaaa !
Posté par IsNotGood . Évalué à 1.
Un OS 32 bits peut utilise un cpu très efficace en calcul sur 64 bits ou 128 bits (entier ou flottant). C'est aujourd'hui le cas.
Il y a peut-être confusion avec les cartes graphiques dites 64 bits ou 128 bits. Ici la taille indique le mot machine. C'est à dire la taille la mieu adaptée au GPU (par exemple ses registres). Ça n'indique pas la taille de l'adressage. Il n'y a pas de cartes graphiques de plus de 4 Go à ma connaissance et encore moins qui ont besoin d'un adressage supérieur à 2^64.
[^] # Re: soixante-quatre bites powaaaa !
Posté par B16F4RV4RD1N . Évalué à 2.
Par contre le 64 bits, j'ai eu vite fait de le remplacer par autre chose chez moi, vu tous les autres soucis que j'ai pu avoir avec. Par "honnêteté intellectuelle" ou plutôt par goût de l'aventure, j'ai quand même installé un Debian 64 sur l'ordinateur à mon travail, vu que je n'utilise la plupart du temps que OpenOffice, Putty et Evolution. Et bien j'ai pu constater que java ne fonctionne pas dans les navigateurs, bon, vu que je n'en ai pas énormément l'utilité cela ne me pénalise pas trop mais quand même. Alors oui le 64 bits c'est le futur, mais pour l'utilisation que j'en ai, pour le moment c'est sans moi.
D'ici 4-5 ans peut-être, quand la plupart du parc informatique sera dessus...
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: soixante-quatre bites powaaaa !
Posté par IsNotGood . Évalué à 1.
Marche ici (et en mode 64 bits). Firefox est installé en 32 et 64 bits. Par défaut c'est la version 64 bits qui est utilisée.
NB : Fedora utilise IcedTea (un fork temporaire de OpenJDK) qui marche en 64 bits. Eclipse marche aussi très bien (comme la version i386). Ce n'est pas parfait (l'aide ne marche pas, comme i386), mais ça le fait. Disons que Azureus avec IcedTea marche aussi mal sous x86_64 que sous i386 (mais dans une poignée de semaines/mois ça va le faire).
NB: IcedTea pour ppc64 vient d'être terminé. Il sera pour F9 (peut-être en mise à jour de F8 mais j'en doute).
> D'ici 4-5 ans peut-être
A part flash (que je n'ai toujours pas installé d'ailleurs...), il n'y a pas de soucis. C'est la seule régression que j'ai. Regression facilement contournable si on lance firefox en 32 bits. Chose que je n'ai pas encore fait, mais ça doit probablement passer par "setarch i386 ...". /usr/bin/firefox a un "MOZ_ARCH=$(uname -m)". Tout le reste marche à l'identique (aussi bien ou aussi mal, c'est selon).
> quand la plupart du parc informatique sera dessus...
On sait déjà qu'on ne peut pas compter sur toi :-)
[^] # Re: soixante-quatre bites powaaaa !
Posté par IsNotGood . Évalué à 1.
Je viens de dire une connerie, l'aide ne marche pas que sous i386, mais marche avec x86_64. Comme quoi....
[^] # Re: soixante-quatre bites powaaaa !
Posté par B16F4RV4RD1N . Évalué à 1.
>> quand la plupart du parc informatique sera dessus...
> On sait déjà qu'on ne peut pas compter sur toi :-)
non je voulais dire quand les machines seront toutes en 64 bits (et pas forcément les systèmes), on aura sans doute moins de pb qu'actuellement, qui est encore dans une une période de transition. Mon ordinateur est déjà en 64 bits.
Après, pour l'utilisation que j'en ai, le 64 bits ne m'apporte rien (pas la peine de me parler de l'encodage de vidéos, je n'en encode pas)
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: soixante-quatre bites powaaaa !
Posté par BAud (site web personnel) . Évalué à 2.
tous, non (par exemple la saleté dans le webmail de Lotus Domino) mais quelques-uns quand même, cf. par exemple http://cookerspot.tuxfamily.org/wikka.php?wakka=Verification(...) (toutes les URL fonctionnent pour moi)
[^] # Re: soixante-quatre bites powaaaa !
Posté par IsNotGood . Évalué à 1.
Idem et sur/en x86_64 (histoire de revenir au sujet du journal).
Beaucoup d'applet et des très compliqués marchent.
Il y en a beaucoup beaucoup plus d'applets qui marchent que d'applets qui ne marchent pas.
# pourquoi t'as acheté une nvidia ?
Posté par djibb (site web personnel) . Évalué à 1.
Mais pourquoi as-tu vendu ton âme au diable ???????????????
[^] # Re: pourquoi t'as acheté une nvidia ?
Posté par BAud (site web personnel) . Évalué à 2.
[^] # Re: pourquoi t'as acheté une nvidia ?
Posté par IsNotGood . Évalué à 1.
Quelle année ?
J'ai joué (et beaucoup) à FightGear sur mon ancien PC qui n'avait qu'une Matrox G400 (32 Mo). Certes, j'ai désactivé des options, mais ça restait "super". Donc une Intel GMA3100 doit très certainement le faire les doigts dans le nez. Je préfère une ATI juste pour avoir de la concurrence. Ça serait un drame si AMD coule. Intel aurait alors une position dominante écrasante.
> http://nouveau.freedesktop.org/wiki/Nouveau_Companion_32
Progrès sympa d'un projet sympa et beaucoup plus.
Mais je crois que le driver libre d'ATI va faire des bonds de géants assez rapidement. C'est un atout énorme d'avoir un constructeur qui joue vraiment la carte du libre.
[^] # Re: pourquoi t'as acheté une nvidia ?
Posté par IsNotGood . Évalué à 1.
Donc j'ai subi. Avec grand plaisir vu la qualité du matos. Il y a même un petit caloduc qui serpente dans la carte mère et le cpu pour la dissipation thermique. C'est mignon et diablement efficace. Il va de soit qu'un overclocking est le bienvenu dans ce contexte...
> Mais pourquoi as-tu vendu ton âme au diable ?
Il faut que je me documente, et dans quelques semaines, je vais probablement passer à ATI.
> l'excellent chipset GMA3100 d'intel
Si on le trouve non intégré à une carte mère, c'est aussi une possibilité.
[^] # Re: pourquoi t'as acheté une nvidia ?
Posté par djibb (site web personnel) . Évalué à 1.
malheureusement...non. Pas à ma connaissance.
pour la petite histoire avec le GMA3100:
google earth OK
tous les FPS auxquels je joue (basé sur Q3) : Wop, nexuiz, urbanTerror :
-> 100 fps.
[^] # Re: pourquoi t'as acheté une nvidia ?
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Par contre je suis étonné de tes 100 FPS sur Nexuiz qui est super gourmand. Tu met quoi comme option ?
Même moi avec ma geforce 6600 256Mo je ne met pas à fond les particules et j'évite trop d'effets "hype", je ne peux pas tous les activer en même temps même si c'est déjà pas mal.
J'ai un frère qui a une Intel (je ne sais pas laquelle par contre, je crois que c'était la dernière à Noël l'année dernière), les dérivés ioQuake3 (Tremulous, UrT) tournent à 100% des options, mais Nexuiz faut brider assez sérieusement !
Nexuiz 100fps... Nexuiz je le fais tourner sur une geforce4 PCI aussi... mais dans ce cas les explosions c'est des sprites 2D.
Je tolère l'absence de certains ombrages dynamiques, le gloom et autres bouffeurs de CG, mais je considère que Nexuiz tourne s'il y a les particules (même si pas à fond) et les deux premiers effets de lumières/ombres dans la liste des options (je n'ai plus la description en tête).
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: pourquoi t'as acheté une nvidia ?
Posté par nigaiden . Évalué à 1.
Tu devrais attendre un peu avant de changer ta carte graphique. J'ai l'impression (ce n'est qu'une impression, sans recherche derrière) que quand on arrive à se demander s'il vaut mieux du nVidia ou du ATI sous Linux, la balance penche en faveur du premier ; pour l'instant le pas qu'a fait AMD/ATI en direction du libre s'est traduit par de la documentation, il faudra patienter avant que cela ne donne des drivers utilisables.
[^] # Re: pourquoi t'as acheté une nvidia ?
Posté par IsNotGood . Évalué à 1.
Pas seulement.
[admin@one ~]$ yum info xorg-x11-drv-radeonhd
Available Packages
Name : xorg-x11-drv-radeonhd
Arch : x86_64
Version: 1.0.0
Release: 0.4.20071219git.fc8
Size : 174 k
Repo : updates-testing
Summary: Xorg X11 radeonhd driver for AMD GPG r5xx/r6xx Chipsets
Description:
X.org X11 radeonhd driver for AMD GPG r5xx/r6xx Chipsets.
This package is a snapshot of a work in progress. You may experience
regressions, bugs, errors, broken displays, and other undesirable phenomena.
radeonhd mailing list: http://lists.opensuse.org/radeonhd/
Built from git commit: 861debbf8d649ce09d53d5880f819757ac9c7814
> il faudra patienter
Quelques signes d'encouragement ne peuvent pas faire de mal.
Enfin je suis persuadé que ça va évoluer plus vite que le projet nouveau.
Il y a deux (et plus) façons de comparer NVidia et ATI.
Si tu te fous du libre, NVidia est peut-être meilleur.
Si le libre est une priorité importante, ATI est gagnant sans l'ombre d'un doute.
[^] # Re: pourquoi t'as acheté une nvidia ?
Posté par khivapia . Évalué à 2.
en même temps s'il conserve son nouveau PC aussi longtemps que l'ancien ;-)
et sinon prendre une ATI, chacun à son niveau, ne peut être qu'une bonne nouvelle pour AMD qui en a bien besoin.
# AMD vs. Intel
Posté par aae . Évalué à 1.
Malheureusement pour AMD, il n'arrive toujours pas(¹) semble-t'il à battre le terriblement efficace core2duo (chauffant peu, facilement overclockable.
(¹) cf. les différents comparatifs sur le net..
[^] # Re: AMD vs. Intel
Posté par IsNotGood . Évalué à 1.
Mouaif...
Pour les quadri coeur, c'est grosso-modo la même chose. Le seul truc est qu'Intel est plus rapide (conséquence d'une fréquence plus élevée). A prix équivalent, les performance sont équivalentes.
Tu peux te payer l'Intel le plus cher ? Tu en as absolument besoin ? Quel conséquence pour toi si tu passes à un AMD certes moins performant (15 à 20% en gros) mais aussi beaucoup moins cher ?
Si Intel a un monopole (comprendre si AMD meurt), le prix des cpu sera plus élevé.
A une époque pas lointaine, c'est Intel qui était en difficulté (difficultés financières et techniques). Aujourd'hui c'est l'inverse. On serait très stupide de refuser de donner une sérieuse chance à AMD (d'autant plus qu'AMD a toujours été très ouvert au libre). Si Intel a un monopole (même s'il l'a acquis de façon loyal) ça ne sera pas cool.
[^] # Re: AMD vs. Intel
Posté par benja . Évalué à 1.
C'est justement dans l'intérêt d'Intel qu'AMD survive, étant donné la lourde menace de procès anti-thrust qui pèse sur eux (dixit une employée de chez Intel).
[^] # Re: AMD vs. Intel
Posté par IsNotGood . Évalué à 1.
Je n'y crois pas deux secondes.
Les anti-trust c'est pour abus de position dominante. Intel n'a qu'à pas abuser de sa position dominante (en gros Intel doit être moins con que MS, ce qui ne devrait pas être dure).
Faut pas enterrer AMD trop vite. AMD a un poil de retard sur Intel. Ses cpu restent excellents. Malheureusement il n'y a pas d'offre à haute fréquence car AMD n'a pas la technologie de fabrication. Mais au niveau conception AMD n'est pas du tout largué !
Si AMD est en sérieuse difficulté, il est probable qu'IBM lui donne un coup de main.
AMD a aussi l'atout d'avoir aussi une bonne expertise en carte graphique (ATI). A moyen terme AMD proposera des CPU avec GPU. Le gain en prix sera important. Des gains en performance sont aussi possibles (meilleur transfert entre la partie graphique et la mémoire centrale). La possibilité que le GPU utilise directement la mémoire centrale n'est pas écraté non plus (mais il y a des problèmes techniques). Ça réduirait les coûts de façon énorme tout en gardant de belle performance. AMD a des atouts pour faire du haut de gamme (pour les gamers) et du bas de gamme (PC en entreprise à prix serré) ou pour les portables (dimensions faibles, énergie).
[^] # Re: AMD vs. Intel
Posté par benja . Évalué à 1.
Je n'ai pas dit qu'AMD était en difficulté, je n'en sais rien et j'ai d'autres choses à faire que suivre la santé économique des multinationnales. Cependant, il me semble qu'AMD est passsé par une période assez morose et qu'Intel a toujours maintenu ses prix au dessus d'AMD alors qu'ils auraient pu les couler facilement.
En ce qui concerme IBM, je suppose que c'est, encore ;-), une pure spéculation de ta part. Personnelement, je ne vois pas pourquoi IBM aiderait un de ses concurrent mais je suis currieux de savoir ce qui peut te faire penser cela.
En ce qui concerne le merge amd-ati, je ne m'exciterai pas trop vite. Des annonces de la part d'Ati (maintenant amd) cela fait un bon moment qu'on les subi. Pour en revenir à Intel, ils font eux aussi des GPU intégrés et dans ce domaine, ils ont une longueure d'avance sur AMD. Certes, ils ne visent pas le marché des hardcore gamers mais je ne pense pas que ce marché est le plus rentable.
Pour finir, je suis de tout coeur avec toi dans cette bataille contre les monopoles. Mon dernier cpu acheté était un ppc, celui d'avant un k6 et je n'ai fais que conseiller des amd à mes connaissances.
[^] # Re: AMD vs. Intel
Posté par imalip . Évalué à 2.
Des choses comme ca ?
http://www-03.ibm.com/press/us/en/pressrelease/22858.wss
Ca fait des annees qu'AMD achete une bonne partie de ses technos semi-conducteur a IBM, en particulier ce qui concerne la finesse de gravure, SOI, etc...
[^] # Re: AMD vs. Intel
Posté par briaeros007 . Évalué à 2.
Dernièrement (comprendre y'a deux jours) j'ai voulu voir grosso modo le prix d'une "bête" de course.
Donc je veux
8 ports sata , 2 gigabits, 4 Go de ram, 1 8600gts(~100-150€), un boitier cooler master elite (~30€)et une alime seasonic(~120€)... et un quad core.
(C'est ce que je veux, inutile de me dire "ca sert à rien!")
phenom 9500, avec 4 Go de DDR2 PC8000 : ~700€
q6600, avec 4 Go de DDR2 pc6400, et une cm qui fait soit 2 gigabits, soit 8 sata, mais pas les 2 (sinon elle part dans les 240€) : ~760€
(pc6400 car la plateforme choisis supportait que la DDR2 en PC6400. Peut etre avec une plateforme avec DDR3, mais 4 Go en DDR3 == +500€)
Presque 10% d'augmentation pour un pc avec moins d'e/s (et soit disant 10% de puissance brute en moins... sachant ce que peut entrainer une mémoire moins rapide itou...).
(ps le q6700 est à + de 400€ et un penryn à + de 900€)
Sans compter ce qui me fait marrer avec les fanboyss d'intel, c'est qu'ils nous disent "ouais amd c'est trop de la merde : ils sont pas en 42nm"... Le seul proc grand public en 42 nm c'est le QX 9650 à +900€. Faut arrêter de déconner. Si on compare avec un QX, moi je prend un barcelona sur une cm multiproc!
Par contre, là ou AMD a BIEN looser, c'est avec le bug du TLB. (petit rappel, les phenom actuel, révisions B2, ont un bug dans la gestion du cache L3, qui peut conduire à des plantage.) AMD a décider de sortir un microcode pour les bios qui supprime cette partie ... et entraine une baisse de perf de ~10% :(
AMD ne souhaite pas modifier ce fix, et déconseille fortement aux fabricants de laisser le choix de désactiver ce fix au client dans le bios. Il faut que le client passe par l'outil adhoc d'AMD.
Berk !!!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.