Reprise du message précédent :
2x64 bits, peut être que c'est plus approprié pour des dual-cores (qui ont tendance à vouloir accéder simultanément à des zones mémoires différentes)  
Mais je pense pas qu'il puisse y avoir affectation d'un contrôleur mémoire à chacun des cores.

Non dual channel=deux bus :
http://en.wikipedia.org/wiki/Dual_channel
 
Et en fait (me suis trompé) pour a64 c'est deux bus pour UN contrôleur (en 939), dual core ou non.
http://www.hardware.fr/articles/57 [...] -4400.html

Les A64 dualcore ont un seul contrôleur mémoire mais cette division par 2 de la BP mémoire (pour chaque core) n'engendre pas de grosses pénalités. Y'a qu'à voir comment se débrouille un A64 S754 monocanal pour s'en convaincre, le dualcanal était loin d'etre pleinement exploité, je dirais même que le passage au S939 dualcanal étais là pour acceuillir le dualcore et non pour augmenter les perf de 0-5%.
 
L'article parle d'un contrôleur mémoire dédié pour core mais cela ne signifie pas qu'il sera intégré, si?
X86-secret avait fait un article il y a quelque temps, ça risque d'être du meme genre je pense :
http://www.x86-secret.com/articles [...] core-4.htm
 

En fait ouais

Si t'accede en 128 bits sur ta RAM t'a bien qu'un seul bus logique de 128 bits, même si physiquement c'est deux bus de 64 bits.
 
C'est pour ça que les deux mode sont possible. Mais bon je crois qu'hormis SiS, peut de chipset gère les deux modes. Chez Intel c'est que du 128 bits je crois.

 
C'est quoi cette histoire de "bus logique" et de deux modes différents ? Tu as des articles là dessus ?

Oula faudrais que je recherche ça.
 
Mais le controleur d'un point de vu logique est soit en 128 bits soit en deux parties de 64 bits, suivant les fabricants - parfois mêmes les deux modes sont supporté.
 
L'avantage du 2x64bits c'est qu'on peu avoir deux barettes différentes et quand même avoir un gain en perfs.

Ok, je comprends mieux. Si j'ai bien suivit, c'est du point de vue du contrôleur qui gère les deux barettes en un seul tenant (2 barette identiques obligatoires) ou indépendament (barettes différentes possible).
En revanche çà ne change rien au fait que si toutes les informations nécessaires au cpu sont dans la barette 1, le dual channel ne sert à rien. A l'inverse, s'il a besoins d'informations dans la barette 1 ET la 2 alors on augmente la BP maxi.

