fin 2003 et 2004 : les années de l'informatique???

[Dandu]

A mon sens, il y a 5 moyens pour un CPU d'augmenter ses perfs, actuellement, mais elles ont toutes des défauts :s

1 : la classique, utilisée par Intel (et les autres) : on augmente la fréquence. le problème, c'est que pour augmenter la fréquence, on doit augmenter la taille du pipeline, et donc baisser le rendement. ce qui induit que on augmente la fréquence, mais on baisse l'efficacité, donc on est au même point.
Intel utilise ca avec le Netbusrt

2 : Augmenter la vitesse de communication vers l'extérieur, en boostant le FSB. On passe de bus SDR a des DDR ou QDR, voire des bus HT ou autres tres rapides.
Ils font tous ca :
K7 : DDR
K8 : lien HT
Pentium-M : P6 + bus QDR
P4 : bus QDR bien rapide


3 : technique plus maligne, mais moins facile a mettre en oeuvre : on augmente l'efficacité du CPU. On monte moins en fréquence (un CPU efficace a un pipeline court) mais on travaille plus a fréquence égale. reste que certains programmes dépendent plus de la vitesse que de l'efficacité.
Intel et AMD utilise ca, avec les Pentium-M et K7/K8

4 : Augmenter le cache. ca marche, mais c'est pas super efficace. ca coute cher, le gain est pas effectif pour toutes les application, un truc qui se contente de 512Ko ira pas plus vite avec 2Mo. c'est plus du bricolage que de l'optimisation réelle si on ne change pas le CPU derrière.
Pour moi l'augmentation du cache, c'est un leurre.

5 : le multi-core. Ca c'est spécial. en theorie, le gain est de 100%, mais en pratique c'est moins. Ca coute cher, ca chauffe plus (donc soit on met 2 CPU moins rapide, soit on a un monstre qui chauffe la maison).
Le gain en utilisation courante est faible, en tout cas avec windows.
Et le gros problème, c'est que on ne peut pas multi-threadé tout les programmes. Le gain sur un jeu est assez faible.
En fait, les quelques jeux optimisés SMP utilisent un CPU pour le rendu, et le deuxième pour des taches annexes, genre le son, l'IA et le moteur physique. Donc par exemple, sur UT 2004, on a un gain de 20/30% en activant le SMP (sur Mac, sur PC, je sais pas)



