Intel présente ses processeurs Core de 8eme génération, Réactions à la publication du 21/08/2017 |
Bienvenue invité ( Connexion | Inscription )
Intel présente ses processeurs Core de 8eme génération, Réactions à la publication du 21/08/2017 |
22 Aug 2017, 14:09
Message
#31
|
|
Macbidouilleur d'Or ! Groupe : Membres Messages : 7 134 Inscrit : 24 Sep 2015 Lieu : Pays d'Aix Membre no 196 570 |
« All problems in computer science can be solved by another level of indirection »
Sinon, pour ceux que cela pourrait intéresser, la discussion a commencé sur la mailing list Swift-evolution autour de la programmation concurrente pour le language swift, await/async/actor... https://gist.github.com/lattner/31ed37682ef...6bca1432ea9f782 https://lists.swift.org/pipermail/swift-evo...814/038892.html -------------------- Bobo du Pays d'Aix et Fanboy Apple
|
|
|
22 Aug 2017, 15:41
Message
#32
|
|
Macbidouilleur de bronze ! Groupe : Membres Messages : 392 Inscrit : 15 Aug 2017 Membre no 202 990 |
« All problems in computer science can be solved by another level of indirection » "All problems in human ressources can be solved by another layer of subcontractors." C'est de moi :-) Et je vous le déconseille si vous voulez du travail de qualité. C'était une boutade ou pas cette phrase à l'origine ? Ce message a été modifié par DonaldKwak - 22 Aug 2017, 15:42. -------------------- "Dites, monsieur le président, c'est vrai que comme dit mon papa vous nous espionnez sur internet ?"
"Il exagère. Et puis c'est pas ton père d'ailleurs" |
|
|
22 Aug 2017, 16:01
Message
#33
|
|
Macbidouilleur d'Or ! Groupe : Membres Messages : 7 134 Inscrit : 24 Sep 2015 Lieu : Pays d'Aix Membre no 196 570 |
Ha ha ... c’est ce qui se passe sur notre projet actuel... aussi du à la difficulté de recruter, le temps que cela prend.
La phrase à l’origine ... je ne sais pas, je la connais juste depuis une quinzaine d’années, je l’ai toujours prise pour un truc pas loin de la vérité, mais aussi, une alerte : attention solution facile !!! -------------------- Bobo du Pays d'Aix et Fanboy Apple
|
|
|
22 Aug 2017, 21:36
Message
#34
|
|
Macbidouilleur de bronze ! Groupe : Membres Messages : 392 Inscrit : 15 Aug 2017 Membre no 202 990 |
Sinon, petit coup de gueule (sympathique) :
- Pourquoi tout le monde veut connaitre la finesse de gravure des processeurs ? - Pourquoi mettre en avant le nombre de fils ? C'est rarement utile Personnelement, les infos suivantes m'intéressent : - Nombre de coeurs - Niveau des instructions vectorielles - Plage de fréquence - Taille du cache L3 - Bande passante de la RAM - Version du iGPU - Consommation - Ligne PCI, etc Bref le nombre de fils et la finesse de gravure, conme dirait ChiChi, ça m'en touche une... -------------------- "Dites, monsieur le président, c'est vrai que comme dit mon papa vous nous espionnez sur internet ?"
"Il exagère. Et puis c'est pas ton père d'ailleurs" |
|
|
24 Aug 2017, 07:18
Message
#35
|
|
Macbidouilleur d'Or ! Groupe : Membres Messages : 1 608 Inscrit : 1 Jul 2006 Membre no 63 808 |
Oui par contre 6 coeurs pour les 15", va falloir attendre quelques années avant que les logiciels en tirent partie Hors soft programmé avec les pieds, quand tu es capables de gérer 4 coeurs, tu peux en gérer 6, 10 ou 40 sans problème... même un mauvais étudiant après quelque cours de programmation parallèle le sait... Bien sûr que non. Ça dépend totalement de ton problème… Il peut très bien se découper naturellement en 4 trends, et être difficilement découpé en davantage. Exemple idiot : un jeu vidéo, avec un thread pour les graphismes, un thread pour l'IA, un thread pour le réseau et un thread pour synchroniser tout ça. Découper ça en 40 threads risque d'être bien compliqué… |
|
|
24 Aug 2017, 09:14
Message
#36
|
|
Macbidouilleur d'Or ! Groupe : Rédacteurs Messages : 32 183 Inscrit : 15 Nov 2005 Membre no 49 996 |
Exemple idiot : un jeu vidéo, avec un thread pour les graphismes, un thread pour l'IA, un thread pour le réseau et un thread pour synchroniser tout ça. Pas si idiot que ça comme exemple. Le jeux vidéos sont justement un exemple typique de produit qui gagne beaucoup en passant de 2 à 4 cœurs mais plus du tout au delà. Mais vraiment plus du tout, au point qu'un 8 cœurs avec ne serait ce que 10% de fréquence en moins qu'un 4 cœurs sera plus lent... Et même un 4 cœurs HT y est souvent plus lent qu'un 4 cœurs non HT.
-------------------- |
|
|
24 Aug 2017, 16:09
Message
#37
|
|
Macbidouilleur de bronze ! Groupe : Membres Messages : 392 Inscrit : 15 Aug 2017 Membre no 202 990 |
Exemple idiot : un jeu vidéo, avec un thread pour les graphismes, un thread pour l'IA, un thread pour le réseau et un thread pour synchroniser tout ça. C'est effectivement idiot :-) Programmer directement avec les threads, c'est comme programmer avec des gotos dans les années 70. Il faut programmer avec des task donner leur dépendances et avoir un runtime qui dispatch ces task sur les différentes threads matérielles. C'est le seul moyen de scaler correctement avec plusieurs coeurs. Malheureusement, les fadas de boost::thread et std::thread en C++ font tous la même erreur. Si vous voulez programmer uniquement sous macOS, il y a Grand Central Dispatch. Sinon, il y a de nombreuses bibliothéques comme TBB qui ont des pool de threads. Ce message a été modifié par DonaldKwak - 24 Aug 2017, 16:50. -------------------- "Dites, monsieur le président, c'est vrai que comme dit mon papa vous nous espionnez sur internet ?"
"Il exagère. Et puis c'est pas ton père d'ailleurs" |
|
|
24 Aug 2017, 17:05
Message
#38
|
|
Macbidouilleur d'Or ! Groupe : Membres Messages : 7 134 Inscrit : 24 Sep 2015 Lieu : Pays d'Aix Membre no 196 570 |
Exemple idiot : un jeu vidéo, avec un thread pour les graphismes, un thread pour l'IA, un thread pour le réseau et un thread pour synchroniser tout ça. C'est effectivement idiot :-) Programmer directement avec les threads, c'est comme programmer avec des gotos dans les années 70. Il faut programmer avec des task donner leur dépendances et avoir un runtime qui dispatch ces task sur les différentes threads matérielles. C'est le seul moyen de scaler correctement avec plusieurs coeurs. Malheureusement, les fadas de boost::thread et std::thread en C++ font tous la même erreur. Si vous voulez programmer uniquement sous macOS, il y a Grand Central Dispatch. Sinon, il y a de nombreuses bibliothéques comme TBB qui ont des pool de threads. C’est le principe de base au coeur de GCD, avec les closures, en C/C++/ObjC/Swift... il se démmerde au niveau du kernel pour répartir la charge entre toutes les requêtes des applications PS pour DonaldKwak : Et pour le moment en attendant Swift 5 ou 6... GCD est le modele pour la programmation concurrente en Swift, sur Linux inclu Précision, dans les premières discussion sur les additions pour la concurrence au niveau de Swift, sans doute que GCD restera comme couche basse.... les async/await/actor de la prochaines version de swift seront compilés en call vers GCD Ce message a été modifié par Hebus - 24 Aug 2017, 17:10. -------------------- Bobo du Pays d'Aix et Fanboy Apple
|
|
|
26 Aug 2017, 08:08
Message
#39
|
|
Macbidouilleur d'Or ! Groupe : Membres Messages : 1 608 Inscrit : 1 Jul 2006 Membre no 63 808 |
Exemple idiot : un jeu vidéo, avec un thread pour les graphismes, un thread pour l'IA, un thread pour le réseau et un thread pour synchroniser tout ça. C'est effectivement idiot :-) Programmer directement avec les threads, c'est comme programmer avec des gotos dans les années 70. Il faut programmer avec des task donner leur dépendances et avoir un runtime qui dispatch ces task sur les différentes threads matérielles. C'est le seul moyen de scaler correctement avec plusieurs coeurs. Malheureusement, les fadas de boost::thread et std::thread en C++ font tous la même erreur. Si vous voulez programmer uniquement sous macOS, il y a Grand Central Dispatch. Sinon, il y a de nombreuses bibliothéques comme TBB qui ont des pool de threads. Ce n'est pas ça qui va rendre ton programme automagiquement « embarassingly parallel ». Si ton programme est intrinsèquement séquentiel, tu auras beau utiliser toutes les astuces comme GCD que tu veux, il ne profitera pas de la présence de plusieurs cœurs... |
|
|
26 Aug 2017, 10:27
Message
#40
|
|
Macbidouilleur de bronze ! Groupe : Membres Messages : 392 Inscrit : 15 Aug 2017 Membre no 202 990 |
Ce n'est pas ça qui va rendre ton programme automagiquement « embarassingly parallel ». Si ton programme est intrinsèquement séquentiel, tu auras beau utiliser toutes les astuces comme GCD que tu veux, il ne profitera pas de la présence de plusieurs cœurs... Effectivement. Le parallélisme, c'est bien au programmeur de le trouver et de le décrire. Mais dans les cas où on a ce parallélisme, l'avenir est au dispatch de ces ressources par un runtime. Dans le calcul scientifique, on en est encore au dispatch des calculs par le programmeur. C'est la méthode utilisée par OpenMP (principalement) et MPI. C'est ultra old-school. Le dispatch dynamique pour la performance est disponible avec TBB (le précurseur était Cilk développé par des chercheurs du MIT). Mais cela ne marche que sur des ordinateurs à mémoire partagée. Pour les ordinateurs à mémoire distribuée (les clusters), pour le moment il n'y a rien car MPI est le roi ici et on ne peut pas faire plus statique. Il y a des gens qui travaillent dessus et certains projets : Open Community Runtime (Department of Energy/ Intel), HPX (Stellar Group), etc. Les runtime qui font le dispatch comme GCD ou TBB, c'est le futur. -------------------- "Dites, monsieur le président, c'est vrai que comme dit mon papa vous nous espionnez sur internet ?"
"Il exagère. Et puis c'est pas ton père d'ailleurs" |
|
|
27 Aug 2017, 21:23
Message
#41
|
|
Macbidouilleur d'Or ! Groupe : Membres Messages : 1 608 Inscrit : 1 Jul 2006 Membre no 63 808 |
oui, c'est au programmeur d'extraire le parallélisme… quand il existe, et c'est exactement ce que je dis : certains problèmes sont intrinsèquement séquentiels (ou avec degré de parallélisme limité).
Tu peux avoir assez de parallélisme pour alimenter 3 ou 4 processeurs, mais ne pas en avoir assez pour 6 ou 40 processeurs. |
|
|
28 Aug 2017, 20:30
Message
#42
|
|
Macbidouilleur de bronze ! Groupe : Membres Messages : 392 Inscrit : 15 Aug 2017 Membre no 202 990 |
Tu peux avoir assez de parallélisme pour alimenter 3 ou 4 processeurs, mais ne pas en avoir assez pour 6 ou 40 processeurs. Je suis d'accord. Mais c'est la raison pour laquelle il faut privilégier le parallélisme de données (par exemple convertir plusieurs images en parallèle) plutôt que le parallélisme de tâches (par exemple une thread fait des calculs sur une image tandis qu'une autre affiche des informations à l'écran). Le second type de parallélisme ne scale pas alors que le premier peut scaler si les communications ne prennent pas le dessus. Pour Lightroom, par exemple, l'export devrait profiter du parallèlisme de données et devrait scaler sans problèmes à de nombreux processeurs. Malheureusement, cela n'est pas le cas ! Donc, de nombreux softs peuvent scaler sans problèmes. Si ils ne scalent pas, c'est simplement parce qu'ils ne font pas ce qu'il faut faire (manque de temps ou manque de compétence). -------------------- "Dites, monsieur le président, c'est vrai que comme dit mon papa vous nous espionnez sur internet ?"
"Il exagère. Et puis c'est pas ton père d'ailleurs" |
|
|
Nous sommes le : 28th March 2024 - 16:15 |