Oui c'est ça.
Le mecanisme 2x64 bits c'est exactement ce que fait le DASP du nForce2. Ca permet d'améliorer la latence principallement. (d'où le besoin d'un tRAS à 11 pour une meilleur éfficacité car c'est, en hard, le mieux pour synchro les deux canaux)
 
Quand c'est en 128 bits ça marche un peu comme le RAID 0 pour les disques durs.

 
mi-2006... sa va etre long................................
 
http://www.x86-secret.com/pics/news/q305/conroe-b.jpg

C'est pas aujourd'hui qu'Intel doit nous faire des confidences ?  
(je l'ai noté dans Outlook )
 
J'attends ca impatiemment

Des news sur le Conroe :
http://www.hardware.fr/news/7768/n [...] intel.html
 
http://www.clubic.com/actualite-21 [...] du-p4.html
 
Je pense que cette fois ça va roxxer avec cette new archi !  

Enfin, après les cochonneries desktop de ces dernières années, Intel devrait sortir du bon
 
l'HT est largué au fait
 
http://www.clubic.com/actualite-21 [...] ding-.html

Normal que l'HT soit largué, l'HT est une techno qui peut marcher qu'avec l'archi Netburst.
 
Aucun interet avec un petit pipeline.

L'HT était un paliatif à l'archi netburst, nuance

L'hypertreading c moins bien que le multicore
 
Avec windows qui gere les core comme des bananes le CPU passera plus de temps a trouver quel core il doit utiliser pour son calcul plutot que a faire le calcul

C'est normal que l'HT soit moins bien que le multicore.
 
N'empêche qu'Intel a essayé de la claquer sur du multicore, beurk.....

Bah Dual Core w/ HT, avec un noyau Windows adapté ca doit quand même être pas mal efficace.
 
C'est comme dire que l'HT beurk ca bug sous Win2K quoi.
 
L'HT apporte un gain et c'est tout. Apres ca plait a qui veut, mais j'prefere que l'HT soit sorti que de garde un P4 exploiter dans pas mal de cas qu'a peine à 80% quoi.

Et dans tout ça, ils comptent toujours sortir le cedarmill et le prestler?  
 

Si tu as un pipeline court, beaucoup d'unites d'execution (dont la moitié se tournent les pouces ), et un decodeur assez puissant pour deux threads, alors ça fonctionnera aussi. C'est ce qu'IBM utilise dans le power 5 je crois.

Tiens oui, j'y pensais plus aux Cedarmill & Prestler  
Ils vont avoir une durée de vie assez courte

 
Sous XP c'est pareil, un PIV 3.06GHz se fait torcher par un XP 2200+ avec de la BD Access/SQL. Au moins sur l'Athlon tu continue à pouvoir te servir de la machine

Oui. Cela dit avec une tâche lourde multimédia on peut continuer à utilser le PC tranquillement, là où c'est impossible avec l'a64 (ex OCCT stab test+surf).
J'ai comparé un a64 s939 1.8@2.4Ghz avec mon p4C 2.4@3.0 sous Win. Pas eu le temps de le faire sous Linux.
 

Le Netburst à toujours suxxé des ours polaires sur les entiers, il se fait aussi torcher en compilation Le p4 est un cpu mul-timéheu dia, na ! On comprend mieux l'arrivée de p-M pour serveurs.
 
Sinon personne ne parle de la fusion des micro opérations pour le suivit des instructions dans le Conroe, à la manière d'un PPC970 (ou dans une moindre mesure d'un p-M) :
http://arstechnica.com/news.ars/po [...] -5232.html
 
Apparement toujours pas de contrôleur mémoire intégré, AMD peut dormir tranquille de ce côté. Pourquoi ? Le contrôleur bouffe des pins, et Mr Intel trouve çà trop cher à fabriquer. Un sous est un sous.

Et ça lui permet de garder le meme socket (LGA775).

Si ça pouvait être compatible i865

Faut pas rever   ...Ceci dit, j'avais vu une news comme quoi certains P4 dual core pouvaient marcher sur certaines mobo i865...

Jouer à HL² tout en compilant une carte sous Hammer est tout à fait possible, c'est moins fluide, mais tout à fait jouable !    
 
OCCT est quand même un truc spécial, et si il laisse la machine utilisable sous PIV HT, c'est qu'il accompli mal son boulot

ou qu'il répartit bien son boulot...  

Ca serait cool, surtout que le cpu sera moins gourmand donc sans les problemes de compatibilité electriques aec le p4D.

OCCT avec HT ca rame quand même bien... Ou alors c'etait mes seulement 512Mo je sais pas...
 
Pas contre je peut encore utilisé le net avec OCCT (ou meme un Nero Digital qui encode a mort) sur mon A64 (les 2Go aidant ptet aussi ). D'ailleurs une fois j'y pensais plus j'ai lancé DOOM3 pour jouer, et si y'avais pas DOOM3 qui avait crashé car comme j'ai desactivé le swap il avait pas assez de RAM, j'crois qu'j'aurai p'tet pas capté de suite.
 
Bref l'HT ou l'absance d'HT ne fait pas tout en multitache je crois.

Si ton appli est multithread dans ce cas c'est "logique"... Apres c'etait ptet aussi l'HDD qui limitait...

Si effectivement le DD limitait, je ne pense pas que la machine serait entièrement congestionnée...
 
Surtout que l'AXP lui s'en sort bien mieux niveau gestion.
 
Les données sont sur un serveur MS SQL....
 
Et l'appli n'était pas du tout multithreadée (auquel cas de toute façon l'AXP n'aurait pas dû répondre mieux).

Si il laisse des miettes à d'autre sprocess, il fait très mal son boulot puisqu'il est censé stresser à mort le CPU

Tu as fumé là

Oui oui j'ai fumé la moquette. C'est un contrôleur dédié en fait. Comme l'a fait remarqué Fouge x86 avait fait une news là dessus il y a quelques temps.

En étant monothread, et vu le système de prioritié, il exploite rarement 100% du CPU. Mais bon souvent 98-99% De plus si <90% de moyenne le test s'arrete.

Alors si il ne sature pas un PIV en le testant (laissant de la place pour d'autres threads), il n'est plus adapté pour une chauffe maxi

 
Chez moi un OCCT ne suffit pas non plus pour occuper "les deux" cpus à 100%.  
 
Pour valider mes stabilitées, je balance OCCT + Super pi 32M + 2  CPU Burn et trottlewatch pour verifier que la surchauffe n'entraine pas de trottle.
 
 

Un logiciel monothread ne peut pas saturer un P4 HT.
Et le but c'est pas la chauffe

 
Effectivement, c'est de voir si le CPU tient la course même quand on le charge à bloc. Si OCCT ne charge pas à bloc le PIV HT, et qu'il peut faire plus dans d'autres situations, alors ben. bof quoi.

Le developpeur d'OCCT maintient ça car son algo ne laisse pas la place pour un second thread. (ce qu'il dit).
 
Apres bon, même sur un P4 sans HT on a du mal à saturé a 100% avec OCCT. C'est normal il est qu'en priorité Normal.

Tu as raison, OCCT est spécial. Mais p4p800 venant de cramer, et les CM s478 se faisant rares, j'ai acheté un a64 3000+ s939.
En multitâche massif avec LAME en ar plan par ex, il y a tout de même avantage à l'HT.