En fait, le truc qui marchent bien, mais demande un optimisation préalable, c'est les jeux d'instructions type SIMD (Altivec, SSE, SSE2). Bien utilisé, on a des gains appréciables sur pas mal d'applications.
Par exemple, sur Mac OS X (je me réfere au Mac parce que l'OS est récent, et bien optimisé SIMD/SMP) on a plus de gains en utilisant un G4 a la place d'un G3 de même fréquence que en passant de 1 a 2 G4.

toujours en me référant aux macs, il suffit de regarder ce qui c'est passé :

G4 :
on a un processeur efficace (pipeline court), on a des caches a mort (1Mo L2 et 2Mo L3 dans certains modèles), on a du Multicore (enfin du SMP normale, mais conceptuellement, c'est la même chose), on a aussi un jeu d'instructions SIMD tres performant.
Mais on a un bus lent (166SDR) et une fréquence assez basse (1500).

Conclusion, un G5, moins efficace a fréquence égale, avec moins de cache (seulement 512Ko L2), du SIMD moins performant (Altivec est moins efficace sur G5), met une claque au G4 parce que il va plus vite et a un bus tres rapide (1/2 CPU)




Finalement, pour ceux qui ont eu la patience de lire mon pavé, je pense que a part si on trouve une architecture qui travaille différemment (en vectoriel, ou tres efficae et tres rapide en même temps) la solution Intel avec le Netburst étaient le meilleur choix. Et je ne pense pas que le multi-core soit la revolution que on en fait, parce que les gains seront faibles, et que ca demande bcp de travail en plus au programmeur pour que ce soit efficace.

[johnnyholzeisen]

En parlant d'hétérogénéité...

Vous connaissez des lecteurs/graveurs optiques qui se connectent en SATA ?
On pourrait virer la dernière grosse nappe qui est dans les tours comme ça :wink:


Dandu :

Je veux bien que le SMP / SMT ne soit pas très utile quand on joue. Mais mon PC ne fais pas qu'une chose à la fois... Il y a par exemple l'antivirus en tâche chez moi.

Au bureau, les secrétaires sont souvent sur Word tout en ayant Outlook ouvert pour vérifier les mails.

Il arrive souvent qu'on tape une lettre dans Word en ayant un player multimédia qui joue notre musique préférée :wink:

Le gain n'est peut-être pas quantifiable, mais il est bien existant, non ?

[Dandu]

En parlant d'hétérogénéité...

Vous connaissez des lecteurs/graveurs optiques qui se connectent en SATA ?
On pourrait virer la dernière grosse nappe qui est dans les tours comme ça :wink:

Plextor fait un graveur DVD (mille formats) en SATA
MSI a un combo DVD/graveur CD en SATA
Le problème, c'est que ca marche pas avec tout les controlleurs SATA (je crois que il faut un Intel ICH5/ICH6) parce que la norme ATAPI est pas dans la norme SATA 1 (sont cons aussi)

Dandu :

Je veux bien que le SMP / SMT ne soit pas très utile quand on joue. Mais mon PC ne fais pas qu'une chose à la fois... Il y a par exemple l'antivirus en tâche chez moi.

Oui, mais l'antivirus tourne pas quand tu joue, il a rien a analyser, a priori.

Au bureau, les secrétaires sont souvent sur Word tout en ayant Outlook ouvert pour vérifier les mails.

Il arrive souvent qu'on tape une lettre dans Word en ayant un player multimédia qui joue notre musique préférée :wink:

je suis pas sur que le dual-core aie comme cible la bureautique. Outlook vérifie mes mails toutes les 5 minutes, et même avec word, excel, 5 ou 6 fenetres IE et Winamp je le vois pas (sur un Duron 500, donc pas précisément une bete de course)

Le gain n'est peut-être pas quantifiable, mais il est bien existant, non ?

Le gain y est, mais pas énorme. je crois que on va se retrouver avec des pubs genre : 2 processeurs en 1, ca va 2X plus vite, mais le gain, hors application bien spécifique (certains calculs math/3D/son) sera maximum 30 ou 40%.

En fait, ce qui me fait le plus peur avec du dual core, c'est que au lieu de nous mettre un CPU xxx a 2800, par exemple, on nous mette 2 core dans le même, mais seulement a 2200, par exemple, pour limiter la chauffe. et a ce moment la, c'est tres mal.

Si pour le même prix (je reve) ou un prix augmenté de maximum 50%, ils nous mettent le dual-core a la même vitesse que le mono-core, pourquoi pas, mais je doute.

a mon avis, ce sera soit moins rapide et pas trop cher, soit même fréquence, mais prix pratiquement doublé.

[EPIC]

Moralité : l'intéret d'une architecture Multicore, SMT, SIMD n'est valable que si les dévellopeurs prennent en compte les spécificités ce ces procs ce qui rallongera innévitablement les délais de dévellopement dû aux aux nombreuses optimisations qu'il sera nécéssaire de faire...

[eponge]

Moralité : l'intéret d'une architecture Multicore, SMT, SIMD n'est valable que si les dévellopeurs prennent en compte les spécificités ce ces procs ce qui rallongera innévitablement les délais de dévellopement dû aux aux nombreuses optimisations qu'il sera nécéssaire de faire...

Le fait de programmer de cette maniere viendra avec le temps... entre le 16 et le 32 bits ca a ete galere au debut... finalement maintenant tout le monde programme en 32 bits, on va dire "bientot" en 64.

et ces optimisations il faudra les faire une fois, on pourra les reprendre apres (je parle en gros hein)

[Dandu]

c'est même pas le problème du temps de dévellopement, c'est le problème de la complexité.

j'ai programmé pas mal pendant un moment, et franchement, faire du multi-thread, c'est pas evident du tout.

Donc le programmeur devra être assez calé pour faire du Multi-thread et faire un programme qui en tire parti :??:

conclusion, je dirais que on aura :

-20/30% des programmes bien optimisé (reellement multi-thread) : programmes pro, compression video/son

-20/30% des programmes (les jeux) utiliseront le deuxième CPU pour les taches annexes, genre IA/son, etc., sans reellement utiliser du multi-thread.

-le reste sera pas optimisé, ou tres peu, et on aura donc juste un confort d'utilisation un rien amélioré, comme avec l'hyper threading pour le moment. On aura un multi-tache plus efficace, ce sera deja ca.

[fofo]

Je trouves que vous dénigrez rapidement quelques technologies, qui ont fait pas mal avancé nos PCs :

• Les performances des cartes graphiques ont explosées.
  Avec ma config de 1997(3DFX2-12MO) je jouais à QuakeIII @ ~ 20FPS, aujourdui pour la meme resolution je à ~600FPS (Radeon 9600XT) soit 30X plus rapide et je vous parle pas de la qualité
  
• Ergonomie :
  Avant pour monter un PC(avec OS) il falait 3h, maintenant 1h30, tout gràce à une foule d'évolutions:
  
  * ATX / AT : ATX a été une révolution plus besoin de brancher tous les connecteurs, son intégré, et maintenant on a même le réseau / modem (donc 3 à 4 cartes PCI en moins)
  
  * Hot Plug : La deuxième révolution : Plus besoin de rebooter le PC pour brancher un modem ou souris (merci USB ), le serial ATA connexion à chaud des disques (pratique pour les Racks), et maintenant avec le PCIE on va même pouvoir ajouter / enlever es cartes à chaud uch:
  
  * Software : L'installation de windows c'est enfin simplifiée (pas de disquette de boot commandes dos à taper, installation semi-automatisée)...

Au contraire je trouve que CPU évolue de moins en moins. En 97 / 98 , en un an on est passé de PII-233 à PII-333 (70% plus rapide).
Y'a un an on était à 3GHz maintenant 3,6GHz (20% de +)

[Neo_13]

pour moi, la soluce a court termes, c'est plus de frequence, de cache...

mais a moyen terme ca passe par d'autres archi, notamment, pour moi, de type EPIC

[Minuteman]

Clairement, mais franchement je sais pas comment l'industrie va négocier la transition au niveau des softs...ça va être le bordel total.

[fofo]

c'est même pas le problème du temps de dévellopement, c'est le problème de la complexité.

j'ai programmé pas mal pendant un moment, et franchement, faire du multi-thread, c'est pas evident du tout.

[troll]
:heink: new Thread();
[/troll]
C'est pas dur de faire un thread, tout bon programmeur dans bien des cas utilise les threads.

Toutes les applications réseau sont basées sur les threads: Un qui attend une connexion sur un port l'autre qui communique sur un autre ...etc

Le problème est un problème de syncronysation :jap:

Donc le programmeur devra être assez calé pour faire du Multi-thread et faire un programme qui en tire parti :??:


Question de formation : Si on nous apprenais tout de suite à programmer avec les threads plutôt que de commencer par VB (goto, gosub ), ou du pascal (programmation bien linéaire comme sur mon Amstrad CPC464)

conclusion, je dirais que on aura :

-20/30% des programmes bien optimisé (reellement multi-thread) : programmes pro, compression video/son

-20/30% des programmes (les jeux) utiliseront le deuxième CPU pour les taches annexes, genre IA/son, etc., sans reellement utiliser du multi-thread.

-le reste sera pas optimisé, ou tres peu, et on aura donc juste un confort d'utilisation un rien amélioré, comme avec l'hyper threading pour le moment. On aura un multi-tache plus efficace, ce sera deja ca.

Faut être patient ça va venir le multicore n'est pas encore sortie, et HT est plus un argument commercial que du multi-cpu

[Neo_13]

Clairement, mais franchement je sais pas comment l'industrie va négocier la transition au niveau des softs...ça va être le bordel total.

dual core.... et registre pour choisir le core utilisé


ou plus sympa... shunt de la prédiction de branchement ou pas, suivant l'état d'un registre... comme ça, tu ne change pas les unités d'execution, par contre tu peux mettre plein de registres et d'unités d'exec... accessibles uniquement avec si le programme est "conforme" et sinon, fonctionnement standard (donc restreint)

[fennec]

Programmer en multithreadé n'est pas facile mais la pluspart des langage de très haut niveau (Java/C#) rendent la tache relativement facile. Le problème réel n'est pas de programmer pour sur SMP/SMT mais d'avoir réelement des parties de son programme indépendantes. Par exemple pour un programme de compression vidéos la pluspart des aglos de compression ont besoin de le frame précédante pour calculer la suitvante, pas question donc de pouvoir calculer une frame sur des sur chaque cpu. Ce problème est assez commun et il est assez difficile de découper un programme en plusieur thread efficasses au niveau répartition de de charge.

Un autre problème du SMP est l'acces aux ressources, un processeur (au niveau OS) ne peux contenir que des processus, ces processus peuvent contenir des thread mais un thread ne peut pas vivre tout seul. Qaund on a plusieur processeur sur plsieur CPU il faut partager les données et les ressources, c'est très très couteux car faut syncronizer les acces. Bien souvent les processus passent leur temps a s'attendre les uns les autres... et le programme monothread devient plus rapide que le multi!

le SMP oui mais dans des applications qui en ont vraiment besoin, et comme pour le 64bit c'est pas demain la veille

[Dandu]

Je trouves que vous dénigrez rapidement quelques technologies, qui ont fait pas mal avancé nos PCs :

• Les performances des cartes graphiques ont explosées.
  Avec ma config de 1997(3DFX2-12MO) je jouais à QuakeIII @ ~ 20FPS, aujourdui pour la meme resolution je à ~600FPS (Radeon 9600XT) soit 30X plus rapide et je vous parle pas de la qualité
  
  Surement, c'est plus beau et plus rapide, mais est-ce que le plaisir de jouer a changé ? j'ai rejoue é sur mon palm a indiana jones et la dernière croisade (un truc en EGA qui tournait sur 8086 avec ma ATI en Isa) et je ce jeu.
  
  Mais c'est un fait que la 3D c'est developpée extrement rapidement, mais on a une nouvelle architecture pratiquement tout les ans (alors que Intel c'est 2 en 10 ans : P6 en 95, Netburst en 2001)
  
  
• Ergonomie :
  Avant pour monter un PC(avec OS) il falait 3h, maintenant 1h30, tout gràce à une foule d'évolutions:
  
  * ATX / AT : ATX a été une révolution plus besoin de brancher tous les connecteurs, son intégré, et maintenant on a même le réseau / modem (donc 3 à 4 cartes PCI en moins)
  
  Et on se retrouve avec des trucs qui bouffent le CPU.
  Le seul intéressant, c'est la carte reseau.
  Les winmodem intégré, c'est Mal(tm) ca marche pas sans windows/sans MMX et ca bouffe le CPU
  Les cartes sons intégrées, a part le soundstorm, abandonné parce que trop cher, c'est pas génial, c'est parasité par la carte mère et ca bouffe plus de CPU.
  Essaye un jeu avec une carte son intégrée, puis avec une SB (même une bete Live) puis sans le son, et regarde la différence.
  
  * Hot Plug : La deuxième révolution : Plus besoin de rebooter le PC pour brancher un modem ou souris (merci USB ), le serial ATA connexion à chaud des disques (pratique pour les Racks), et maintenant avec le PCIE on va même pouvoir ajouter / enlever es cartes à chaud uch:
  
  L'USB :
  super, moins rapide que le PS2 pour la souris
  super nul en transfert de donnée par rapport au firewire (bridge pas efficace)
  fournit trop peu de courant, plein de trucs plante
  m'enfin, ca a l'avantage d'etre pratique.
  
  Le SATA a chaud, ca demande des racks adapatés, et pour se promener avec un disque, un rack externe en FW est plus indiqué.
  
  Le PCI-E hotplug, c'est pour les serveurs, t'en auras surement jamais dans une machine de bureau (faut dire l'interet est limité). et puis le PCI peut etre hot-plug aussi, je crois (certains serveurs le proposent)
  
  
  * Software : L'installation de windows c'est enfin simplifiée (pas de disquette de boot commandes dos à taper, installation semi-automatisée)...

Clair que demander les trucs en fin d'install (comme XP fait) c'est mieux que de demander n'importe quand (comme 98)

Sinon ca fait un moment que le CD est bootable quand même (NT4 et 98 le faisaient, je crois). Le problème c'est que les versions pirates ont rarement copié le secteur de boot, donc peu de gens sont au courant :D

Au contraire je trouve que CPU évolue de moins en moins. En 97 / 98 , en un an on est passé de PII-233 à PII-333 (70% plus rapide).
Y'a un an on était à 3GHz maintenant 3,6GHz (20% de +)

reste que tes 20% c'est 600Mhz, et que les 70 de l'autre, c'est 100Mhz.

Je trouve que ce qui a tres fort evolué ces dernières années, c'est la mémoire vive.

alors que jusque l'arrivée de la SDRAM ca a été lentement. entre 81, premier PC et 96/97, les premières SDRAM66, on a pratiquement pas evolué. la mémoire EDO d'un 486/20 est pratiquement la même que celle d'un P233MMX.

et maintenant, on est passé de SDRAM66 en 97 (533Mo/sec theorique, a peine 200 en pratique) a de la DDR2-667 en dual -> 6400Mo/sec

[fennec]

[b][troll]
:heink: new Thread();
[/troll]
C'est pas dur de faire un thread, tout bon programmeur dans bien des cas utilise les threads.

Toutes les applications réseau sont basées sur les threads: Un qui attend une connexion sur un port l'autre qui communique sur un autre ...etc

oui mais c'est plustot pour une question de "propreté" et pour avoir du code autonome. En C j'avais codé un serveur multi-utilisateur monoProcessus uniquement avec des select(). Ce que je veux dire c'est qu'au niveau client tu ne gagnes pas beaucoup de perf, voire rien

[Dandu]

c'est même pas le problème du temps de dévellopement, c'est le problème de la complexité.

j'ai programmé pas mal pendant un moment, et franchement, faire du multi-thread, c'est pas evident du tout.

[troll]
:heink: new Thread();
[/troll]
C'est pas dur de faire un thread, tout bon programmeur dans bien des cas utilise les threads.

Toutes les applications réseau sont basées sur les threads: Un qui attend une connexion sur un port l'autre qui communique sur un autre ...etc

Le problème est un problème de syncronysation :jap:

Donc le programmeur devra être assez calé pour faire du Multi-thread et faire un programme qui en tire parti :??:


Question de formation : Si on nous apprenais tout de suite à programmer avec les threads plutôt que de commencer par VB (goto, gosub ), ou du pascal (programmation bien linéaire comme sur mon Amstrad CPC464)

conclusion, je dirais que on aura :

-20/30% des programmes bien optimisé (reellement multi-thread) : programmes pro, compression video/son

-20/30% des programmes (les jeux) utiliseront le deuxième CPU pour les taches annexes, genre IA/son, etc., sans reellement utiliser du multi-thread.

-le reste sera pas optimisé, ou tres peu, et on aura donc juste un confort d'utilisation un rien amélioré, comme avec l'hyper threading pour le moment. On aura un multi-tache plus efficace, ce sera deja ca.

Faut être patient ça va venir le multicore n'est pas encore sortie, et HT est plus un argument commercial que du multi-cpu

Merci, mais quand je dis programmer des thread, c'est pas comme pour du reseau, ce que je veux dire c'est du code multi-thread qui utilise bien 2CPU, et correctement, pas pour gagner 5% de perfs.



Et moi, perso, on m'a appris a programme en C.

[johnnyholzeisen]

J'ai appris à programmer Ti-Basic (le langage des Ti-92+ et Ti89)

J'ai fait une année de C et je vais bientôt faire une année d'assembleur. En 3ème, je verrai le C++.

On ne m'a pas montré l'instruction "newThread()"

[fofo]

[HS mode="enabled"]

J'ai appris à programmer Ti-Basic (le langage des Ti-92+ et Ti89)

J'ai fait une année de C et je vais bientôt faire une année d'assembleur. En 3ème, je verrai le C++.

On ne m'a pas montré l'instruction "newThread()"

J'ai commencé en Amstrad Basic 1.0 :P
Ensuite du Ti-Basic à quel belle époque que le lycée
Ensuite ça s'enchaine Pascal, Delphi, ASM, C++, Java, C, C#(du java Avec Des Majuscules Partout :gun: ) pour les plus courants :jap:

Mon préféré reste le C/C++ (pour la vitesse :evil et le Java pour le coté pratique et multiplateforme
[/HS mode="enabled"]

euh l'instruction c'est new thread()

[fofo]

En C j'avais codé un serveur multi-utilisateur monoProcessus uniquement avec des select(). Ce que je veux dire c'est qu'au niveau client tu ne gagnes pas beaucoup de perf, voire rien

Ca dépend :
- du nombre de client
- du réseau (si tu test en localhost ça change rein en effet :jap
- Tu gagnes forcément énormément parce que tu as plusieurs clients traités en même temps le dernier client arrivé n'a pas a attendre que tous les autres aient fini par contre le premier pert un peu car il a pas tout le serveur à lui tout seul


En réseau tu fais souvent des threads parceque t'es obligé. A l'IUP on a fait un jeu de logique en réseau :
- 1 arbitre en C
- 1 joueur:
* réseau en C
* IA en Java/Prolog

Le problème c'est que chaque element ne sait jamais lequel va répondre en premier (notre IA trouvait une solution en entre 0,5" et 5"), mais l'arbitre pouvait envoyer un timeout

Mais là c'est un peu différent des threads pour du multi processeur.

L'idéal serait que le compilateur / OS gère automatiquement un thread par objet, ainsi plus les taches à réaliser son petite plus l'équilibre entre les proc est facile à réaliser. Pour cela faudrait des registres commun assez énorme pour ne pas perdre en temps de chargement / déchargement d'état processeur; Le problème c'est qu'un registre commun entre les deux corps ne peut pas être gèré à la compilation mais par l'OS qui devrait 'interpreter' l'assembleur

[fennec]

En C j'avais codé un serveur multi-utilisateur monoProcessus uniquement avec des select(). Ce que je veux dire c'est qu'au niveau client tu ne gagnes pas beaucoup de perf, voire rien

Ca dépend :
- du nombre de client
- du réseau (si tu test en localhost ça change rein en effet :jap
- Tu gagnes forcément énormément parce que tu as plusieurs clients traités en même temps le dernier client arrivé n'a pas a attendre que tous les autres aient fini par contre le premier pert un peu car il a pas tout le serveur à lui tout seul

si tu prends l'exemple d'apache tu peux traiter 100 clients avec 4 processus, tu n'a pas toujours autant de thread que de clients. Evidment c'est un cas bien spécifique de programme très optimisé et en générale on fait 1 client/1 thread.

Mais il faut faire attention, par exmple dans un jeu ou on aurait plein d'énemis, prenons serious sam par exmple, je ne pense pas qu'ils aient mis 1 thread pas enemis, pourtant ça pourrais être tentant au niveau conceptuel mais ça ne doit pas être très performant.

En réseau tu fais souvent des threads parceque t'es obligé. A l'IUP on a fait un jeu de logique en réseau :
- 1 arbitre en C
- 1 joueur:
* réseau en C
* IA en Java/Prolog

Le problème c'est que chaque element ne sait jamais lequel va répondre en premier (notre IA trouvait une solution en entre 0,5" et 5"), mais l'arbitre pouvait envoyer un timeout

Mais là c'est un peu différent des threads pour du multi processeur.

... tu as fais deprolog ... tu as toute mon admiration ça va tu te sens bien ? ce language est aussi atroce qu'inutilisé

L'idéal serait que le compilateur / OS gère automatiquement un thread par objet, ainsi plus les taches à réaliser son petite plus l'équilibre entre les proc est facile à réaliser. Pour cela faudrait des registres commun assez énorme pour ne pas perdre en temps de chargement / déchargement d'état processeur; Le problème c'est qu'un registre commun entre les deux corps ne peut pas être gèré à la compilation mais par l'OS qui devrait 'interpreter' l'assembleur

Oui mais un trhead par object c'est peut être pratique quand tu concoit ton système mais en ratique c'est pas top au niveau performance. Si tu prend lexemple de Java tu as une notion très intéressante qui a été introduite pas le système des "pool threads". Ce sont des groupes de threads virtuels dont tu peux te servir comme des threads normaux, mais en réalité la JVM ne va instancier des nouveax threads que si elle en a besoin, a savoir: si son flux d'éxecution se trouve bloqué sur une ressource ou un sémafore. C'est redoutable au niveau performance et ça ne coute rien de plus en dev, c'est juste un peut plus difficile a débugger.

[Minuteman]

Clairement, mais franchement je sais pas comment l'industrie va négocier la transition au niveau des softs...ça va être le bordel total.

dual core.... et registre pour choisir le core utilisé

On a vu ce que ça donnait avec l'Itanium: presque la moitié du core utilisé pour une émulation x86 foireuse, même Intel a reconnu que "c'était peut-être une erreur". Maintenant avoir 2 "vrais" cores performants c'est une possibilité mais un suicide économique

[Yasko]

- L'intégration de circuits reprogrammables (FPGA-like) haute-fréquence au sein d'un CPU.
- Le stockage de données dans un volume et non plus un plan (ou surface).
- le remplacement de l'électron par le photon :ave2:

Science-fiction ?

[Minuteman]

A mon avis un stockage de données massif sans pièces mécaniques serait déja un gros avantage...

[Yasko]

"J'ai la force, comme Anakin, j'opère au laser
..."

Edit :
Mais, bon, le(s) laser(s) faut bien qu'il bouge quand même
=> système mécanique
Ou alors le laser guidé électromagnétiquement... (dans le style d'un faisceau dans un oscilloscope).
Mais bon, v'la la précision que ca nécessite...

[Yasko]

Pour les threads, leur multiplication n'est pas forcement non plus une bonne chose. Ca complique grandement les choses et au dessus d'un certain seuil, c'est effectivement néfaste pour les performances.
Selon l'architecture de l'application, faut trouver les bons mécanismes.

C'est vrai qu'un thread par objet peut sembler intéressant. J'y vois un peu une analogie du monde réel :
Je suis un objet/individu
Je possède mes propriétés/attributs, caractéristiques et mes méthodes/possibillités, capacités
Je vie ma vie sans forcement avoir besoin des autres, mais avec qui je peux intéragir quand c'est nécessaire.
Il reste l'environnement autour de ces objets (la lumière pour se voir, l'air pour se parler et s'entendre, ..., des "services" tournant de manière continue), et la mémoire commune de tout ce petit monde ("tiens, y a 5 minutes, Robert m'a demandé de lui rendre son crayon").
Je sais pas, je suis peut être parti dans un délire là...
Je me suis souvent comparé ce monde virtuel au notre.

Dans le cadre de la parallélisation et du multithread, je me posais également une question.
Pourquoi implanter plusieurs cores assez indépendants les uns des autres ?
Parce que le multicore actuel, schématiquement, c'est un peu comme du SMP sur un seul et même die, avec une interface commune vers l'extérieur.
Pourquoi ne pas plutôt multiplier les unités de traitement d'un seul et même core, une seule et même conscience... (The MysticCPU... :heink: 'tain, faut que j'arrête). Nan, sérieux, la gestion des flux de données, des traitements par un superviseur qui aurait la vision de l'entité dans son ensemble, serait forcement plus efficace, plus réactive, plus je ne sais quoi...