[...]"
NdM : j'ai coupé le message, car c'est une recopie d'une news de Clubic.com Clubic.com : "Intel et le 64 bits grand public" Publié le 21/02/2003 par Vincent
Cette news était une recopie avec quelques changements mineurs d'une news publiée sur Clubic. Nous n'acceptons pas ce type de news d'habitude, mais il nous est difficile de tout vérifier. Toutes nos excuses à Clubic.
Message aux rédacteurs de news : rédigez un minimum vos dépêches, évitez à tout prix la recopie, et même fouillez un peu plus loin, pour enrichir la brève, c'est assez facile.
Merci Berretta_Vexee
Aller plus loin
- Site d'Intel (2 clics)
- Site d'Intel (1 clic)
- La news originale sur Clubic (1 clic)
# Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Beretta_Vexee . Évalué à 10.
http://www.clubic.com/n/n7984.html(...)
# Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Nicolas GORALSKI . Évalué à 2.
Le fait qu'il ne souhaite pas faire des processeurs 64 bits ne m'étonne qu'a moitié, ils doivent amortir leur derniers processeurs.
AMD a une maintenant une opportunité de gagné des parts de marché. Mais le soucis restera toujours les logiciels qui ne sont pas à recompiler comme les antivirus pour les serveurs de messagerie. Cela restera du 32 bits malgré la pseudo compatibilité j'attend de voir.
Sinon il y a les futur PowerPC G5 ainsi que les Sparc et HPPA-RISC.
wait and see.
Je me souviendrait toujours du PII porté par un escargot dans la pub Apple.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par jeandubois . Évalué à 10.
Ca ne parait pas important comme ça, mais si c'est le cas, cela empecherait de dire qu'AMD est le premier à proposer un 64Bits grand public, et enleverait une part de "prestige" dont AMD à bien besoin pour contrer Intel, coté grand public justement.
De plus, je vous rappel cette news sur Hardware.fr :
http://www.hardware.fr/html/news/?date=26-01-2002#4454(...)
qui à été suivi d'autres news confirmant le fait que l'architecture 32bits devrait être utilisé jusqu'en 2008, soit jusqu'au fameux p8
http://www.hardware.fr/html/news/?date=04-10-2002#5207(...)
ce qui pourrait confirmé un tel projet.
Encore une pour la route :
http://www.hardware.fr/html/news/?date=15-11-2002#5337(...)
Comme quoi, Intel n'est pas aussi stupide qu'il le laisse penser. Il laisse juste les autres prendre la température du marché.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Sylvain Rampacek (site web personnel) . Évalué à 8.
Tout a fait d'accord !!
Mais à mon avis, aussi bien pour Intel que AMD, le 64 bits pose des gros problèmes :
- au niveau technologique (comment faire le moins cher, le plus performant et compatible avec le 32 bits)
- au niveau commercial (est-ce que ça va plaire au grand public ?)
Car bon, ça fait longtemps que AMD nous promet un 64 bits quand même...
Et oui : http://linuxfr.org/2002/05/13/8232.html(...) , en mai 2002, il était annoncé pour octobre 2002 !!... (on prend les mêmes et on recommence ?)
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Olivier Jeannet . Évalué à 1.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Nicolas GORALSKI . Évalué à 5.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Moby-Dik . Évalué à 4.
Ce n'est pas le problème. Le code 68000 était émulé par le PowerPC. Le 32 bits tourne en natif sur le futur CPU AMD (et il est censé tourner aussi vite que sur un Athlon actuel).
Dans le cas de Linux, le problème sera vite oublié, mais je pense plutôt au logiciel un peu plus propriétaire comme oracle, db2, les antivirus.
C'est une obsession, les antivirus ? :-))
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Olivier Jeannet . Évalué à 0.
Décidément, tu y tiens à ton anti-virus. Dans ton commentaire précédent, je croyais que c'était une taquinerie, vu le peu d'utilité des anti-virus (à part enrichir quelques sociétés qui ne vivent que de ça). Surtout que je ne pense pas qu'un anti-virus soit limité par le CPU.
Je suis souvent sous Windows NT au boulot, et j'ai désactivé l'anti-virus (contrairement à la politique de ma boîte) car il prend de la mémoire et ralentit aussi la machine. Je ne fais aucune manipulation qui me permettrait de récolter un virus (je n'ouvre pas d'exe et je n'ai pas Outlook), et je n'en ai jamais eu.
Par contre, concernant une base de données, la recompiler pour de meilleurs performances me semble beaucoup plus utile et nécessaire.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Nicolas GORALSKI . Évalué à 0.
Travaillant chez un herbergeur et FAI, je me vois mal dire à mes clients : désolé l'antivirus cela ne sert à rien sauf à engraisser les sociétés éditrices. Nimda, klez c'est vrai moi ça m'a fait rire mais pas ceux qui se sont fait infectés.
Soit un antivirus n'est pas limité par la cpu, mais analyse plusieurs centaines de mails par secondes avec les pièces jointes volumineuses on en rediscutera après de ta cpu.
Et non ce n'est pas une obsession les antivirus, mais j'avais proposé à un responsable de passer sur des power pc pour les performances. Car nous manquions cruellement de puissance sur les traitements de mails avec l'antispam et l'antivirus.
L'un des motif de refus fut le manque de binaires natifs. En effet GNU/Linux est disponible sur une quantité d'architecture mais certains logiciels commerciaux disponible pour GNU/Linux ne le sont et seront que pour IA32 du moins pour le moment.
A ceci on peut rajouter aussi dans les softs propriétaires :
- SGBDR : ORACLE, DB2...
- Sauvegarde : Arkeia, TINA
- Serveur Web : websphere, weblogic
Donc à mon avis, le fait d'avoir l'AMD en 64 bits c'est bien mais avoir des binaires optimisés pour cette architecture cela sera au poil. Un cluster de 64 bits ou du SMP donnerait des performances sympathique. Mais avant de s'avancer sur des hypothétique performance j'attend de voir la bête pour me faire une opinion.
En attendant je n'acheterais pas cette architecture si cela ne me sert qu'a faire tourner des softs en 32 bits.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Moby-Dik . Évalué à 1.
L'un des motif de refus fut le manque de binaires natifs.
T'as eu de la chance qu'ils aient refusé, parce qu'un PowerPC se fait torcher par les processeurs IA32 actuels...
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Olivier Jeannet . Évalué à 2.
Tes clients veulent avoir un anti-virus chez leur hébergeur, et pas chez eux sur leurs PC ? Ou au moins ils pourraient mettre cet anti-virus sur la passerelle entre leur réseau interne et le reste du Net. Et je dirais à mes clients qu'en évitant certaines pratiques, on n'a pas de problème de virus. Je sais bien que le client est roi mais rien n'interdit de lui donner des conseils de bon sens, surtout si on lui fait faire des économies.
Cela dit, je ne vois pas en quoi un anti-virus agit contre Nimda vu que Nimda est surtout un vers. Nimda infecte les serveurs Web en les attaquant directement, et génère un gros trafic Web (mes serveurs Linux ont pas mal loggué de tentatives).
Et pour finir, je pense qu'un anti-virus ne sert souvent à rien car ce qui est dangereux ce sont les nouveaux virus, et ceux-là par définition ton anti-virus ne les connaît pas.
Soit un antivirus n'est pas limité par la cpu, mais analyse plusieurs centaines de mails par secondes avec les pièces jointes volumineuses on en rediscutera après de ta cpu.
Dans ce cas, je te l'accorde.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Sylvain Rampacek (site web personnel) . Évalué à 2.
si si...
l'anti-virus sert !
car en fait, nimda utilise effectivement une faille de sécurité (corrigée) de IIS.
mais dès qu'il commence à rentrer sur le serveur, il se met sur le disque dur...
donc l'anti-virus l'analyse (comme tous les fichiers ajouter/modifier) et hop, il le supprime !
(c'est pas du bidon, c'est du vécu)
après, si tu veux le bloquer avant même l'infection, c'est au rôle du firewall de faire ça !
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Serge Rossi (site web personnel) . Évalué à 4.
Donc, si le CPU AMD devenait vraiment disponible sur des machines d'entreprise, je pense que Oracle ne mettrait pas longtemps à apparaitre pour cette plateforme.
A noter que le problème d'AMD en entreprise avec ses gammes actuelles, ça n'est pas tellement un problème de CPU mais plutôt de cartes mères.
Regardez les gammes de serveurs x86 rackables chez Compaq/HP, Dell ou IBM. Vous en voyez beaucoup avec de l'AMD ? Non. On ne trouve quasiment que les cartes mères sur chipset Intel ou Serverworks.
Si AMD ne corrige pas ce problème, les AMD 64 bits ne décolleront pas en entreprise.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par rgill . Évalué à 1.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par doublehp (site web personnel) . Évalué à 1.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Christophe Merlet (site web personnel) . Évalué à 2.
C'est ça que tu cherches http://www.redfoxcenter.org/FTP/RedFox/Divers/pubapple/snail-2.mov(...) (2,3 Mo)
Perso, je préfère celle là :-)))
http://www.redfoxcenter.org/FTP/RedFox/Divers/pubapple/toasted.mov(...) (3,3 Mo)
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par fielog . Évalué à 0.
quand au 64 bit, j' y crois pas encore, lorsqu'on aura plutot une architexture plus sioux (avec des bus et des perifs vraiement performant), , la, on pourrait exploiter les performance du 64 bits .
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par TSelek . Évalué à 0.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par fielog . Évalué à 1.
Je crois que l'histoire c'est que INTEL voulais changer d'architecture mais que MICROSOFT ne voulais pas car trop compliqué à développer dessus.....
J'aime les réflections disant que l'architecture PC c'est de la m...e mais les meme qui font cette réflection l'utilise (je suis dans le meme cas)...
Dites moi pourquoi l'ALPHA est elle morte alors que c'était théoriquement la meilleur du marché à l'époque (RISC 64 bits!!!)..
# Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Fabimaru (site web personnel) . Évalué à 10.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Bruno (site web personnel) . Évalué à 5.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Beretta_Vexee . Évalué à 5.
Ces 2 bourdes ( qui ne sont pas plus grosse que d'autre de la par de personne bien plus eminante en la matiére ) nous sont dut a Bill gate et non a un ingenieur d'Intel.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Fabimaru (site web personnel) . Évalué à 8.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par matiasf . Évalué à -2.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Jean-Pierre Schwickerath (site web personnel) . Évalué à 2.
Je me demande vraiment si Intel se moque de nous ou pas. Les processeurs 64 bits existent depuis près de 10 ans pour les grandes machines. On ne va pas m'expliquer qu'en dix ans où on est passé de maigre 386 au puissant de la mort qui tue la vie P4 on n'a pas été foutu de réduire les coûts de production des 64bits pour le rendre grand public, qui n'est autre chose que "à prix abordable".
Bon c'est vrai que l'Itanium 1 c'était un véritable escargot et qu'ils ont dû vraiment l'améliorer pour qu'un puisse l'utiliser à d'autres fins que de dépense inutilement de l'argent.
Entre nous, avec les logiciels libres, puisqu'on a accès au code source, on se fout un peu de la compatibilité binaire qu'Intel nous revend depuis le i386. Si j'avais besoin d'une platteforme 64 bits, c'est avec plaisir que je tournerais vers sparc ou alpha. Le x86 y'en a vraiment plus besoin.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par matiasf . Évalué à 4.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Maz (site web personnel) . Évalué à 0.
"Passer de 32 à 64 bits, çà bouffe plus de mémoire et plus de place disque."
Tu pourrais préciser s'il te plait ? Parce que là, avec mes connaissances actuelles de l'architecture des PC et de Linux, je ne suis pas d'accord. Mais peut-être ai-je manquer un wagon ?
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Beretta_Vexee . Évalué à 5.
Sur une architecture 32Bits classique le plus petit block mémoire fait 32Bits et que donc sur une architecture 64Bit celui-ci fera 32Bits.
Et que donc un simple int prendra la méme place en mémoire qu'un quad word ( 2 Double ).
Hors rien n'est moin sur vue que c'est un processeur 16/32/64 au quel on aura affaire, le passage du bus de 16 a 32Bit avec le 386DX, n'a pas fait exploser la consomation mémoire, je ne vois pas pourquoi cela serait le cas avec le passage de 32 a 64bit, dans le cas d'un processeur purement 64Bit cela aurait été different.
Pour l'espace disque je comprends pas trop moi méme, mais peut étre par t'il du principe que les cluster seront de 64Bits aussi, ce qui est un peut ridicule vue que sur n'importe quel systéme avec de gros capacité les cluster font déjà souvent plus de 64Bits mais bon ...
Apres pour ce qui dise que le 64Bit est sans interet sortit de l'addressage mémoire qui passe la barre des 4Go, c'est un peut reducteur, la bande passente mémoire va sacrement augmenté et ce méme pour les applications 32bit si le processeur gére bien le tout, de plus le domaine de la video, de la 3D et du multimedia en general font déjà largement usage du MMX et SSE, ce qui prouve bien qu'il y a bien une utilité a des operations sur 64 voir 128bits.
Je pence d'aillieur qu'on peut tout affait rapprocher le x86-64 du MMX et du SSE, tout le monde reniait leur utilisé au debut et maintenant ils sont trés largement addopté, de plus le x86-64 apporte des inovations nettement plus importante que le MMX et SSE
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par matiasf . Évalué à 1.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Beretta_Vexee . Évalué à 2.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par matiasf . Évalué à 1.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Beretta_Vexee . Évalué à 1.
Le fait est que l'Opteron et l'Athon 64, ne sont pas qu'un simple extention du x86 avec un bus et des registres sur 64Bits, mais integres aussi pas mal d'inovation comme le controleur hypertransport qui permet des echanges sur 256Bits.
2) un traitement 64Bits sur un processeur 32Bit prendra toujours 2 fois plus de cycle que sur un processeur 64Bits, que ce soit bien supporté ou pas.
3)Le gros intéret d'os Linux 64 bits, c'est l'adressage mémoire.
Oui mais la on parle de processeur, et l'Opteron et Athlon 64 apporte un peut plus que l'addressage 64Bits, et je pence que GCC ne crachera pas sur quelques registre en plus et un cache plus large et plus rapide.
De plus je suis percuadé qu'il y bon nombre d'applications qui peuvent beneficier d'un traitement sur 64Bit, que ce soit en matiére de graphisme, de video ou de la 3D, ( 3 domaine ou de plus l'assembleur a encore sa place et son mot a dire, des filtres on l'on pourrait traiter 2 pixel a la fois etc etc ...), sans parler des applications qui manipules de grands nombres comme le cryptage ou les calculs scientifiques, ( méme si le gain est pas de l'ordre de 100% il est tout de méme enorme ).
De plus des algos sur 64Bits existe mais faute d'architecture populaire en 64bits ils sont sous exploités, je pence par exemple au Tiger Hash, qui déjà plus rapide que le SHA1 et MD5 sur un cpu 32Bit ecrase tous sur un 64Bits.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par matiasf . Évalué à -1.
Ooops. J'ai pris ça pour la "nouvelle GForce"... des divagations.
> 2) un traitement 64Bits sur un processeur 32Bit prendra toujours 2 fois plus de cycle que sur un processeur 64Bits, que ce soit bien supporté ou pas.
Pour un cpu avec des registres de 32 bits ok. Si tu as des registres de 64 bits c'est différent. Un IA-32 moderne qui bosse sur des 'double float' n'est pas plus lent qu'un cpu dit 64 bits (sinon il y aurait pléthore de bench le montrant). D'ailleur un athlon a un bus de 64 bits et quelques registres de 64 bits.
Je ne dis pas que tu as tord mais je trouve que ce n'est pas évident.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Moby-Dik . Évalué à 0.
Suffit d'utiliser le MMX.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Beretta_Vexee . Évalué à 2.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par doublehp (site web personnel) . Évalué à 1.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Moby-Dik . Évalué à 5.
Le RGB 32 bits, c'est 8 bits par composante plus éventuellement 8 bits pour l'alpha, donc 32 bits en tout (et non 32 bits par composante). C'est à ça que sert le MMX (avec les cosmonautes qui dansent le funk en tapant sur des tambours).
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par rgill . Évalué à 0.
j'en suis encore à 192Mo de mem et 256 de swap sur un PII :))
doucement les amis, je suis d'accord avec Intel là, faut pas se presser. On sera obligé de passer au 64bits uniquement pour la course à la puissance, et ça c'est quand on ne pourra plus ou difficiliement monter en vitesse pure et miniaturisation.
Moi aussi au cpu 64bits ça me botterai juste pour le côté techno ( j'ai toujours rêvé d'avoir un Alpha ou un Sparc à la maison :)),
mais sinon l'utilité est restreinte pour le moment. Je n'ose même pas imaginer ce qu'on peut faire avec un Athlon XP ou un PIV, alors au proc 64bits .... :-/
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par reno . Évalué à 6.
Plus de place --> occupation disque et mémoire supérieure, mais surtout efficacité des caches diminuée.
De plus, si tu utilise des mots sur 64 bits sans que cela soit nécéssaire tu perds en performance aussi car les calculs prenne plus de temps.
Certes si tu besoin de faire des calculs avec des valeur sur 64bit alors la tu gagnes beaucoup, mais a l'heure actuelle le besoin n'est pas énorme.
AMD est malin: dans leur mode 64 bit, ils ajoutent 8 autres registres ce qui peut aider grandement les 80x86 avec leur nombre ridiculement faible de registres autrement le mode 64 bit par lui-meme tant que tu n'as pas plus de 4 Go de RAM, bof!
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par matiasf . Évalué à 0.
Ajoutont à celà les possibles (j'ai pas vérifié) problèmes d'alignement s'il sont fait sur 8 octets contrairement à 4 comme actuellement. Au pire on peut avoir :
char titi ; // 7 octets de perdu
int toto ;
contre :
char titi ; // 3 octets de perdu
long toto ;
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par doublehp (site web personnel) . Évalué à 1.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par matiasf . Évalué à 1.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Olivier Jeannet . Évalué à 5.
Je te rappelle qu'un programme peut être compilé avec uniquement des offsets relatifs sur 32 bits. On peut d'ailleurs imaginer qqch sur le modèle de ce qui faisait sur PC avant (mode NEAR pour < 4 Go et FAR pour > 4 Go).
<i>> et de ne transfere que les bits significatifs !
Ça ne change rien. [...] A moins que le cache ajoute un octet pour indiquer le type.
Originaux tes exemples, j'ai l'impression que tu n'as jamais vu d'assembleur et les modes d'adressage d'un CPU. Tu oublies les modes d'adressages qui précisent la taille des données à transférer. Sur 68000 un "move" peut être écrit "move.b", "move.w" ou "move.l" , correspondant à 8, 16 ou 32 bits. Quand dans ton code C tu manipules des char ou des long, c'est compilé en instructions qui ne transfèrent que les tailles utiles (en l'occurence 8 bits pour char et 32 bits pour long).
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par doublehp (site web personnel) . Évalué à 2.
( meme mieux que moi :o )
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par matiasf . Évalué à -1.
Et sous ms-dos et windows il y a quelques années on pouvais faire du 16 bits en relatif aussi (les fichier .com :-) ).
Si ton programme n'utilise que du relative 32 bits sur un os 64 bits (par exemple) alors tu ne peux pas utiliser de librairie (comme expliqué plus haut). Dans ce cas, je vois pas où il est le gain de place.
> Originaux tes exemples, j'ai l'impression que tu n'as jamais vu d'assembleur et les modes d'adressage d'un CPU.
Tu n'as pas compris le problème. On parlait de cache. La question était de savoir s'il était possible d'économiser le cache en ne copiant que les octets "significatifs". J'ai répondu que non en prenant comme exemple un int de 8 octets. Il est évident que pratiquement tout les cpu savent récupérér 1, 2, 4 ... octets (le z80 le fesait). Quoiqu'il en soit (puisse que l'on parle de cache ! ) je me demande si le cache a ce niveau de "finesse".
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Troy McClure (site web personnel) . Évalué à 2.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par matiasf . Évalué à -2.
Heuuu... C'est quoi la question ?
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par TSelek . Évalué à 2.
je me demande si le cache a ce niveau de "finesse".
La réponse était :
l'unité de base d'un cache, c'est la "ligne de cache", c'est 32 octets sur les x86
Vu que le cache fonctionne en "line" et ne vas pas tagger à l'octet près mais par brouettes entières, tes préoccupations relatives au langage C perdent tout sens dès qu'un cache entre en jeu.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par matiasf . Évalué à -2.
Et même 64 bits sur athlon xp.
> tes préoccupations relatives au langage C
C'est pas mes préoccupations. Relis.
> perdent tout sens dès qu'un cache entre en jeu.
C'est aussi ce que je dis. Relis.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Moby-Dik . Évalué à 0.
Octets. 64 bits, c'est la largeur du bus entre CPU et cache (pas du tout la même chose).
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par matiasf . Évalué à -1.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Olivier Jeannet . Évalué à 1.
Je ne vois pas le rapport entre le fait qu'un OS soit 64 bits, qu'on utilise des adressages relatifs en 16 ou 32 bits, et qu'on ne puisse pas utiliser de librairie. A l'heure actuelle, la librairie C (tu parles bien de ça je suppose) est en 32 bits sous Linux x86, mais ça n'empêche pas d'avoir des programmes qui ne contiendraient que des offset relatifs sur 16 bits. Sur Amiga tu pouvais bien avoir des programmes qui n'utilisaient que des sauts relatifs, alors que l'OS était 32 bits.
La question était de savoir s'il était possible d'économiser le cache en ne copiant que les octets "significatifs". J'ai répondu que non en prenant comme exemple un int de 8 octets.
Tu te poses de drôles de questions. Remarque, si tu utilises un int pour une variable, c'est que tu comptes utiliser un bonne partie des valeurs possibles, tu ne vas pas prendre un int si tes valeurs vont de 1 à 100 par exemple. Ta question "d'optimiser le cache" n'a même pas de sens à mon avis. Si tu manipule un int (sur 32 bits ou 64 bits) et que tu modifies sa valeur dans le CPU, une fois que tu sauvegarde en mémoire, tu es obligé d'aller écrire tous les bits, qu'ils soient à zéro ou à un ! Le CPU ne sait pas ce qu'il y avait en mémoire avant.
Et dans le cas d'un cache, la granularité du cache est bien supérieure à la taille d'un mot mémoire.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par matiasf . Évalué à 1.
> qu'on utilise des adressages relatifs en 16 ou 32 bits, et qu'on ne puisse pas utiliser de librairie.
Car le compilateur ne sait pas à la compilation où va être chargée la librairie partagée (d'où l'édition de lien à l'exécution pour les librairies partagée). Et donc, il ne peut supposer que la fonction appelée (ou la variable) est à une distance tenant dans un mot inférieur à sizeof(void *) (sous un système 32 bits, sizeof(void *) = 32 et pour un système 64 bits, sizeof(void *) = 64). Donc l'appel de la fonction (ou de la variable) est codé en utilisant une adresse absolue sur 64 bits (si c'est un OS 64 bits). Notes que je n'est pas dit que c'était impossible pour une librairie static (d'édition de lien étant faite à la compilation). Je ne parle que de l'utilisation d'un objet dans une autre librairie partagée !
> Sur Amiga tu pouvais bien avoir des programmes qui n'utilisaient que des sauts relatifs, alors que l'OS était 32 bits.
Sous DOS aussi c'est possible (fichier .com comme je l'ai dit précédament). Car il n'y a pas d'utilisation de librairie partagée.
> Tu te poses de drôles de questions.
C'est pas moi qui ait posé la question (relis le thread).
> Ta question "d'optimiser le cache" n'a même pas de sens à mon avis.
J'ai répondu à une question et dis que l'on ne pouvait optimiser le cache comme c'était proposé. Et je n'ai fait aucune proposition d'optimisation de cache (relis le thread).
> Et dans le cas d'un cache, la granularité du cache est bien supérieure à la taille d'un mot mémoire.
Merci de le confirmer.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Dies Irae (site web personnel) . Évalué à 4.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Olivier Jeannet . Évalué à 3.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par matiasf . Évalué à 0.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Olivier Jeannet . Évalué à 1.
Tu as sans doute raison pour les pointeurs de fonction, mais tu te trompes pour l'adressage relatif qui ne serait pas utilisable entre fonctions.
Dans le cas des pointeurs de fonctions, en effet je ne vois pas trop comment on ferait sans stocker le pointeur complet. Un offset relatif ne marcherait pas pour la ligne "func = titi() ;" puisque cet offset devrait être modifié entre le moment de l'affectation et la ligne où on y fait référence ( "func();" ).
Quoique finalement ça ne devrait pas être très difficile de faire un compilateur qui serait capable de suivre les offset des pointeurs de fonction...
Par contre, n'importe quel appel de fonction "normal" marche très bien avec des offset relatifs, c'est ce qu'il se passe quand tu génères du code "PIC" (position independant code"). Sur 68000 ça se code avec un "jsr offset(PC)" si ma mémoire est bonne. Un appel de fonction ou un saut de boucle, ce n'est jamais qu'un saut (avec dans le cas d'une fonction une sauvegarde sur pile de l'adresse de départ, et un "ret" au bout).
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par matiasf . Évalué à 1.
Pour tout les appels de fonction de librarie partagé, le relatif ne peut pas marché.
> Quoique finalement ça ne devrait pas être très difficile de faire un compilateur qui serait capable de suivre les offset des pointeurs de fonction...
Faut ajouter beaucoup de code pour ça => perte de place. C'est comme les gens qui veulent économiser de l'espace en utilisant des champs bits. Faut tellement de code, que généralement ça bouffe plus de place que d'utiliser un int pour stocker un booleen. Et c'est aussi plus lent.
> Par contre, n'importe quel appel de fonction "normal" marche très bien avec des offset relatifs, c'est ce qu'il se passe quand tu génères du code "PIC"
En fait, lorsque la librairie partagée est chargée, le loader change toute les adresses relatives en absolu (depuis la table des symbols). Car ce sont des adresses relatives (donc de 64 bits sur un OS 64 bits) et non des offsets. Les librairies partagées sont faites en considérant qu'elle commence à l'adresse 0 (la résolution d'adresse sera faite à l'excécution). Il est claire que si plusieurs librairie sont utilisées, ça ne peut pas marché. Le loader va modifier les adresses relatives pour en faire des adresses absolus.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Olivier Jeannet . Évalué à 1.
Oui, c'est un cas où on est obligé d'avoir des adresses absolues. Mais à l'intérieur de ton programme, ou de ta bibliothèque de fonctions, tu peux n'avoir que du relatif.
Encore que, sous Amiga on récupérait une adresse de début de bibliothèque (avec OpenLibrary() ), et ensuite on appelait une des fonctions de la bibliothèque en utilisant un offset relatif si je me souviens bien (en asm : "jsr OpenWindow(a6)", a6 étant le registre d'adresse pris par convention pour les appels de biblio), la bibliothèque comprenant en son début une table de fonction . Que les ex-amigaïstes me confirment la chose...
Tout ceci pour dire que passer en 64 bits ne devrait avoir qu'une influence tout à fait réduite sur l'occupation mémoire ou disque, en particulier aucun risque de doublement de taille.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par matiasf . Évalué à 0.
Pas dis le contraire.
> en particulier aucun risque de doublement de taille.
C'est claire.
Mais pour répondre vaguement à la question :
du -s
ftp://ftp.redhat.com/pub/redhat/linux/7.2/en/os/i386/RedHat/RPMS/(...)
1166250
du -s
ftp://ftp.redhat.com/pub/redhat/linux/7.2/en/os/ia64/RedHat/RPMS/(...)
1194397
Mais la version ia64 a presque 90 paquets de moins !
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par gouzou alexandre . Évalué à 4.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par TSelek . Évalué à 3.
Mais ça ne m'explique pas pourquoi on en est pas resté aux 8 bits alors que 16 ça bouffe plus de mémoire ! quand aux 32 bits houla comme c'est trop cher ! les 4 bits c'est pas mal aussi comme rapport qualité/prix.
On pourrait pas faire du 48 bits ? c'est un bon compromisentre 32 et 64, pour couper la poire en deux...
Plus sérieusement, j'ai une barrette de 1 Go sur ma liste de courses, maintenant là en 2003, et je ne suis qu'un rigolo, même pas pour du serveur, alors la barrière des 4 Go toujours pas cassée en 2008, hum hum c'est aussi mal vu que le 640kb is enough for everybody de l'autre escroc.
# et pour le 64 bits pas grand public ?
Posté par Troy McClure (site web personnel) . Évalué à 3.
[^] # Re: et pour le 64 bits pas grand public ?
Posté par Pierre Tramo (site web personnel) . Évalué à 4.
D'apres lui, ça devait surtout venir de gcc qui est pourri sur les non x86. Ça sert pas a grand chose si y a rien de correct pour l'exploiter.
[^] # Re: et pour le 64 bits pas grand public ?
Posté par Troy McClure (site web personnel) . Évalué à 3.
http://sourceforge.net/projects/open64/(...)
[^] # Re: et pour le 64 bits pas grand public ?
Posté par Obsidian . Évalué à 2.
Je voudrais pas dire de bêtises, mais j'ai l'impression que s'offrir une archi 64 bits, c'est un peu comme monter un cluster ou faire du traitement en parallèle en général. Si l'architecture logicielle n'est pas adaptée, on ne risque pas de gagner en performance de façon fulgurante.
D'autre part, je suis en train de me demander dans quelles conditions le 64Bits peut-être réellement utile. Si l'on considère en simplifiant à l'extrême que le 64 bits agit sur la taille des entiers manipulés par le processeur en une opération et sur la largeur du bus, on peut comprendre qu'un entier compris entre -32768 et +38767 soit un peu étroit pour la plupart des opérations courantes et que passer du 16 au 32 bits ait apporté un réel gain en ramenant à une seule étape les opérations qui étaient découpées en deux phases voire plus.
Par contre, atteindre les limites de -2147483648 à 2147483647, c'est pas courant. Connaissez vous beaucoup d'applications actuelles qui fassent un usage intensif des quad words ? Ah si, peut-être les "double" très utilisés par les compilateurs.
En dehors de ces cas précis, 0001 et 00000001 représentent la même chose, et s'il faut autant de temps pour accéder à la mémoire, je comprend que le gain en performance ne soit pas évident.
[^] # Re: et pour le 64 bits pas grand public ?
Posté par herge . Évalué à 4.
Certaines applications peuvent également bénéficier d'un gain de performance en effectuant certains calculs par blocs de 64 bits, plutôt que 32 bits, mais MMX et SSE existent déjà pour ce type d'opérations et sont plus performants.
[^] # Re: et pour le 64 bits pas grand public ?
Posté par Nÿco (site web personnel) . Évalué à 2.
[^] # Re: et pour le 64 bits pas grand public ?
Posté par nigaiden . Évalué à 3.
[^] # Re: et pour le 64 bits pas grand public ?
Posté par Pierre Tramo (site web personnel) . Évalué à 1.
[^] # Re: et pour le 64 bits pas grand public ?
Posté par Nÿco (site web personnel) . Évalué à 1.
[^] # Re: et pour le 64 bits pas grand public ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: et pour le 64 bits pas grand public ?
Posté par Olivier Jeannet . Évalué à 2.
[^] # Re: et pour le 64 bits pas grand public ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: et pour le 64 bits pas grand public ?
Posté par doublehp (site web personnel) . Évalué à 2.
[^] # Re: et pour le 64 bits pas grand public ?
Posté par Jean Roc Morreale . Évalué à 3.
[^] # Re: et pour le 64 bits pas grand public ?
Posté par doublehp (site web personnel) . Évalué à 8.
[^] # Re: et pour le 64 bits pas grand public ?
Posté par PLuG . Évalué à 1.
[^] # Re: et pour le 64 bits pas grand public ?
Posté par Olivier Jeannet . Évalué à 1.
Déjà, ajouter un bit ça serait pas mal, ça doublerait le nombre. Avec 5 bits ça comblerait les besoins de beaucoup de gens (32 possibilités, il y a de quoi en mettre des cartes d'extensions).
8 bits, ça me paraît énorme et inutile, ça fait 256 IRQ différentes.
[^] # Re: et pour le 64 bits pas grand public ?
Posté par doublehp (site web personnel) . Évalué à 2.
Meme Aple s est offert 8 bits pour les IRQ ... j ai jamais entendu dire que c'etait "trop" :=)
[^] # Re: et pour le 64 bits pas grand public ?
Posté par Sidoine de Wispelaere . Évalué à 1.
Les IRQ sont cascadables : on a un premier niveau de 8 IRQ dont une sert à accéder au deuxième niveau => total de 15 IRQ. Je suppose que rien ne s'oppose à ce qu'il y ait un niveau supplémentaire... Sauf que ça sert pas à grand chose et il faudrait que l'OS le supporte.
[^] # Re: et pour le 64 bits pas grand public ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Sinon, il faut lire ".8" soit 0.8 bits de plus (une moyenne.) par an.
"La première sécurité est la liberté"
[^] # Re: et pour le 64 bits pas grand public ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Coté Athlon64, l'avantage est l'ajout d'un mode d'adressage qui faisait default et le doublement du nombre de registre adressable.
"La première sécurité est la liberté"
[^] # Re: et pour le 64 bits pas grand public ?
Posté par Fabimaru (site web personnel) . Évalué à 4.
[^] # Re: et pour le 64 bits pas grand public ?
Posté par Troy McClure (site web personnel) . Évalué à 2.
cat /proc/cpuinfo
processor : 0
vendor : GenuineIntel
arch : IA-64
family : Itanium 2
model : 0
revision : 7
archrev : 0
features : branchlong
cpu number : 0
cpu regs : 4
cpu MHz : 995.819000
itc MHz : 995.819000
BogoMIPS : 1488.97
je relance le bench de http://linuxfr.org/comments_reply,10578,155866,1.html(...)
** **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark(...) **
** for details. (Results can be submitted to pozo@nist.gov) **
** **
Using 2.00 seconds min time per kenel.
Composite Score: 120.72
FFT Mflops: 65.99 (N=1024)
SOR Mflops: 229.90 (100 x 100)
MonteCarlo: Mflops: 51.47
Sparse matmult Mflops: 147.90 (N=1000, nz=5000)
LU Mflops: 108.34 (M=100, N=100)
ben voilà, pour la factorisation LU c'est le score de mon celeron@450 MHz :))
# Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par cveyoda (site web personnel) . Évalué à -1.
n'est pas pret et comme intel et bill travaillent toujours ensenble,
ca va de soit, intel doit attendre que win64 fonctionne !?
m'enfin avec du 32 bits j'en ai assez pour le moment.
Amd avec un 32/64 ca permet de fair tourner des anciens os,
et aussi les GNU/linus qui sont deja pret.
a+
cveyoda
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par matiasf . Évalué à 0.
http://www.microsoft.com/windowsserver2003/64bit/default.mspx(...)
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par pasBill pasGates . Évalué à 2.
# Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par cveyoda (site web personnel) . Évalué à -2.
n'est pas pret et comme intel et bill travaillent toujours ensenble,
ca va de soit, intel doit attendre que win64 fonctionne !?
m'enfin avec du 32 bits j'en ai assez pour le moment.
Amd avec un 32/64 ca permet de fair tourner des anciens os,
et aussi les GNU/linux qui sont deja pret.
a+
cveyoda
# Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par Troy McClure (site web personnel) . Évalué à 2.
Astute observers will have wondered how a 32bit processor can address more than 4GB of memory. PAE is the answer. It allows 36bit addressing using 'pages' of memory. According to Torvalds, the Pentium 4 is crippled "because Intel refuses to do a 64-bit version (because they know it would totally kill ia-64)."
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.