« le débat sur les multicores me fait rigoler vu que la majorité des programmes C, C++ ou Java n'exploitent pas non plus le multicore. »
Tout dépend le type de code. En Java, pour du code qui utilise du calcul intensif par exemple, avec beaucoup d'irrégularité mémoire (pointer chasing), on a des programmes aussi rapides qu'en C++ (à condition de faire du « vrai » C++, et pas du « C avec namespaces et templates » -- dans ce dernier cas, C gagne, mais pas forcément de beaucoup).
En Python, puisqu'on peut embarquer relativement simplement des fonctions C externes, il est dommage de ne pas avoir de « vrai » modèle de threads.
Dernière chose : l'argument du « de toute manière les codes actuels n'exploitent pas le multicore », bien qu'énonçant un fait véridique, n'est pas solide : jusqu'à il y a peu, l'intérêt d'utiliser du multiprocesseur en dehors de programmes serveur ou de certains programmes types (comme Photoshop/Gimp par ex) n'avait pas vraiment de sens. Maintenant qu'on est coincé à la même fréquence mais avec plus d'unités de calcul, il va falloir réapprendre à programmer pour inclure l'option parallèle. Parce que plusieurs coeurs c'est bien, mais s'ils doivent se partager non seulement la mémoire cache (4 Mo pour 2 coeurs c'est très bien, 4 Mo pour 4 ça devient pas très grand), mais aussi - et surtout - le bus mémoire, tes processus parallèles, pour peu qu'ils soient limités par l'accès à la bande passante mémoire, risquent de faire la gueule. Je ne parle même pas de la concurrence pour accéder à une carte réseau, ou un disque dur, etc. Le problème existait déjà avant, mais avec la présence de plusieurs coeurs, il s'amplifie.
En fait le multicore amène dans le grand public (et donc plus précisément aux programmeurs qui programment « pour » ledit grand public) des problématiques qui auparavant étaient réservées au domaine du calcul scientifique. Dans l'absolu, je préférerais de loin que tout soit programmé séquentiellement, car on s'enlève tout un tas de bugs potentiels, mais le fait est que je vois difficilement comment on peut se passer de paralléliser certains bouts de codes. Par exemple, un certain nombre de programmes qui permettent de faire du calcul scientifique sont faits en Python, avec derrière des bibliothèques mathématiques programmées en C. Bon, très bien. C'est juste dommage de ne pas pouvoir paralléliser les calculs quand ont sait qu'on a un système multicore. Idem pour tout ce qui est encodage, filtre pour images, etc.
[^] # Re: Grandiose
Posté par lasher . En réponse au journal Linuxfr en J2EE. Évalué à 7.
Tout dépend le type de code. En Java, pour du code qui utilise du calcul intensif par exemple, avec beaucoup d'irrégularité mémoire (pointer chasing), on a des programmes aussi rapides qu'en C++ (à condition de faire du « vrai » C++, et pas du « C avec namespaces et templates » -- dans ce dernier cas, C gagne, mais pas forcément de beaucoup).
En Python, puisqu'on peut embarquer relativement simplement des fonctions C externes, il est dommage de ne pas avoir de « vrai » modèle de threads.
Dernière chose : l'argument du « de toute manière les codes actuels n'exploitent pas le multicore », bien qu'énonçant un fait véridique, n'est pas solide : jusqu'à il y a peu, l'intérêt d'utiliser du multiprocesseur en dehors de programmes serveur ou de certains programmes types (comme Photoshop/Gimp par ex) n'avait pas vraiment de sens. Maintenant qu'on est coincé à la même fréquence mais avec plus d'unités de calcul, il va falloir réapprendre à programmer pour inclure l'option parallèle. Parce que plusieurs coeurs c'est bien, mais s'ils doivent se partager non seulement la mémoire cache (4 Mo pour 2 coeurs c'est très bien, 4 Mo pour 4 ça devient pas très grand), mais aussi - et surtout - le bus mémoire, tes processus parallèles, pour peu qu'ils soient limités par l'accès à la bande passante mémoire, risquent de faire la gueule. Je ne parle même pas de la concurrence pour accéder à une carte réseau, ou un disque dur, etc. Le problème existait déjà avant, mais avec la présence de plusieurs coeurs, il s'amplifie.
En fait le multicore amène dans le grand public (et donc plus précisément aux programmeurs qui programment « pour » ledit grand public) des problématiques qui auparavant étaient réservées au domaine du calcul scientifique. Dans l'absolu, je préférerais de loin que tout soit programmé séquentiellement, car on s'enlève tout un tas de bugs potentiels, mais le fait est que je vois difficilement comment on peut se passer de paralléliser certains bouts de codes. Par exemple, un certain nombre de programmes qui permettent de faire du calcul scientifique sont faits en Python, avec derrière des bibliothèques mathématiques programmées en C. Bon, très bien. C'est juste dommage de ne pas pouvoir paralléliser les calculs quand ont sait qu'on a un système multicore. Idem pour tout ce qui est encodage, filtre pour images, etc.