Il s'agirait alors, comme pour le Hammer, d'un x86 avec des registres étendus sur 64 Bits.
Le premier avantage est que tout le code existant tourne sans modification à une vitesse standard.
Le second est qu'il est plus facile à programmer. Pour utiliser le mode 64 Bits, il suffit d'utiliser les instructions étendues 64bits. (Rappelons que l'Itanium traite 4 paquets d'instructions parallèlement, d'où une certaine complexité pour un homme normalement constitué).
Le troisième avantage est que le prix du processeur ne devrait plus être de 200.000 FF, mais tourner autour de celui d'un processeur haut de gamme actuel.
Du coup, le PDG d'AMD déclare que l'arrivée de ce processeur constitue " sa plus grande peur ".
Aller plus loin
- Zdnet.fr (2 clics)
# Itanium
Posté par Le_GnoU . Évalué à 10.
L' itanium est peut etre une grosse daube, mais il offrait a long terme une alternative au x86, qui est, je le rapelle, le processeur le plus archaique(heritage du 4004) et le plus merdique au monde.
Viva la revolucion Fcpu...
[^] # Sauf que...
Posté par TSelek . Évalué à 9.
Arf, comme si Intel et AMD étaient les premiers à faire du 64 bits et que les autres n'avaient rien sorti d'excellent... Laisse-moi deviner, tu utilises du PowerPC, de l'ultrasparc ou de l'alpha ?
Franchement, c'etait pas la peine de s'appeller GnoU pour s'appitoyer sur la moitié du tandem wintel.
[^] # Re: Itanium
Posté par koopa . Évalué à 10.
À mon avis de tous les trucs archaïques du PC (IRQ, mode réel, bus ISA ...) c'est le processeur x86 qui durera le plus longtemps, et je ne vois pas pourquoi la suprématie du x86 ne durerait pas encore 10 ans.
[^] # Re: Itanium
Posté par Jak . Évalué à 10.
Si la compatibilité x86 est aujourd'hui difficile à contourner, c'est désormais essentiellement à cause du monopole de Microsoft sur le marché du logiciel. Intel était le seul à pouvoir essayer de changer ça, mais la démarche d'AMD me semblait la plus judicieuse, car quoique qu'il en soit, AMD n'aurait jamais pu imposer une nouvelle architecture, contrairement à Intel, enfin, c'est ce que je pensais.
Si même Intel ne parvient pas à mettre au placard le x86, alors en effet, on en a encore pour 10 ans.
Mais sincèrement, si une station Alpha ou Sparc était moins chère qu'une station x86, je ne me poserais pas la question de savoir quoi choisir : la logithèque sur ces machines est, grâce aux Logiciels Libres, largement assez fournie pour la plupart des utilisateurs.
[^] # Re: Itanium
Posté par Euclide (site web personnel) . Évalué à 2.
Monopole qui existe grace au pc et donc au x86.
Ca se mord la queue cette histoire.
Le x86 est une archi qui a marché car elle est plutot ouverte.
Ton alpha tu ne pouvais le mettre quand dans une machine vendu par DEC, avec un OS DEC, un clavier DEC, une carte graphique vendue par DEC, de la RAM certifiée DEC....
on peut remplacer DEC par Apple ou par d'autres.
Un x86 tu as très vite eu le choix de l'OS, du fondeur du proc, du fondeur de la carte video, du fabriquant de carte mère et j'en passe. Certains fournisseurs sont en position de monopole, mais jamais completement a 100%.
C'est la seule archi de ce type que je sache.
Elle a permis a bon nombre d'acteurs de se lancer sur le marché. Ca a créé de la concurence et donc une baisse des prix.
Bref c'est la plus ouvertes des architures.
C'est un peu en train de changer (l'athlon est le premier processeur AMD a ne pas tourner sur les cartes mères pour proc intel)
L'itanium est tout aussi incompatible avec le Hammer.
[^] # Re: Itanium
Posté par Alberto . Évalué à 10.
D'autre part, ce jeu d'instruction pourrait etre integrer dans le prochain core de type pentium4 !
Ce qui signifierait que le prix de ce type de processeur devrait etre rapidement faible.
L'itanium pour sa part est un VLIW (very long instruction word) ce qui pose encore de nombreux problemes au niveau des compilateurs. Bref l'itanium c'est pas encore pour tout de suite et aujourdhui mieux vaut se rabattre sur un 64bits classiques qui a fait ses preuves...
[^] # Re: Itanium
Posté par Ho_Kurios . Évalué à 4.
Tu peux trouver dessus un émulateur x86 (em86 sous linux et fx32 sous windows) qui marche assez bien. Mais sous linux il ne sert pas a grand chose puisqu il y a des distributions. Bref c'est une bonne alternative enfin s etait avant le rachat par Con paq.
[^] # Re: Itanium
Posté par PLuG . Évalué à 5.
Le probleme de l'alpha c'est la politique commerciale de DEC a l'epoque de sa sortie.
En gros ils ont dit a leur client de migrer sur plateforme alpha car ils arretaient net la maintenance de leur gamme de produit precedente.
Les clients en ont eu gros sur la patate et ont certes migré (forcé!) mais pas avec le meme constructeur.
Résultat: le processeur alpha, qui est encore une merveille n'a pas connu le succès qu'il méritait.
[^] # Problème de l'Alpha
Posté par Serge Rossi (site web personnel) . Évalué à 8.
Dec avait une très forte base installée de serveurs et stations Vax sous VMS à l'époque.
(Euclid était un soft de CAO majeur à l'époque et tournait essentiellement sous VMS).
La présentation a été très mal faite puisqu'il ont dit que Dec ne supporterait plus le processeur Vax (32 bits), qu'il fallait recoder tout en 64 bits et que non, y'avait pas moyen de faire tourner les anciennes applis sur les nouvelles machines.
("léger" remue-ménage dans la salle des heureux clients VMS plus si heureux du coup !)
Donc en gros, tous les clients (nous) se sont dit : tant qu'a faire de changer, on va regarder ce qu'il y a de beau sur le marché.
Comme les stations et serveurs Sun et SGI étaient déjà là et avec un catalogue logiciel important, alors qu'il n'y avait pas grand chose sur Alpha VMS ou Alpha Unix (Ultrix ? DecUnix ? OSF/1 ? Je ne sais plus quel était son nom en 1992) ben en gros, beaucoup sont passés sur Sun ou SGI.
De profundis Digital !
[^] # Alpha chez Compaq?
Posté par Jean-Pierre Schwickerath (site web personnel) . Évalué à 7.
[^] # Re: Alpha chez Compaq?
Posté par darkleon (site web personnel) . Évalué à 7.
2-Ils ont aussi récupérer les ingénieurs de Dec, mais l'architecture des 2 processeurs doit être trés différente, donc ce ne doit pas être simple voir plus compliqué de "plaquer" les optimisations de l'alpha sur l'itanium. Donc l'expérience doit leur servir, mais ça n'améliorera pas radicalement les performances de l'itanium.
[^] # Re: Alpha chez Compaq?
Posté par darkleon (site web personnel) . Évalué à 5.
# FRF vs EUR
Posté par Olivier . Évalué à 10.
200000 FRF ~ 30000 EUR (30489.80 EUR pour les puristes)
Hop, -1
[^] # La démocratie, c'est "Cause toujours !" ;-)))
Posté par adolphos . Évalué à 3.
# ZDNet, fiable ou pas?
Posté par Kevin JULIEN . Évalué à 10.
Regardez là:
http://www.hardware.fr/news/lire/26-01-2002/#4454(...(...))
http://www.theinquirer.net/25010201.htm(...(...))
# battage
Posté par kesako . Évalué à 10.
Les journaleux n'avaient vraiment pas de en manque de superlatifs !
Tout ca pour accoucher d'une souris...
Et pendant ce temps j'attend toujours un proc tres basse conso qui puisse fonctionner plus de 24h avec une seule batterie.
allez -1
[^] # Re: battage
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Ou encore tu prends un proc ARM mais il ne faut pas s'attendre au même perf...
"La première sécurité est la liberté"
[^] # Re: battage
Posté par Le_GnoU . Évalué à 1.
Les proc arm sont tres performants, tres legers en terme de transistors) et tres economes.
Intel fabrique du StongARM pour des pda et autres merdouilles, et j' ai entendu dire qu' ils limiteraient la frequence de ces proc (500 MHz Max.) pour ne pas ridiculiser leurs x86 en termes de performance.
# Compile ton C !
Posté par Bruno Stévant . Évalué à 10.
Hum j'aimerais savoir si cette personne a deja entendu parler d'une technologie, pourtant assez eculee, qui justement evite au programmeur moyen d'avoir a "utiliser des instructions" comme de penser aux pipelines d'executions : la compilation !!!
C'est certain, un proc compatible 32/64, ca permet de faire tourner les applis deja compilees, mais ca ne facilite pas la programmation. Connaissant Intel, les instructions 32 et 64 bits ne pourront pas etre mixees, ou alors sous peine d'un changement de mode dont Intel a le secret (donc overhead, raz de registres, etc ...)
P'tet qu'un n-ieme hack dans le code de gcc va quand meme permettre d'utiliser efficacement ce proc hybride (car on n'etend pas gcc, on le *hacke*)
--
Taliesin - Barde
[^] # Re: Compile ton C !
Posté par Jak . Évalué à 10.
Car afin d'économiser de la place sur des unités annexes dans le silicium, certaines opérations sont sensées être faites par le compilo plutôt que par une unité de traitement du processeur, comme par exemple la prédiction de branchement (je ne me souviens plus bien de l'article, mais l'idée était de faire faire certaines opérations d'ordonnancement des instructions par le compilo plutôt que par le processeur comme sur un processeur classique qui s'arrange avec le code : Exécution dans le désordre (OOO), prédiction de branchement ... , ceci afin de ne pas perdre de place pour les unités de calcul).
Ce à quoi se heurte Intel est la difficulté de mettre en place cela. Sur le papier, c'est génial (comme l'ancienne VM du noyau Linux), mais en pratique, c'est difficile à implémenter et ça ne marche pas comme on le souhaite.
[^] # Re: Compile ton C !
Posté par kalahann . Évalué à 10.
Malheureusement, vu combien de temps il faut pour écrire un compilateur qui produise du code stable et optimisé, je sais pas combien de temps il faudra pour en écrire un qui, en plus, devra traiter le parallélisme des instructions et toutes les autres "nouveautés" d'HP et intel...
[^] # Youpla!
Posté par Jak . Évalué à 10.
C'est ce qui fait que sur la papier, c'est très performant, car les conditions sont calculées à l'avance (en gros, car ce n'est pas aussi simple). Je crois me rappeler que le code assembleur était annoté par le compilateur afin justement de profiter du parallélisme quand c'était possible.
Par exemple, les DSP Texas Instrument de la série 320C6xxx (6201, 6701...) étaient déjà des processeurs VLIW, capables en théorie (j'ai un peu vu le 6201) d'exécuter 8 instructions par cycle d'horloge. Le code ressemblait à ça
mov reg1 reg2
|| add reg3 0x10
|| sub reg1 reg4
add reg4 reg2
...
Les '||' indiquaient que l'instruction de cette ligne était exécutée en parallèle avec l'instruction de la ligne précédente. Il possédait 2 chemins de données (DataPath) et 4 unités d'exécution par chemin de données (2 UAL, 1 pour les sauts et encore une autre, mais je ne me souviens plus exactement), donc, en théorie, on pouvait exéduter 8 instructions à la fois, mais encore fallait-il que les instructions soient bien ordonnées pour pouvoir utiliser les 8 unités à la fois, et sans dépendances de résultat. Car des instructions arithmétiques ne peuvent par exemple être traitées que 4 par 4 (et pas 8 par 8).
Pour l'Itanium, il me semble que c'est encore plus évolué au niveau des annotations dans l'assembleur, justement pour faire faire la parallélisation par le compilo et pas par le programmeur. Mais c'est loin d'être évident, l'Itanium nous le prouve.
[^] # Re: Compile ton C !
Posté par Bruno Stévant . Évalué à 6.
C'est clair ...
Pour l'instant, gcc (et consorts lcc ...) compile tres bien pour les archis std du desktop (IA32, sparc, ppc, etc ...) car architectures bien connues, optimisations pas trop mechantes, etc ...
Mais des qu'on attaque des choses un peu plus pointues (hautes perfs, parallelisme, proc embarques), la les compilos savent plus faire. Est-ce la faute aux designers hardware ?
A mon avis, la decision d'Intel est plutot motivee par un manque de savoir-faire des developpeurs de compilateurs, et non par reniement des nouvelles technologies processeurs. Car ces "features" (prediction de branchements, VLIW) ne se retrouvent pas seulement dans les proc "high-end" mais aussi dans l'embarque (appareil-photos, pda, etc ...). Va donc falloir que des gens se motivent a faire evoluer la discipline du compilateur.
--
Taliesin
[^] # Re: Compile ton C !
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Le but est que cela aille vite. Un processeur cela coute, un programme compilé ne coute qu'une fois lors de sa création et une puce coute à chaque pièce. Voila la différence.
Car ces "features" (prediction de branchements, VLIW) ne se retrouvent pas seulement dans les proc "high-end" mais aussi dans l'embarque (appareil-photos, pda, etc ...).
Pas tant que ça justement. Le VLIW se retrouve dans les DSP TI. Mais pour un DSP c'est une démarche facile : les fonctions de base sont écrites à la main.
Quand au reste ? Peut-être dans les ST50/SH5 mais ce n'est pas des bidules courant.
Et franchment les problèmes de compilation VLIW sont assez nouveau, contrairement à ce que tu sembles dire.
"La première sécurité est la liberté"
[^] # Re: Compile ton C !
Posté par Bruno Stévant . Évalué à -2.
Bien sur, je trouve juste dommage que les compilos GNU aient tant de mal a apprehender cette technologie.
--
Taliesin
PS: Remarquez, ca fait un concurrent de moins pour ma boite.
PPS: Remarquez, j'me casse dans un mois ;)
[^] # Re: Compile ton C !
Posté par PLuG . Évalué à 4.
Facile pour toi. Tu prends un compilateur, docn tu comptes sur les autres pour gerer la compléxité !
Crois tu que ceux sur lesquels tu t'appuies ne sont pas des hommes normalement constitués ?
Un processeur compliqué cela veut dire des difficultées à intégrer son support dans gcc, donc des versions de gcc qui produise du code buggé pendant longtemps.
Enfin les developpeurs du noyau linux ne travaillent pas en assembleur il est vrai (tres peu d'asm dans le code), mais maitrisent le code assembleur généré par gcc et produisent du code C adapté a ce qu'ils veulent obtenir en asm en sortie. Avec un processeur compliqué cela promet des belles nuits de débuggage.
Cela ne veut pas dire que Itanium n'est pas bien, mais que ton raisonnement me parait un peu "facile".
Regardes une nouvelle fois le support x86 de gcc qui n'est pas bon du tout pour les processeurs recents comparé au compilateur Intel pour linux (a telecharger ici: http://www.intel.com/software/products/compilers/c50/linux/index.ht(...)) ) et imagine le boulot ...
[^] # Re: Compile ton C !
Posté par Bruno Stévant . Évalué à 10.
He bien oui, figure toi que je travaille dans une boite qui donne dans le compilateur. Et gcc est notre sujet de plaisanteries de bureau favori =)
Plus serieusement, les difficultes a recibler gcc vers une nouvelle architectures proviennent moins de la complexite des heuristiques que la difficulte a les integrer a gcc.
Techniquement, gcc prefere se fier au generateur de code pour effectuer la majeur partie de ces optimisations. Donc trop bas niveau, donc plus difficile.
Il existe une litterature assez fournie dans le domaine de la compilation, ou justement les techniques de compilations pour pipelines evolues sont largement traitees. Les references sont le Muchnick ("Advanced Compiler Design and Implementation") et Grune ("Modern compiler design") ...
--
Taliesin
# intel: vivre vite et mourir vieux...
Posté par kael . Évalué à 10.
ils peuvent pas faire comme tout le monde passer d franchement d'un truc 32 a 64bits???
au lieu de ca il ont fait un proc (itanium) dont le debut de la conception le destinait a etre compatible x86 puis pa-risc puis finalement on sait plus, tout ce dont on est sur c'est que ces tentative d'heritage a fait ramer la bete...
Il suffit pourtant de prendre exemple sur apple ou meme mieux sur digital: a l'epoque digital est passe du vax a l'alpha, pour ca il onts utilise un stade intermediaire avec leurs recompilateur de code a la volée (qui servira de base pour fx32! et emu86), et pas de bol ca marche tres bien !!!
l'excuse de la compatibilitée ascendante pour les applis critiques c'est du pipo, y'a qu'a voir il y a encore des vax dans plein de boite : on vas pas s'ammuser a bidouiller si c'est vraiment critique...
pis je parle meme pas de l'heritage hardware du pc...a commencer par le BIOS!!! (bon j'ai dis que j'en parlerai pas...)
--
"what is your user name?"
[^] # intel: vivre vite et mourir vieux...
Posté par kalahann . Évalué à 2.
J'ai une sparc et un ppc à la maison, quasiment tous les programmes sont portés. (le pb c'est plutôt l'installation)
Heureusement pour intel que microsoft impose leurs processeurs en plus de leurs produis.
Vive l'indépendance de l'architecture!
[^] # Re: intel: vivre vite et mourir vieux...
Posté par kael . Évalué à 4.
c'est ca que je reproche a intel c'est de pas simplifier leur materiel grand public, a cause de ca on a du materiel qui coute plus cher car moins simple et qui est plus lent car il necessite de passer par des tonnes de phase d'initialisation inutiles pour le plus part (j'ai dis que je parlerai pas du bios...mais c'est dure!!)
[^] # Re: intel: vivre vite et mourir vieux...
Posté par kalahann . Évalué à 3.
Quand aux sparc, rs/6000 et autres alpha, les constructeurs se plaisent bien dans un marché haut-de-gamme à forte marge. Ils vont pas faire comme intel et AMD et s'engager dans la guerre des prix! Du coup les prix restent haut (contrairement au marché grand public ou les prix DOIVENT être bas)
[^] # Re: intel: vivre vite et mourir vieux...
Posté par darkleon (site web personnel) . Évalué à 8.
De toute manière l'Itanium est réservé pour les gros serveurs, ils pouvaient continuer tranquillement les pentiums en attendant pour le desktop.
Et en plus, s'emmerder a faire du VLIW avec des compilos EPIC pour gagner des transistors (intention louable, permet d'avoir plus de cache ou moins de chaleur), puis en reperdre 3 fois plus pour garder la compatibilité x86, c'est du nimportnawak.
C'est encore un coup du marketing ça, surtout ne pas affoler le client, qui poura repartir avec ses applis x86.
Résultat, 3 ans de retard pour une bouse qui ne marche pas et finallement, qu'est qu'il va se passer, on le sent bien, l'ItaniumIII n'aura plus de compatibilité x86 hardware pour le "booster" au max et il y aura une gamme pentium64bits pour la compatibilité desktop.
C'est bien d'être compatible, mais quand on renouvelle un parc de serveur, c'est moins critique, car en général il n'y a que quelques applis dessus, si il y a une version native pour itanium, on s'en fout des applis x86, c'est pas fait pour jouer à quakeIII, solitaire, démineur, etc...
Encore que je ne serais pas surpris si QuakeIV sera l'appli qui tirera le maximum de l'Itanium :-)
[^] # Re: intel: vivre vite et mourir vieux...
Posté par Jean-Noël Avila . Évalué à 8.
* Pour obtenir des volumes de production appréciables, il faut tomber dans le grand public (c'est plus du tout le même volume que pour les serveurs), avec ses cohortes de logiciels 32 bit et toute une éducation à refaire...
* Corollaire du premier point, on ne se lance pas dans une entreprise aussi risquée (avec les capitaux qui sont en adéquation) si on n'a pas une bonne estimation de réussite. La bonne estimation de réussite c'est le passage par le grand public (c'est la base d'Intel et d'AMD).
Au fait, les derniers P4 sont encore compatibles 16 bits ? :o)
[^] # Re: intel: vivre vite et mourir vieux...
Posté par kael . Évalué à 4.
ben essai de faire touner dos 5 et win 3.1 et tu vera ca marche :)
en fait le au demarage du pc le processeur est en mode compatible 8086 et apres les systèmes d'exploitation les mettent en mode protegè et tout ce qui s'ensuit...
ce qui est formidable c'est que les vieux systeme ne peut quasiment pas fonctioner a cause des evolutions (controleur disques etc..) mais on reste tout de meme compatible au niveau du proc, c'est vraiment TRES utile
[^] # Re: intel: vivre vite et mourir vieux...
Posté par darkleon (site web personnel) . Évalué à 7.
Certes, mais Intel n'a jamais caché que l'Itanium serait réservé aux serveurs pendant quelques années avec des processeurs à 5000 euros piéce pour avoir une trés trés grosse marge.
Ils voulaient avoir une adoption progressive // par le grand public par le biais de la compatibilité x86, mais comme elle est carrément pourrie, ça ne pouvait pas marcher, les plus gros acheteurs de matériels performant sont les gros joueurs, et ils ne vont pas acheter un processeur qui tourne 8 fois moins vite en émulation (Itanium 800mhz avec des perfs équivalentes au P100).
Quand au 2éme point, c'est le reproche que l'on peut faire à Intel justement, c'est d'avoir pris une décision "cul entre 2 chaises".
Soit ils étendaient le x86 comme l'a proposé AMD (et c'est ce qu'ils vont peut être faire) risques minimum dans la continuité.
Soit ils sortaient un proc radicallement nouveau bcp plus simple pour qu'il soit moins cher à produire pour ne pas à avoir à supporter le poid de l'existant, risques maximum, mais un développement plus rapide, possibilité de créer des nouveaux chipsets plus simples et du coup plus performant et moins buggés, et avec des gains maximum en cas de réussite car élimination directe de la concurrence.
En fait, leur tactique aurait pu marcher si l'Itanium était sorti en 1999, quand les fréquences d'horloge étaient inférieure à 800mhz.
Maintenant que le PIV est à 2,2Ghz (3ghz en "overclock") la puissance brute est tellement supérieure à l'Itanium en code natif, que même si tu perds du temps à émuler du 64bit sur du 32bit, ton processeur reste plus rapide et moins cher.
On voit bien que le PIV pourra plus facilement progresser en vitesse d'horloge que l'Itanium, et AMD n'est pas trés loin du PIV.
Bordel on ne va jamais se débarasser de la compatibilité x86, dans 20 ans on va encore se la payer.
[^] # Re: intel: vivre vite et mourir vieux...
Posté par PLuG . Évalué à 7.
a l'époque AMD n'était pas si réputé/fiable/important.
Intel décide de faire un processeur différent, ce qui permet de s'affranchir de l'historique x86 mais oblige tout le monde a porter ses OS/applications.
Cela marchera puisque le x86 n'évoluera plus trop, tout le monde finira par changer de lignée de processeur.
Mais voila qu'AMD propose, lui, de continuer a faire évoluer la lignée x86. Intel n'est plus du tout sur que MS voudra porter windows sur l'Itanium puisqu'il n'y sera pas obligé, pour le grand public c'est plus facile de continuer avec les logiciels déjà acquis ... l'Itanium est promis a un echec cuisant.
Intel retourne donc sa veste et suit la meme stratégie que son concurent, puisqu'elle est plus sure commercialement.
[^] # Re: intel: vivre vite et mourir vieux...
Posté par PLuG . Évalué à 1.
ils sont meme compatibles 8 bits ... x86 quoi !!
mais cela depend du sens que l'on affecte a 64bits.
taille des registres, des bus ?
sur les consoles, ils mesurents les bus (en les cumulant en plus ...).
en général je me base plutot sur les registres, a mon avis plus parlant quoi que le 8088 (équipant les IBM PC a 4,77MHz)etait un faux 16bits car le bus des données etait sur 8 bits, c'est le 8086 qui était un vrai 16bits (équipant les clones a 8MHz ... des bombes !!)
[^] # Re: intel: vivre vite et mourir vieux...
Posté par kesako . Évalué à 6.
Je soupcone que c'est plus simple que ca :
Microsoft a dit a Intel qu'un windows 2000 "full 64 bits" n'etait pas la priorté absolue , que c'est difficile et que ca coute cher. Et pas vraiment en phase avec le marché. Qu'il ne fallait pas s'attendre a le voir arriver avant 2001 au mieux plutot 2002 ou 2003
Donc Intel s'est retrouvé coincé. L'architecture Pentuim est en bout de course, faut la changer. Mais ya pas d'OS valable pour le 64bit . Les plans ont ete fait en 97 ou 98 , a l'epoque linux c'etait zero ( il s'agit de milliard de $ d'investissement !)
Donc ils ont ete obliges de faire ce truc batard 32/64 bits
[^] # Re: intel: vivre vite et mourir vieux...
Posté par darkleon (site web personnel) . Évalué à 3.
Donc c'est une excuse en bois de la part de microsoft, sans faire de win full 64 bits dés le départ, ils auraient pu déjà porter win2k 32bits, puis au cours des années le passer en 64bits, d'autant plus que la partie critique 64 bits sur un serveur, c'est la gestion de la mémoire et des capacités de stockage de grande capacité, hors il me semble que Microsoft gére tout ça au prix d'adaptation du code 32bits faisant du pseudo 64bits.
L'erreur fondamentale d'Intel a été de vouloir garder la compatibilité ascendente, pour continuer dans leur ligne commerciale, mais de faire quelque chose de nouveau quand même.
Pourtant, ils en avaient des exemples de société qui avait cassés leur compatibilité, APPLE, DEC, IBM, SUN et ils sont toujours là.
[^] # Re: intel: vivre vite et mourir vieux...
Posté par VERMEEREN Sebastien . Évalué à 2.
Un truc tres curieux :
- Microsoft change de versions => incompatibilité de format => tout le monde rale
- Intel change de versions => compatibilité ascendante totale => tout le monde rale
Que faut il donc faire ????
[^] # Re: intel: vivre vite et mourir vieux...
Posté par darkleon (site web personnel) . Évalué à 5.
Mon analogie ne marche pas parce que les noms que j'ai cité ont réussi non pas parce qu'ils étaient petits ou gros, mais parce qu'ils font le hard+soft ce que ne fait pas intel
Microsoft change de versions => incompatibilité de format => tout le monde rale
Microsoft change de versions => format compatible ou incompatibilité de format mais bien documenté sans restrictions sur l'écriture de filtres et filtres efficaces fournis => personne rale.
C'est pas le changement de version qui est ennuyeux, c'est le changement du format de fichier, personnellement, je m'en fous un peu de tapper une page html avec notepad, vi, emacs, ... tant que je peux la lire dans 20ans et la remodifier.
D'ailleurs microsoft l'a bien compris, on est obligé de changer les softs pour lire les nouveaux documents pour éviter justement que l'on ai pas d'obligation sur le choix du soft pour l'édition, autrement pourquoi choisir office plutôt qu'une autre suite si ils produisent tous le même résultat au final.
Intel change de versions => compatibilité ascendante totale => tout le monde rale
Parce que ça sert à rien, vu que justement, microsoft change tout le temps leur formats de fichier. Ce qui t'intéresse quand ta machine progresse, ce n'est pas tellement les applis, c'est surtout de pouvoir récupérer tes données.
Est-ce que tu apprécies plus un mp3 avec winamp que xmms, non, est ce que tu apprécie plus l'utilisation de winamp ou de xmms, là la question se pose.
Est ce que xmms ppc ou xmms x86 vont jouer les mp3 différement.
Est-ce que tu peux réellement jouer aux vieux jeux dos sous win sans passer par une émulation?
Personnellement, je suis passé de l'amiga au pc, j'ai récupérer tous mes fichiers de données, je regrette un peu l'amiga, mais une fois que tu as retrouvé des softs qui te plaisent, tu t'en fous un peu de savoir ce que tu as derrière (en dehors de la puissance de traitement).
Evidemment je n'aimrais pas avoir une rupture de compatibilité tous les 2 ans, mais après 20ans de bons et loyaux services, il serait peut être temps de penser à de nouveaux processeurs qui seraient plus petits, moins chauds (plus de ventilation, devenu un rêve utopique) et plus performants. Mais voilà avec cette fameuse compatibilité ascendante qui ne sert à rien, tout à évoluer dans une machine, quid du mode CGA ou Hercules sur une carte graphique de cette année.
Tu t'en fous, j'émule un amiga500 a 60fps sur mon PC, si je veux rejouer à TurricanII, je ne vois pas pourquoi je ne pourrais pas émuler tout efficacement un PC 386 VGA pour rejouer à Prince of Persia par exemple (oui parce qu'à part les jeux, je n'utilise pas de vielles applications, j'utilise celle qui sont plus récente et qui exploitent bcp mieux le matériel). D'autant plus qu'il y a toujours des 386 en vente pour le 0.001% d'applications critiques qui auraient vraiement besoin d'une compatibilité maximum.
Regarde le monde des consoles, elles sont rarement compatibles entre elles, et alors ça n'empeche personne de les acheter et qu'elles soient bien vendu, résultat des machines exploités à pratiquement 100% au bout d'un à deux ans d'existence.
Avec le x86, on a toujours l'impression que la machine est exploitée à une fraction de ses capacités, il y a bcp de puissance pour pas grand chose.
Le x86 est vraiment comme les voitures américaines, gros moteur, mais peu de reprise et avec une consomation gargatuensque ;-)
Je dis ça parce que je commence vraiment à en avoir marre de voir qu'à chaque nouveau processeur la taille de la puce se réduit par 2 et la taille du bloc radiateur/ventillo augmente par 2 alors qu'on pourrait garder une température de chauffe constante (cf PPC, Transmeta, ARM).
[^] # Re: intel: vivre vite et mourir vieux...
Posté par Johann Deneux . Évalué à 3.
Rhhhaaaa (soupir d'envie). Un PC silencieux. En ce moment, je cale le coté gauche de ma tour avec mon pied, sinon le boitier vibre contre le corps de la tour, fixée à la carte mère, fixée à deux immenses PII avec des ventilaux vrombissants.
Bon tout le monde s'en fout sans doute, mais qu'est-ce que ce serait bien, un PC sans ventilo....
[^] # Re: intel: vivre vite et mourir vieux...
Posté par VERMEEREN Sebastien . Évalué à 1.
# a 4 instructions ?
Posté par Zeemax Zeemax . Évalué à 0.
ZeeeeeMax.
[^] # Re: a 4 instructions ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
nicO
"La première sécurité est la liberté"
# 128 bits
Posté par cliklik . Évalué à 1.
Est-ce l'avenir?
Quels sont les problemes techniques pour ne pas faire directement ce genre d'architecture?
A force d'attendre, intel va p'tre sauter une génération.
[^] # Re: 128 bits
Posté par reno . Évalué à 4.
En general le nombre de bit represente la taille du mot entier sur lequel tu peux faire un calcul "en un cycle".
Pour les processeurs 64-bits, l'interet principal est de pouvoir adresser plus de 4 Go de memoire simplement.
C'est tres important pour les serveurs et cela le deviendra probablement bientot pour les clients.
A priori, on n'aura jamais plus de 2 puissance 64 octets de memoire (les exponentielles ca croit vite!!!)..
Donc pas besoin de passer a plus de 64 bits.
Avoir plus de 64 bits pourrait etre utile pour faire des calculs rapidement avec des nombre sur plus de 64 bits
-->tres peu probable, on a tres rarement besoin de nombre si grand ou d'une telle precision en calcul flottant(encore que ... pour certains calculs en sciences).
Un interet pourrait etre pour manipuler rapidement des vecteurs (par exemple MMX).
Mais a part ca..
[^] # Re: 128 bits
Posté par Jak . Évalué à 1.
PASSÉISTE !! :)
Tiens, j'y songe, mais le jeu d'instruction MMX2 (SSE, je crois) utilise des registres 128 bits, il me semble. C'est une forme de processeur 128 bits, finalement. Bon, un peu comme le 386SX qui utilisait des registres 32 bits en interne mais n'utilisait qu'un bus mémoire de 16 bits, contrairement au 386DX qui avait un bus mémoire 32 bits. (enfin, ya une histoire de ce genre, je ne suis plus tout-à-fait sûr).
D'ailleurs, le F-CPU (le processeur libre) est conçu de façon générique pour pouvoir être facilement adaptable en 32, 64, 128 ou 256 bits.
[^] # 128 bits et petits calculs rigolos :-)
Posté par darkleon (site web personnel) . Évalué à 2.
Je m'explique, on prend la boucle
for (i=O; i<2^x; i++) // i est déclaré register
sur un processeur à 1ghz 1 incrementation/cycle ce qui est le cas des alpha, ppc, x86
pour x=32 bits = 4,29 s
pour x=64 bits ~ 585 ans
pour x=128 bits ~ 10^21 ans soit mille milliards de milliards d'année.
<disclaimer>A priori mes calculs sont juste, je ne suis pas responsable de vos migraines si vous ne retrouvez pas les mêmes résultats parce que j'ai oublié un zéro en tappant mes chiffres :-p </disclaimer>
Pétard, moi qui trouvais que mon Athlon 1.2ghz "arrachait" grave, je me rend compte qu'il met 4,29s pour faire une simple boucle, hors l'être humain perd patience au bour de 2s :-)
Conclusion, il me faut un athlon 32bits à 3ghz ou un athlon 64bits à 3x10^9 ghz ;-)
Donc en fait, c'est déjà impossible de faire du calcul exhaustif sur du 64bits, donc je pense même que l'on ne pourrait pouvoir faire que des stockages et additions sur ces registres (pour gérer la mémoire), car même si le circuit logique qui fait une addition ou multiplication est démontré mathématiquement, reste toujours les problèmes d'implémentation dans le monde réel, surtout a la finesse de gravure actuelle.
C'est vrai que moi aussi je me disais 8, 16, 32, 64, 128, 256... c'est la suite logique mais bon ça sert pas à grand chose, on va rester bloqué aux 64 bits.
Par contre il n'est pas dit que les bus de données passent eux à 128bits (voire plus) comme sur les consoles voire 1024bits sur la PS2 entre le framebuffer et la puce 3D, puisque ce ne sont que des liaisons d'échange, et ça permet de palier le manque de rapidité de la mémoire par plus de données échangées en une transaction.
*** evidemment il y a un truc, ils testent bit par bit, donc 64 tests par registre pour 64 bits :-)
Néanmoins ça n'enléve pas les possibilités de bug pour les calculs arithmétiques, puisque des tests exhaustifs sont impossibles.
--------------------
Le message est posté "AS IS", l'auteur ne saurait être responsable de rien du tout et le simple fait de l'avoir lu vous empêche d'être en désaccord avec lui :-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.