IPB

Bienvenue invité ( Connexion | Inscription )

2 Pages V  < 1 2  
Reply to this topicStart new topic
> Intel présente ses processeurs Core de 8eme génération, Réactions à la publication du 21/08/2017
Options
Hebus
posté 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
Go to the top of the page
 
+Quote Post
DonaldKwak
posté 22 Aug 2017, 15:41
Message #32


Macbidouilleur de bronze !
**

Groupe : Membres
Messages : 392
Inscrit : 15 Aug 2017
Membre no 202 990



Citation (Hebus @ 22 Aug 2017, 15:09) *
« 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"
Go to the top of the page
 
+Quote Post
Hebus
posté 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
Go to the top of the page
 
+Quote Post
DonaldKwak
posté 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"
Go to the top of the page
 
+Quote Post
flan
posté 24 Aug 2017, 07:18
Message #35


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 1 608
Inscrit : 1 Jul 2006
Membre no 63 808



Citation (otto87 @ 21 Aug 2017, 15:10) *
Citation (Eagle Kiss @ 21 Aug 2017, 13:44) *
Oui par contre 6 coeurs pour les 15", va falloir attendre quelques années avant que les logiciels en tirent partie rolleyes.gif

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é…
Go to the top of the page
 
+Quote Post
SartMatt
posté 24 Aug 2017, 09:14
Message #36


Macbidouilleur d'Or !
*****

Groupe : Rédacteurs
Messages : 32 183
Inscrit : 15 Nov 2005
Membre no 49 996



Citation (flan @ 24 Aug 2017, 08:18) *
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.


--------------------

Go to the top of the page
 
+Quote Post
DonaldKwak
posté 24 Aug 2017, 16:09
Message #37


Macbidouilleur de bronze !
**

Groupe : Membres
Messages : 392
Inscrit : 15 Aug 2017
Membre no 202 990



Citation (flan @ 24 Aug 2017, 08:18) *
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"
Go to the top of the page
 
+Quote Post
Hebus
posté 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



Citation (DonaldKwak @ 24 Aug 2017, 17:09) *
Citation (flan @ 24 Aug 2017, 08:18) *
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
Go to the top of the page
 
+Quote Post
flan
posté 26 Aug 2017, 08:08
Message #39


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 1 608
Inscrit : 1 Jul 2006
Membre no 63 808



Citation (DonaldKwak @ 24 Aug 2017, 17:09) *
Citation (flan @ 24 Aug 2017, 08:18) *
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...
Go to the top of the page
 
+Quote Post
DonaldKwak
posté 26 Aug 2017, 10:27
Message #40


Macbidouilleur de bronze !
**

Groupe : Membres
Messages : 392
Inscrit : 15 Aug 2017
Membre no 202 990



Citation (flan @ 26 Aug 2017, 09:08) *
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"
Go to the top of the page
 
+Quote Post
flan
posté 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.
Go to the top of the page
 
+Quote Post
DonaldKwak
posté 28 Aug 2017, 20:30
Message #42


Macbidouilleur de bronze !
**

Groupe : Membres
Messages : 392
Inscrit : 15 Aug 2017
Membre no 202 990



Citation (flan @ 27 Aug 2017, 22:23) *
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"
Go to the top of the page
 
+Quote Post

2 Pages V  < 1 2
Reply to this topicStart new topic
1 utilisateur(s) sur ce sujet (1 invité(s) et 0 utilisateur(s) anonyme(s))
0 membre(s) :

 



Nous sommes le : 28th March 2024 - 16:15