Reprise du message précédent :
un test relativement interessant
http://www.pcinpact.com/articles/a/127/0.htm?pge=1

lol j'aime bien le constat sur le fait que win répartit mal les resources. c'est pas un scoop. au fait nos cpu (mono core) ne sont pas sensés supporter le multi tâche ? nous aurait-on menti ?
le fait de vouloir justifier le dual core avec du multi tâche ça va pas nous servir ...
 
sinon j'adore la conclusion : "Le hardware est finalement, et comme toujours, en avance sur le software d'au moins 2 bonnes années..." . ça dépend ce qu'on prend en référence comme soft ...  
(bon ok on est pas vendredi mais de toute façon faudra que les sites regardent un peu en arrière et réalisent ...)

Certainement le meilleur test du moment !!!
 
http://techreport.com/reviews/2005 [...] dex.x?pg=1
 
C'est bizarre mais y'a 99% d'opterons en haut des tableaux  

pourquoi donc le meilleur test du moment
 
je trouve le choix des tests bien étrange personnellement, pas du tout en adéquation avec le type de processeurs testés.

ya presque la gamme complete d'intel et amd
 
ta un autre article avec autant de cpu "server"  

Le Sempron passe au 64bit :
http://www.matbe.com/actualites/10 [...] ussi-a-64/

 
C cool, comme je change de proco tous les 5-6 ans, le 64bit est pour moi incontournable. Enfin qqchose de pas cher. (J'ai été hyper frustré d'acheter il y a qq années un des derniers 286, quand j'ai vu plein de choses qui tournaient sur 386 mini!)
 

Il faudrait peut-être que tu te renseignes sur ce qu'est la gestion multitâche sur un mono-proc
 
Les processeurs ne sont pas multi tâches, les OS le sont et doivent allouer les ressources processeur aux différents threads d'exécution. Pour un processeur classique, il n'y a pas de "mono tâche" ou de "multi-tâche" (c'est différent pour les processeurs HT avec les cores virtuels, et je ne sais pas ce que vont donner les processeurs de prochaine génération implémentant la virtualisation matérielle), un proco est capable d'exécuter une suite d'instructions, et c'est à l'OS de fournir ces instructions, donc de jongler entre les tâches.

C'est pourtant l'intérêt de base, faire tourner plusieurs applications concurrentes simultanément, ou améliorer la réactivité des applis correctement multithreadées.

Masklinn »
 
Et pis en plus, les arguments utilisés par ces personnes sont typiques des gens qui n'ont jamais utilisé de bécanes multi-proc

Le multiproc ça pourt0rz, chuis un peu dégouté d'avoir acheté mon A64 avant la sortie des multicores d'ailleurs (donc je suis en monoproc/monocore, vu que j'avais franchement pas le budget pour un système bi-opterons ), mais franchement il y a un monde entre le monoproc et le dual proc, même sur un desktop, quand on utilise des applis un peu intensives en ressources

vivi, d'ailleur si tu veux te faire mal : http://forum.mesdiscussions.net/sm [...] egorie.htm
 
Et pis aussi là :

Les Athlon MP ca ne fait plus mal à personne

Certes, mais ça tient encore 'achment bien la route pour la plupart des utilisations
 
Et pis l'aspect multi-proc permet d'éviter les "blocages" de proc sur des allocations de ressources hasardeuses

Opteron ou Athlon 64 X2 et hop

bi xeon/RH au taf, pour modelisation . certes je suis pas au fait de la limitation qui pose pb mais si les pipelines ne sont pas id indépendant nos proc n'étaient pas multitâche. et faudrait plutot commencer par ça plutot que faire du multicore. si il le sont alors le pb est logiciel et une fois de plus on compense à grand coup de hardware un mauvais soft.

Marc » Me tentes poa ... ya des fois G des envies de revendre mon bi-1900+  
 
Mais bon, comme mes 2 bécanes ont encore suffisemment de souffle ... j'vois poa trop l'intérêt immédiat passer à l'opteron surtout quand le WinXP 64 n'est poa dispo dans le commerce
 
Et pis quite à faire du massivement multi-proc : http://www.xbitlabs.com/articles/e [...] 5-7_6.html avec des Opteron 875 histoire d'aller jusqu'au bout du raisonnement.
 
Budget à prévoir : environ 10 000 € l'bestiau

Dans les faits oui, mais le puriste te dira que cet apport de puissance/souplesse est un plus et non une compensation avec les applis ad-hoc.

le puriste ou le gobeur de marketing ?

Le mec qui comprend qu'une appli correctement multithreadée (bien codée) tourne mieux en multicore/multiproc que sur un monocore monoproc
 
De même pour faire tourner simultanément plusieurs instances d'une application à consommation de ressources intensives, ou plusieurs applications concurrentes en parallèle...
 
Edit: quand l'OS a un scheduler potable pour pouvoir tirer parti des cores multiples parallélisés bien sûr

Atlantis » Ben le développeur info industrielle sur des architectures réparties basée temps réel servant au pilotage de robots par commande numérique

Moi j'aimerais bien du multi core parce que mon Eudora pete un plomb au premier demarrage quand je lui demande de check les mails, il fait 100% d'utilisation CPU pendant 1 minute c'est bien lourd je peut rien faire d'autre

Beuuuuh ... pourquoi tu fais poa ça sur le serveur du forum ?  

> masklinn : tourne mieux pkoi en valeur intrinsèque (pas relative à un goulot d'etranglement cache/ram etc ...) ? si on cherche à comparer un monoproc avec deux proc/core (de mm gabarit à l'unité) en utilisation intensive autant dire que 2 > 1, ça avance vachement. tu penses qu'un pc qui aurait 2*1500+ serait aussi performant qu'un 3000+ ? (à P-rating comparable evidemment)
 
> TNZ : dans ce cas on prend plusieurs pc. encore que je sois pas sûr qu'une bonne parrallélisation du code ne donnerai pas le mm résultat.
 
> marc : qd faut faire le ménage, faut faire le ménage

Le multicore pour le grand public, c'est très bien car il sera beaucoup moins géné par tous les virus/spyware qui bouffent des ressources. Avec le multicore il ne s'en rendra même plus compte

... suivant l'architecture, le coeff varie entre 1.6 et 1.8. Le 2 absolu n'existe pas dans une architecture bi-proc (monocore).
 
... dans les grosses architectures réparties, les OS ne sont poa les mêmes d'une machine à l'autre puisque ceux ci sont choisis en fonction des tâches à effectuer. Et encore je ne te parle pas des problèmes de synchro et d'échanges de données plus lentes en réseau que sur un bus interne.

Ca va dépendre du nombre d'applis et de leur conception.
 
Avec une seule appli principale grande consommatrice et non multithreadée, le 3000+ sera beaucoup plus rapide mais inutilisable pendant que l'appli tourne. le 2*1500+ effectuera le traitement moins rapidement (de 50%) mais restera utilisable (puisque seul un core/proc bossera sur l'appli)
 
Si l'appli est bien multithreadée, les perfs seront au moins équivalentes, supérieures si tout est vraiment bien fait parce que moins de miss au niveau du cache des procos (à cache équivalent) et moins de locks (les threads bossant en //, moins de switching entre deux threads donc le scheduler bosse moins et moins d'overhead à ce niveau)
 
Si plusieurs applis grande consommatrice, le 2*1500+ va être beaucoup plus fluide sur toutes les applis, et plus rapide

Ben oui, moins d'overhead.
 
Mais faut que l'appli soit très bien multithreadée et s'y prète (algos massivement parallélisables par exemple).
 
En dehors du calcul scientifique tu trouveras pas grand chose qui répond correctement au cahier des charges
 
(et ça veut dire coder une appli pour chaque algo)
(et une appli massivement multithreadée c'est dur à coder )

au début je dois dire que j'étais enthousiaste qd on a commencé à voir du dual core. mais qd on y reflechit bien c'est surtout de la poudre aux yeux que des solutions logicielles peuvent palier (qu'elles soient à inventer ou qu'elles existent déjà). mais en ce moment c'est la mode de nous ré-inventer la roue et nous presenter ça comme qd chose de nouveau et, histoire de faire passer la pillule, "dont on bénéficera" (le dual core, les drm, l'iram et j'en passe ...).

Atlantis » oui et non, faut faire le tri dans tout les trucs qui sortent sur le marché. Certains sont de la poudre aux yeux (genre le wifi qui remplace un réseau filaire) et d'autres sont de vraies évolutions.
 
Dans le cas du multi processeur, ce qui gêne le plus, C qu'on s'aperçoit que les applis actuelles sont programmées par des gorets. CàD que ces applis n'utilisent pas le multi-threading qui existe depuis TRES longtemps sur le papier et dans les OS (depuis les années 70 en gros).
 
Pourquoi se faire chier à programmer proprement alors que les fondeurs de processeurs se tirent la bourre à coup de Ghz ? ... la prochaine génération de processeurs gommera les impasses algorythmiques
Ce genre de raisonnement m'a toujours fait bondir. Ne dit on pas : "C toujours les mauvais ouvriers qui ont les mauvais outils" ?

en gros on va encourager les gars à continuer à prog avec les pieds pour un peu que l'arret de l'escallade des frequences pouvait enfin justifier de chercher un code plus propre/adapté à l'archi ben on va avoir droit à des trucs encore plus mal prog puisque de "toute façon maintenant ça se verra encore moins". super quoi ...
et je suis de l'avis de fouge : on va surement avoir droit à de nouveau concept de spy / trojan / virus.

justement, les programmes mal conçus (monothread) verront leurs performances stagner. La mauvaise qualité de ces programmes sera alors encore plus flagrande. Avec les dualcore, les fréquences n'augmentent plus, mais la puissance général de la machine si.
 
Quant aux spyware et autre joyeusetés, effectivement, ils seront plus discret (modulo les goulots d'étranglement genre l'accès au net, l'accès aux DD)

la majorité des progs sur un pc est difficilement benchable, c'est ce ceux-là dont je me préoccupe, les autres (jeux etc) ça fait longtemps qu'ils font gaffe, ils ont une image de marque et une pub gratos (via les tests) à entretenir.

modulo
adjectif invariable
 
ALGÈBRE Congruence modulo p : relation d'équivalence entre deux entiers dont la différence est un multiple de p.

Lorsque tous les logiciels seront optimisés pour le multicore, on perdra le confort en multitache intensif que l'on a avec un bicore et des appli monothread.
Heureusement qu'on aura alors des CPU quad/octo-core

fouge : oui c'est pas faux . bonjour le bordel au niveau du scheduling si on veut garder un systeme modulable selon ses souhaits ...

en guise de up :
nouvelle roadmap
http://www.hardware.fr/html/news/?date=23-07-2005#7711
le x2 3800+, une bonne nouvelle :
http://www.hardware.fr/articles/58 [...] -3800.html

Un petit article d'Anand, très bien fait, où le mythe sur l'efficience du double core par rapport au pentium prend sa claque...
http://www.anandtech.com/cpuchipse [...] i=2484&p=4
Mais c'est vrai qu'intellectuellement l'approche d'AMD est plus satisfaisante...    

Notons que les Intel dualcore ne sont pas comparé aux Intel monocore "normaux" mais à des monocores avec l'HT désactivé.
Or on compare toujours à un CPU tel qu'il est utilisé dans la réalité.
Avant on comparait A64 VS P4-HT, maintenant on compare les Intel dualcore au A64 dualcore. Le gain est comparé au CPU monocore correspondant.
 
Si les A64 voit ses scores "exploser" par rapport au monocore c'est à cause de l'absence d'une technologie gérant le MT alors que les P4 avaient déjà l'HT.
Donc si le gain du dualcore chez Intel n'est pas aussi bon que chez AMD, c'est principalement à cause de l'HT déjà présent dans les monocores (et absent des P4-D).
Mais ça on l'avait tous +/- compris, il n'y a pas de mythe cassé.
 
Cependant d'un point de vue purement technique, le choix d'implémentation du dualcore d'Intel est "presque" aussi efficace que celle d'AMD bien qu'elle soit moins élégante. A ces faibles fréquences de fonctionnement en tout cas...

Entièrement d'accord avec toi, je crois que j'ai pensé plus vite que je n'ai écrit.
 

 
Je voulais dire que l'efficience du dual core AMD par rapport au single core AMD n'est pas bien meilleure que l'efficience du dual core Intel par rapport au single core Intel, et ce bien que l'approche d'AMD soit plus élégante.

Un petit guide des cpu AMD64/Intel, pour l'heure en desktop :
http://forum.hardware.fr/hardwaref [...] 2104-1.htm