Reprise du message précédent :
Vu le taux d'adoptiondu 64bit au niveau logiciel, on est pas pret de voir le 128bit débarquer ...
 
Surtout quand j'entend dans les magasins d'informatique : "prennez du 32bit, il y a moins de bug qu'en 64" (véridique !!!)

Je trouvais ça bizarre aussi alors que les 1er cpu 128bits ne sont même pas évoqués dans la presse...

Je vais tourner le problème dans l'autre sens.
On sait que les mobo X58 actuelles ne seront pas compatibles, mais est-ce aussi le cas pour les bloomfield?
 
C'est peut être complètement bête comme question mais bon je demande quand même.

on va surtout dire que l'intérêt n'est pas le même. Pas grand monde ne revendiquera cette évolution ( changer de mobale pour le même proc => sur le x58 aucun intérêt), tandis que changer de mobale pour pouvoir changer de procal, c'est moins bien déjà

Bah si ça permet de changer en plusieurs phases.
bloomfield+X58(v2009)->bloomfield+X58(vSandyBridge)->cpu SB + X58 SB.
 
Moi j'y vois un intérêt.

 
Il s'agira d'une nouvelle architecture, donc le moindre changement d'alimentation et paf les Bloomfield passent à la trappe ...
 
Après, c'est une possibilité, mais la probabilité qu'elle soit réelle est quasi-nulle ...  
 
Et puis, quel serait l'intérêt pour Intel ? Vider les stocks de Bloomfield/Gulftown plus rapidement ?  

Faudrait apprendre à lire zack, regardes mon premier post. J'en sais rien si les bloomfiled seront compatible, je demande justement.

Je sais parfaitement lire, merci .  
Bon, eh bien, je te laisse deviner la réponse ...

 
Non non tu sais pas lire, surtout quand je vois ça :

 
Alors que juste au dessus j'ai mis :  
 

 
bref  

Toi, t'as pas dû apprendre l'indulgence à l'école ...  
J'ai zappé ton post, tout simplement . Désolé .

Des liens ?

dailytech je crois, mais j'arrive plus à mettre la mains dessus.

 
ah ouais? et quel est l'intérêt de changer en plusieurs phases?  

le banquier par hasard ?

 
  , ça me semble logique pourtant.

mais pourquoi est il si méchant ??

Pourquoi? l'intérêt c'est bien ce que tu as mis  

je parlais du banquier qui est mechant : je dois attendre le 01Nov pour acheter mon i7

Ah ok  

range ce grand sourire, je vais m'enerver  
 
enfin le premier c'est tout de suite dimanche. mon Athlon 3000 tiendra bien encore deux semaines (moi non mais lui oui )
 
sinon fin du HS :
il n'y a pas plus de news que ca sur Sandy KiloBridge ?

ben désolé moi je vois pas l'intérêt d'acheter une nouvelle mobo si on peut pas y mettre les nouveaux cpu qui vont avec   et se retrouver avec les mêmes perfs qu'avant

Mais bien sur qu'on peut mettre un cpu SB sur une mobo X58 SB, je dis juste que si tu n'as pas le budget pour passer complètement sur SB et que tu possèdes en ce moment un bloomfield, si Intel pouvait faire en sorte que nos i7 9xx soient compatibles mobo X58 SB , ça serait vachement bien.

   
 
bah suffit d'attendre d'avoir le budget  
c'est une fausse bonne idée ton concept

Il semble que les versions grand public du SNB n'utiliseront pas le socket LGA 1156, mais le socket H2.  
 
Oui un nouveau socket (et VRM). Surtout pour empêcher de mettre un CPU 1156 sur une mobo SNB, ou un SNB sur une mobo 1156.
 
source: la doc Intel test tool.

 
En même temps on s'en doutait un peu...
Intel et les changement de socket, une longue, très longue histoire  

& sockets + chipsets => histoire sans fin

 
C'est quoi les "X horloges" un peu partout ?

Des cycles, pas des horloges.
 
Sinon, c'est quoi la source de ça ?

Il s'agit du tri-gate ? http://www.intel.com/technology/si [...] d_cmos.htm
 
Parce qu'en fait cette affirmation est issue du wikipedia italien, et ne repose sur aucune source. C'est d'ailleurs pas une affirmation, mais une question.
 
http://it.wikipedia.org/wiki/Sandy_Bridge

Et qu'est-ce que c'est, des cycles ?  
 
Ouais, possible que le tri-gate soit utilisé ... je crois qu'Intel avait dit qu'il l'utiliserait pour ses CPU en 32nm .  
 
Après, Intel en a bien d'autres en réserve comme ça, cf sa fameuse technologie qui réduit la consommation de 90% .  Mais celle-là n'arrivera certainement pas de si tôt .

