Reprise du message précédent :

Toi même

cet article me semble vraiment complètement louche, je laisse tomber...

j'aurais dû mettre un disclaimer :
 
attention c'est du the inqu, ne lisez pas si vous avez un QI plus gros que votre taille de slip

Moi j'ai même un QI plus gros que la taille de mon Jean

Et pourquoi pas un socket un peu particulier, pouvant accueillir 2 modules :
- un proc 32 bits x86 (le Tejas)
- un proc 64 bits (au hasard, le 64 bits de l'Itanium )
Ce serait le meilleur moyen d'assurer la transition entre les 2, en permettant de monter l'un, ou l'autre, ou les 2 sur une même carte mère, sans perte de performances puisque chaque proc peut traiter le code qui lui correspond  
 
Blazkowicz > je ne m'étendrais pas sur la taille de mon QI, je pense que chacun pourra se faire sa propre opinion

 
sa veux dire ok en langage d'jeun'z

ouais, et quand tu dois faire du 32bits, tu mets ton P5 et quand tu veux exécuter du 64bits, t'ouvre ton PC et tu mets un itanium à la place    
 
 

 
et tu fait un dual boot.
 
z'avez pas fini de troller ce bo topic.

non, ce serait géré par l'OS. On sait faire un OS capable de gérer simultanément des applis 32 bits et des applis 64 bits (le processeur passant dans le mode qui convient quand il faut), et on sait répartir des tâches sur plusieurs processeurs. Alors pourquoi un OS ne pourrait pas répartir des tâches différentes sur des processeurs différents ?
 
SiXPAcK > spa un troll, c'est juste que ce week-end, j'ai pas récupéré mes heures de sommeil en retard

on peut peut-être faire un dual-boot spécial: au lieu de juste choisir l'OS, on choisit aussi sur quel module on veut booter

faut bien passer le temps    

mouais, le genre de truc qui donne des cauchemars aux "kernel hacker"...

Et tout ça pour à peine 10000? trop cool

Serait-ce vraiment plus compliqué que ce qui existe actuellement ? Un windows XP "AMD64" est capable de mélanger des applis 32 bits et des applis 64 bits. Il est aussi capable de répartir des applis sur plusieurs procs.
Il "suffirait" de se limiter à affecter les applis 32 bits sur les procs 32 bits, les applis 64 bits sur les procs 64 bits  
 
Elle me plait bien cette idée. Vous auriez le numéro d'Andy Grove, j'ai un coup de fil à lui passer ?  
 
mareek > quand on aime, on ne compte pas

 
Pour gagner du temps on peux passer direct a 2048 bit non?

bon, un coup de fer à souder, et je me monte une machine avec une 68000 pour les jeux amiga 500 et un 486 pour jouer à doom
 
avec un OS qui switche intelligemment entre les programmes!

 
adresser 2^2048 octets est une priorité en effet
 
malheureusement ça doit dépasser l'entropie de notre univers

Même si on veut exprimer la distance entre la voie lactée et la galaxie la plus éloignée connue en pouces, ont aura pas besoin d'une telle précision

c'est vrai que c'est peut-être réalisable en fin de compte  

réalisable, peut-être, mais un quad opteron serait moins cher

tout à fait, et sans doute plus puissant...

 
c koi cette histoire de precision?
 
avec mon 32bit je calcul autan de decimal de pi que je veux!!
 
si je laisse tourné pendant 10 000ans et si j'ai un disque dur assez (relativement) enormisime, mon pauvre cpu 32 bit limitera pas la precision

Un cluster de 500 Cray T3E aussi

bon, désolé de briser vos rêves, mais ça a déjà été réalisé
 

 
ça vient du topic "quizz"
http://forum.hardware.fr/forum2.ph [...] h=&subcat=
 
une extension pour un amiga
 
c'est pas du 32/64bits, mais ya tout de même un MC68060 et un PPC604e, selon le code qu'on fait tourner, et ça fait du multitâche

bon ben désolé mrBebert, tu pourras pas déposer un brevet

Un processeur 32bits ne peut pas traité de nombres entier plus grand que 4 294 967 295 (hors instruction mmx&Co).|

et encore, MMX et SSE ne gèrent que des entiers 32bits eux aussi, ils les prennent peut-être par paquets de deux ou quatre mais ça s'arrête là

zut  
Alors ca veut dire qu'il faut que je mette mon réveil pour demain tout à l'heure pour aller travailler

 
+1
 
(pfff.. réveil à 5h45 mais il me faut de la marge pour pas chier le bus )

et tu dors quand ? Aux cours ?

 
 
 
aussi important que la différence entre un Athlon 64 et l'Athlon 64 FX grosso modo; d'après les tests publiés
 
De plus le prescott a un cache L1 doublé, divers réarrangements et optimisations diverses  

 
 
d'ailleurs, c'est pas discret avec les Zz au dessus de ma tête
 
 
 
 
 
bon..
BN  
 

ben si, le MMX gère les entiers 64Bits et le SSE les entiers 128Bits
http://www.onversity.com/cgi-bin/d [...] &P=100&T=0

Single Instruction Multiple Data
 
par exemple
 
http://www.codeproject.com/cpp/sseintro.asp
 
Processor with the Intel SSE support have eight 128-bit registers, each of which may contain 4 single-precision floating-point numbers.

En effet, les "vrais" entiers 64Bits, n'arrivent qu'avec le SSE2    
 
http://www.intel.com/design/Pentiu [...] 547012.pdf (chapitres 9-10-11)
 
P.S. ton lien marche pas

 
J'avais bien compris.
Le probleme c'est que par quel miracle le P5 va mettre 1Ghz au prescott.
 
Selon les dates de l'article, le P5 serait prêt 4 ou 6 mois après Janvier 2004.
Le prescott est sensé atteindre combien l'été prochain ?
http://www.presence-pc.com/news/n1301.html
Ici il donne le Tejas à 4ghz, ca serait déja pas mal.

 
Personne ne se rapelle le slide d'AMD avec le SMP asymétrique K8 - K7 ?
 

 
sans aucun doute

 
 

 
Vi vi, donc les gains du Prescott ? C'est dû à quoi ? L2 ?  
L1 ? HT2 ?

clairement....En plus dans la gamme P4, j'ai jamais vu une nouvelle version etre moins performante que celle qu'elle remplace, alors bon je trouve ça bizard....

c'était plutôt un SMP Opteron - A64 non ?    
Car jusqu'à preuve du contraire, il n'y a pas de K7 avec HT prévu...

 
mmmmmh, je sais plus en fait.
 
Remarque le lien HT -> nortbrige EV6 -> bus EV6 -> K7 pourrait faire l'affaire non ?