Non mais on leur a pas dit que la course aux MHz c'était fini.

Au contraire, enfin un fondeur qui pense aux applications monothread ou aux applis dans lesquelles le thread principal est largement utilisé, en augmentant la fréquence !! Enfin ça repart de quelque part.

Bien d'accord. Les multis core c'est bien (cela peut dans certain cas augmenter le confort d'utilisation, même pour une utilisation basique de sa machine), mais l'augmentation du nombre de core à ces (grande) limites pour les applis courante.
On va avoir 4, 8 puis 16 cores ? et après ? Si c'est génial par exemple pour un serveur web qui doit traiter des milliers de requêtes en parrallèles, pour faire tourner ses applis courantes, ça ne pourra QUE servir à rien.
Les applis courantes (IE, FireFox, Office etc...) peuvent à la rigueur être un peu plus confortable à utiliser sur un dual core (genre execution du code Javascript sur un thread, le reste sur un autre...). M'enfin, cela ne donnera rien de révolutionnaire par rapport à un mono core.
Pour les jeux, bah, le dual offre un léger gain aujourd'hui, et le seul jeu qui se targue de gérer 5 threads simultanément n'est pas près de voir le jour.
C'est pour cette raison qu'au dela de 4 ou 8 cores, les gains pour une utilisation courante, dans l'état actuel des choses, n'apportera RIEN.

Donc, on risque une grave stagnation des perfs des PC domestiques.

Donc, maintenant que les multi core sont la (2 ou 4, ce qui est une avancée qui me semble nécessaire, bénéfique ET suffisante pour un moment) il faut continuer la course à la fréquence et la recherche de gain sur un core à fréquence égale (comme l'a très bien fait le Core 2 par rapport aux autres processeurs).

Salut

Etant sur Mac depuis 20 ans, les promesses d'IBM je connais bien ... c'est la loi de Murphy à l'envers, il faut rajouter 2 ans à la date de sortie et diviser l'annonce par deux ...

Un proto qui tourne à 6 ghz en labo ... ben voyons ... ils ont juste oublié de préciser la durée de vie du proc à cette fréquence (1/2 seconde) ...

Si je fais le plein de ma clio au nitrométhane : 0 à 200 km/h en 3,2 s ... sont fort chez Renault non ?

Bonjour à tous,
Vous avez tous raison aujourd’hui, mais demain les développeurs ce seront adaptés pour utiliser les processeurs au maximum de leurs capacités. On vous parle des processeurs de demain, vous nous répondez que les logiciels d’aujourd’hui ne les utilisent pas pleinement.
Soyez beaux joueurs, émerveillé vous de la prouesse technologique !

alors là, en tant que programmeur sur du hardware, j'ai un peu de mal à te croire que "demain", sous entendu "dans peu de temps",les programmes vont arrêter d'executer les tâches les unes après les autres pour tout faire en parallele.

Pour pouvoir appeler une fonction, il faut pouvoir lui donner à manger, et si la fonction qui va lui donner à manger est pas terminée, c'est assez difficile de commencer à travailler..

quand on voit le faible nombre d'applis ou l'interface graphique et les (gros) calculs tournent sur deux threads differents ...

Yep. On ne peut pas tout exécuter en parallèle.

1) Si ton boulot est d'acheter une pomme et une seule, à quoi ça sert d'être 10 à aller acheter la même pomme ? (gain de temps nul, voir grosse perte de temps à savoir qui va la payer).

2) Si par contre tu as une pomme et une poire à acheter, si tu as au moins 2 personnes, elles peuvent le faire en même temps et tu peux donc, en simplifiant, dire que tu acheteras le tout en 2 fois moins de temps qu'avec une personne.

3) Si, pour d'obscures raisons (uniquement compréhensible par des développeurs lobotomisés comme moi ), pour acheter la poire, tu dois d'abord avoir acheté la pomme, idem, ça ne sert à rien d'être 2, tu n'iras pas plus vite qu'en étant un.