Le trigate c'est surtout une annonce de 2005 ou 2006, dont Intel n'a plus reparlé.
 
Et que wikipedia a ressorti en supposant que ça s'appliquerait au SNB.

 
Sauf qu'Intel investit rarement plusieurs millions de dollars en R&D pour annoncer une techno inutilisée ... ce serait con, quand même !

C'est juste, mais pas de trigate avant au moins le Ivy Bridge.

 
Pourquoi attendre le 22nm pour passer à l'action ?  
 
Pour le moment, on a aucun chiffre concernant la consommation des SNB, on peut donc toujours espérer .  
Sans tri-gate, je vois difficilement comment Intel pourrait se permettre de sortir des CPU à 4GHz .

Parce que le trigate est une modif de process, et que les modifs de process se font lors d'un tick.
 
Pour les 4 GHz, c'est du flan.  Encore qu'un i7 975 (déjà à 3.33 GHz) passé au 32nm soit pas loin de ces 4 GHz.

Peut-être que le Gulftown en bénéficiera ? Peu probable, m'enfin sait-on jamais ...  
 
Ouais, sinon, toutes les infos qu'on a sur SNB sont périmées vue leur ancienneté .  
 
Au fait, squoi la mémoire de trace ? ...

S'il n'est pas sur le SNB, il n'est pas non plus sur un CPU lancé 1 an avant. Toute la doc sur le 32nm est dispo sur le site d'Intel.  
 
Peut-être gardent-ils cette techno au chaud pour quand ils commenceront à avoir des soucis de réduction de gravure.
 
Là avec les 45, 32, 22nm, ils semblent vouloir aller vite.
 

Je ne sais pas. Cette citation est extraite de quoi ?

 
Intel n'ira pas plus vite que son tick-tock le permet .
Et, je le redemande, qu'est-ce que c'est que les "cycles" ? Les Hz par Hz ? Et c'est quoi le décodeur de base dont il est fait mention dans le wiki anglais ?

Un cycle, c'est un "coup" d'horloge. Quand un proc fonctionne à 1 Ghz, il traite 1 milliard de "cycles" à chaque seconde.
On va se baser la dessus pour déterminer le rendement d'un processeur, c'est à dire la quantité de travail effectué pour un nombre de cycles donnés. Ce rendement, n'est pas le même entre différents processeur, et donc un processeur peut être plus performant tout en étant moins rapide (en fréquence).

Traduction (pas géniale) de "trace cache", j'imagine ?
Un processeur x86 n'exécute pas directement les instructions x86. Il les décode (convertit) en micro-instructions qui seront, elles, traitées par les différentes unités (dan un ordre pouvant être différent de leur ordre d'entrée).
Le trace cache est un cache sur cette opération de décodage  

 
Ok, pour les cycles, c'est bien ce que je me disais, mais alors pourquoi il y a des chiffres à côté ? Ils vont exécuter un nombre de cycles différent de celui du CPU ?  
Et aussi merci pour l'explication de la mémoire cache de "décodage" .  C'est un peu plus clair, maintenant . Donc, en fait :
 

 
... ça veut dire la même chose .
Mais pourquoi elle fera son retour dans SNB ? Avant, les CPU ne décodaient pas le x86 ? C'est louche, cette histoire

Parce qu'un processeur peut faire plusieurs choses à chaque "tic" d'horloge (chaque cycle). Il y a plusieurs unités, qui travaillent en parallèle. J'imagine que ces chiffres indiquent le nombre d'instructions que peut traiter (dans un cas idéal) le processeur à chaque cycle. Ou le nombre de données ? (c'est différent avec les instructions vectorielles où une instruction s'applique à plusieurs données d'un coup)
En fait, je comprends pas ce que ca signifie. Faudrait avoir l'original en anglais, la traduction est ... peu claire  
 

Que les processeurs décodent, ca reste vrai. La différence, c'est qu'ici, il décode et met en cache les instructions décodées. S'il revient dessus, il n'aura plus à les décoder
Du moins, c'est ce qu'on avait sur les P4, il y aura peut être des nuances sur ce processeur

   Tu prends le problème à l'envers.  
 
C'est parce qu'ils vont vite qu'ils ont mis en place le tick tock. Enfin, pas le tick tock lui même, mais le rythme.
 
Et d'ailleurs ce rythme se ralentit déjà. Donc raison de plus pour Intel d'utiliser les trucs comme le trigate quand ils en auront vraiment besoin.
 
Et avec les yields et l'efficacité des 45nm et 32nm, c'est facile à comprendre que pour l'instant le Trigate et co ils s'en fichent un peu.
 
Il laissent ça en R&D, ce qui permet de l'améliorer encore, et l'utiliseront quand ils en auront besoin.