4) Et si, pour acheter une pomme, il faut 5 mn et pour acheter une poire 30mn (vachement plus éloigné le marchand de poire ), bien que tu vas dédier 2 personnes à l'achat des ces 2 produits, tu mettras au final 30mn au lieu de 35 pour tout terminer. Ce qui est un faible gain !

Et dans de nombreux cas logiciels, 1) 3) et 4) sont vrais. Donc, multiplier les cores ne sert pas toujours à quelque chose.

Mais il est tout de même vrai, moyennant un peu d'efforts, que certains softs pourront gagner à s'adapter à cette nouvelle donne, à savoir dédier les différentes tâches dans différent threads: Cela donnera des fois de gros gains, d'autres fois de petits. Tout dépend du logiciel et des données à traiter.

Pourquoi ne pas penser que les processeurs vont embarquer des cores dédiers/spécialisés dans certaines tâches comme il a était dit recement ?
De toute maniere il n'existe pas une maniere de voir les choses (architecure des ordinateurs) et pour le moment le plus simple et encore d'augmenter le nombre de core ou/et la fréquence. Après on verra...

Les machines multi-procs existent depuis longtemps et les developpeurs et les constructeurs on déjà de l'experience dans ce domaine. On connait déjà les limites...

Est-ce que la présence du Cell sur la PS3 ne va pas faire avancer la connaissance des développeurs dans l'utilisation et la programmation en multi thread ?

Je veux dire: sur PC, pour l'instant, pas la peine de trop forcer dessus, il y a encore tant de machines mono-core en circulation.

Mais la PS3 étant monotype, j'imagine qu'ils vont fatalement se creuser dans ce sens.

Et ca finira (peut etre) par redescendre sur le monde info, non ?

On peut rêver ?

pour vraiment utiliser les multi coeur il faudrait commancer par avoir des systems d'exploitation qui sont optimiser pour le dual coeur

et faire bouger des geant comme micro$oft et apple ca prend du temps

Mais ils sont déjà multi thread les OS et puis pas la peine d'attendre les multi core pour faire du multi thread !!

Je ne sais pas trop comment c'est branlé, mais je peux t'assurer que ni MacOS X ni Vista ne sont réellement pensés pour du multi-coeur. Ils sont capables de se débrouiller, parce qu'ils ont été un peu modifiés pour, mais pas plus que ça, ils l'avouent eux-mêmes.

Les OS fournissent une gestion de threads. Ce n'est pas pour cela que les logiciels écris sur ces OS les utilisent. C'est bien différent.

Tu sais, déjà des tas de moteurs graphiques commencent à tirer parti du multi-thread. Ce n'est pas vraiment un problème de connaissance (tout développeur qui se respecte à au moins une fois dans sa vie eu besoin de créer un bout de code gérant des threads).

Non, le problème c'est surtout que l'intérêt actuellement n'est pas encore énorme, que cela demande de refaire des développement complet de librairies logiciels (couteux), que cela est plus complexe à réaliser, que le gain n'est pas forcemment incroyable dans tous les cas, et donc que cela prend du temps et de l'argent.

qd même, le simple fait que tu aies un bouton "annuler" sur une interface graphique prouve que t'as au moins 2 threads...dans certains langages c'est la norme (en Java par ex, en .NET je sais pas mais je présume fortement)




très bien expliqué...sans parlé que pour une tâche elle même (dans ton exemple acheter une pomme), on est pas forcément capable de la découper en sous-tâches qu'on peut paralléliser...



+1...c très marketting, parce que intuitivement, tout le monde croit que les gains sont linéaires, si une tache prend X temps sur un core, alors elle prendra x/2 avec 2 cores, ce qui n'est jamais le cas (ne serait-ce que parce qu'une partie sensible du temps va servir pour synchroniser les 2 processus), et qu'en pratique, comme ca a été très bien expliqué par SpadVIII, sauf cas précis, les gains sont marginaux...ce qui fait les super résultats du core2 duo, c'est surtout qu'ils ont optimisé les cores eux même, pas le fait qu'il y en ait 2...

tien jai le gout de macheter une pomme soudainement!

donc si l'acheteur de pomme et un utilisateur macintosh, celui qui utilise le pc est une poire... lol