Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
2359 connectés 

 


 Mot :   Pseudo :  
 
 Page :   1  2
Page Suivante
Auteur Sujet :

[HFR] Actu : Coeurs virtuels et parallélisme pour SoftMachines

n°9309861
hyksos_sow​o
Posté le 26-10-2014 à 14:46:44  profilanswer
0Votes positifs
 

Reprise du message précédent :
De quoi tu parle?? Y'a aucun problème à faire du multi thread 'lourd' et efficace en C#. C'est même foutrement plus facile que en C/C++. On peut exécuter des bout de code à la volé par n'importe quel thread grâce au dispatcher. Pis le nouveau system de Task que Microsoft ont ajouté a .Net 4.0 simplifie encore plus.
 
Bien sur il faut savoir coder, il ne suffit pas de simplement faire une boucle for et mettre quelques mot clé de compilation pour que le compilateur te chi du code multi threadé..

mood
Publicité
Posté le 26-10-2014 à 14:46:44  profilanswer
 

n°9309870
raptor68
Pouet !
Posté le 26-10-2014 à 15:02:11  profilanswer
2Votes positifs
 

c'est précisément ce dont je parle, le développeur ne fait plus rien, il fait confiance aux technologies toute la journée, qu'ils savent coder ou non, certes c'est plus simple mais tout ce qui t'es masqué (parce que des choses sont masquées ) fait l'efficience de ton code (à mon avis)


Message édité par raptor68 le 26-10-2014 à 15:03:02
n°9309885
hyksos_sow​o
Posté le 26-10-2014 à 15:30:46  profilanswer
1Votes positifs
 

Pas sur de te suivre la... un mauvais programmeur n'essayera même pas de faire du code multi thread et la 'technologies' ne rendra pas son code multi thread non plus. (Sauf si on parle de la news présenté ici... qui à mon avis n'est que utopique, bonne sur papier mais impossible à implémenter de façon robuste)
 
Un mauvais programmeur qui essai de faire du code multi threadé en C# ne fera que de la merde, alors qu'un bon programmeur sera capable d'avoir un code qui scale aussi bien que sur C/C++.
 
Donc non la technologie ne fait pas tout pour toi, le programmeur fait toute la différence.

n°9310119
Gigathlon
Quad-neurones natif
Posté le 26-10-2014 à 19:50:51  profilanswer
0Votes positifs
 

Après réflexion, je décrète que ce papier est bel et bien un pétard mouillé.
 
Au mieux, ils peuvent proposer une solution de transition, mais c'est au niveau hard que se situe l'archaïsme qui bloque l'évolution : on en est encore à utiliser une architecture datant des premières machines multi-sockets...

n°9310510
fofo9012
Posté le 27-10-2014 à 10:01:00  profilanswer
0Votes positifs
 

Indépendamment du langage, du compilateur, des qualités du dev, le multithreading doit être pris en compte dans toute la chaîne de conception.  
Sur un cycle en V habituel idéalement on devrait :
- L'utilisateur doit définir les volumétries / criticités de temps de traitement
- Le fonctionnel doit réfléchir à définir des tâches autonomes,
- L'analyste / (le) développeur doi(ven)t réaliser chaque brique de manière autonome.
 
Actuellement on en est très loin :
- L'utilisateur pond son cahier des charges sans indiquer ces contraintes de volume / perf,
- Le fonctionnel travaille sur un truc séquentiel,
- L'analyste pont un algo séquentiel,
- Le développeur code le truc séquentiel en utilisant des variables globales à tout va,
- Les test unitaires / d'intégration sont OK,
- Les tests users sont KO parcque le temps de traitement est déplorable.
 
Après c'est le jeu du qui-qui-qu'a-tord :  
- Pour l'utilisateur, c'était évident que ça devait marcher rapidement,
- Le fonctionnel s'en fout, "c'est pas son boulot de réfléchir contrainte technique",
- L'analyste va dire qu'il n'avait aucun élément pour faire des tâches autonomes,
- Le développeur va essayer des options de compilation puis mettre ça sur le dos du compilateur.
 
Blâmer le proc / le compilateur / le développeur : c'est se voiler la face. Aussi bon chaque élément soit-il, il ne peut pas repenser 100% de la solution en multithread.
 

n°9310522
TNZ
Ryzen 9 5950X powered ...
Posté le 27-10-2014 à 10:26:11  profilanswer
1Votes positifs
 

:)
D'où l'importance de tenir la main de tout ce petit monde durant le cycle en V afin qu'à chaque étape, le mode de réflexion soit le parallélisme.  
 
Cf mon post en 1ere page ;)


---------------
"Mieux vaut demander à un qui sait plutôt qu'à deux qui cherchent." ... "Le plus dur, c'est de faire simple.", TNZ
n°9310579
MEI
|DarthPingoo(tm)|
Posté le 27-10-2014 à 11:33:48  profilanswer
0Votes positifs
 

barbare128 a écrit :

Cette startup n'est qu'une énième association de penseurs marketing avec option claquettes.>
 
Ouer, à 250 personnes, on est plus dans la start up. S'ils font de la pub pour leur deuxième tour de financement, c'est qu'on est pas loin du produit final.
 
Si ça permet d'exécuter des instructions à la volée sans recompiler, eh ben c'est une p*tin de bonne idée.
 
Genre faire travailler un core sur un registre et laisser passer que les instructions qui s'occupe de ce registre, et passer sur un second core les instructions qui le concerne. Bon en gros ce serrait ça ...
 
Mais c'est vraiment un sacré travail.
 
Chapeau.


C'est vrai que BitzBoys, Gigapixel et autres ont sorties des produits finis de leurs super technologies magiques... :o


---------------
| AMD Ryzen 7 7700X 8C/16T @ 4.5-5.4GHz - 64GB DDR5-6000 30-40-40 1T - AMD Radeon RX 7900 XTX 24GB @ 2680MHz/20Gbps |
n°9310591
MEI
|DarthPingoo(tm)|
Posté le 27-10-2014 à 11:42:38  profilanswer
0Votes positifs
 

fofo9012 a écrit :

Indépendamment du langage, du compilateur, des qualités du dev, le multithreading doit être pris en compte dans toute la chaîne de conception.  
Sur un cycle en V habituel idéalement on devrait :
- L'utilisateur doit définir les volumétries / criticités de temps de traitement
- Le fonctionnel doit réfléchir à définir des tâches autonomes,
- L'analyste / (le) développeur doi(ven)t réaliser chaque brique de manière autonome.
 
Actuellement on en est très loin :
- L'utilisateur pond son cahier des charges sans indiquer ces contraintes de volume / perf,
- Le fonctionnel travaille sur un truc séquentiel,
- L'analyste pont un algo séquentiel,
- Le développeur code le truc séquentiel en utilisant des variables globales à tout va,
- Les test unitaires / d'intégration sont OK,
- Les tests users sont KO parcque le temps de traitement est déplorable.
 
Après c'est le jeu du qui-qui-qu'a-tord :  
- Pour l'utilisateur, c'était évident que ça devait marcher rapidement,
- Le fonctionnel s'en fout, "c'est pas son boulot de réfléchir contrainte technique",
- L'analyste va dire qu'il n'avait aucun élément pour faire des tâches autonomes,
- Le développeur va essayer des options de compilation puis mettre ça sur le dos du compilateur.
 
Blâmer le proc / le compilateur / le développeur : c'est se voiler la face. Aussi bon chaque élément soit-il, il ne peut pas repenser 100% de la solution en multithread.
 


 
Il y a aussi beaucoup de problèmes qui ne sont pas parallélisable.
 
Genre l'info. de gestion, c'est très difficile à parallélisé, et même si c'est possible, c'est souvent pas fait, car la complexité de la gestion des erreurs induite par la parallélisation décourage de le faire, car soit on va prendre BEAUCOUP plus de temps à le faire, soit on va réduire la fiabilité du processus (ce que l'on ne veut absolument pas en principe).
 
Pour tout ce qui est du computing pu là c'est déjà parallélisable de fait en principe (c'est de l'algorithmie pure).
 
Après il y a le reste, souvent les jeux et applis pro. Mais là en fait on a pas attendu les compilos et CPU pour optimiser le code depuis des années.
 
La solution semble super cool sur le papier, semble révolutionnaire. Mais en pratique je crains que les gain soit faible et qu'au final ça ne soit que comme l'hyper threading, un peu bonus bienvenu mais tout sauf vital.
 
Et encore, l'HT a plus de sens vu qu'on a des centaines de threads en // aujourd'hui sur nos machines... :spamafote:


---------------
| AMD Ryzen 7 7700X 8C/16T @ 4.5-5.4GHz - 64GB DDR5-6000 30-40-40 1T - AMD Radeon RX 7900 XTX 24GB @ 2680MHz/20Gbps |
n°9310848
Gigathlon
Quad-neurones natif
Posté le 27-10-2014 à 15:48:09  profilanswer
0Votes positifs
 

fofo9012 a écrit :

Indépendamment du langage, du compilateur, des qualités du dev, le multithreading doit être pris en compte dans toute la chaîne de conception.


Joli sur le papier, sauf qu'en pratique ce que tu dis est complètement à côté de la plaque.
 
Le séquentiel est naturellement partout et souvent chercher à paralléliser l'exécution amène une surcharge de travail qui finit par diminuer les perfs dans tous les cas, juste encore plus avec peu de cores.
 
Regarde ce qui s'est passé avec les GPU, c'est le parfait exemple de cette réalité : on exécute bien en parallèle, mais les traitements en cours dans un même SIMD peuvent n'avoir strictement rien à voir entre eux, et ça dans l'optique d'optimiser le remplissage... malgré un nombre de threads énorme comparé au CPU.
 
 
A l'inverse, quand on voit Micro$oft et consorts "inventer" un nouveau foreach "parallèle", on peut se demander si le compilateur ne pourrait pas de lui-même vérifier si il y a des dépendances et adapter le code généré. Mais non, pour une raison obscure, il fallait créer un nouveau "parallel_foreach" paramétré.


Message édité par Gigathlon le 27-10-2014 à 15:53:37
n°9310884
MEI
|DarthPingoo(tm)|
Posté le 27-10-2014 à 16:18:39  profilanswer
2Votes positifs
 

Le compilateur ne fait qu'une analyse STATIQUE du code. Il n'a donc ni conscience des données, ni conscience de ce que le développeur espère réaliser.
 
Lorsque l'on introduit des mot clés où autres pour soit indiquer que l'on peux paralléliser la boucle (cas des annotations OpenMP), soit explicitement demander le threading (cas du Parellel.ForEach()), c'est pour donner explicitement l'information que ce code la précisément peut être parallélisé, car :
1. les données ne seront pas inter-dépendantes
2. l'ordonnancement n'a pas d'impact sur le traitement
 


---------------
| AMD Ryzen 7 7700X 8C/16T @ 4.5-5.4GHz - 64GB DDR5-6000 30-40-40 1T - AMD Radeon RX 7900 XTX 24GB @ 2680MHz/20Gbps |
mood
Publicité
Posté le 27-10-2014 à 16:18:39  profilanswer
 

n°9310963
fofo9012
Posté le 27-10-2014 à 17:58:37  profilanswer
1Votes positifs
 

Gigathlon a écrit :

fofo9012 a écrit :

Indépendamment du langage, du compilateur, des qualités du dev, le multithreading doit être pris en compte dans toute la chaîne de conception.


Joli sur le papier, sauf qu'en pratique ce que tu dis est complètement à côté de la plaque.
 
[...]
 
on peut se demander si le compilateur ne pourrait pas de lui-même vérifier si il y a des dépendances et adapter le code généré. Mais non, pour une raison obscure, il fallait créer un nofonctionuveau "parallel_foreach" paramétré.

Justement, les compilateurs, depuis des années, parallélisent ce qui est est possible. Le pb est que rien ne remplace un(e équipe de) cerveau(x).
Un compilateur travaille en bas niveau, il ne peut pas savoir si fonctionnellement telle ou telle étape peut être parallélisée. Ce savoir l'équipe de conception l'a !
Charge à eux de concevoir des modules indépendant ensuite le dev, voir le compilateur se charge du reste.
 
Un truc tout con mais une variable réutilisée partout (par fainéantise / (pseudo)optimisation) va généré une dépendance pour le compilateur au moment de la  compilation qui risque d'empêcher une optimisation.

n°9311190
Singman
The Exiled
Posté le 27-10-2014 à 22:03:50  profilanswer
0Votes positifs
 

Mouai.... Disons que Softmachines réinvente les hyperviseur de type VMWare ou Xen, a un niveau différent. Parce que au final, on se rapproche très près de ce qui existe déjà chez eux.

n°9311443
Gigathlon
Quad-neurones natif
Posté le 28-10-2014 à 09:41:41  profilanswer
0Votes positifs
 

fofo9012 a écrit :

Un truc tout con mais une variable réutilisée partout (par fainéantise / (pseudo)optimisation) va généré une dépendance pour le compilateur au moment de la  compilation qui risque d'empêcher une optimisation.


Seulement en cas d'utilisation de cette variable dans la boucle, raison pour laquelle on évite.
 
Les types de boucles peuvent ou non être automatiquement parallélisées aussi, un while n'étant qu'un if-goto (CMP-JZ/CMP-JNZ) déguisé alors qu'un for peut le plus souvent être déroulé et un foreach seulement en connaissance du contexte (pour un tableau de taille connue ça roule, pour une liste ça roule pas du tout).
 
L'abstraction, rendue nécessaire par le saucissonnage en briques élémentaires et de plus en plus forte est par contre préjudiciable, on se met à remplacer des interruptions par des while car l'API s'occupe de gérer ça dans son coin, mais au final on y perd énormément.
 
On peut aussi réfléchir à ce qu'impose un modèle objet, dont l'origine est bien la même puisqu'une instance d'objet n'est rien d'autre qu'une structure atomique : quid de l'utilisation des caches? Quid du bazar impliqué par le threading dans une instance faisant elle-même partie d'une appli threadée?
 
Il faut surtout savoir utiliser ce qu'on a à disposition, et si définir des objets "pion/fou/cavalier/tour/reine/roi" dérivés d'un objet abstrait "piece" a du sens, l'échiquier lui-même a tout intérêt à être représenté par un simple tableau avec des index renvoyant au type de pièce présent sur chaque case, de façon à limiter la lourdeur de l'évaluation à plusieurs tours.

Message cité 1 fois
Message édité par Gigathlon le 28-10-2014 à 09:54:13
n°9311479
MEI
|DarthPingoo(tm)|
Posté le 28-10-2014 à 10:05:23  profilanswer
1Votes positifs
 

Gigathlon a écrit :


Seulement en cas d'utilisation de cette variable dans la boucle, raison pour laquelle on évite.
 
Les types de boucles peuvent ou non être automatiquement parallélisées aussi, un while n'étant qu'un if-goto (CMP-JZ/CMP-JNZ) déguisé alors qu'un for peut le plus souvent être déroulé et un foreach seulement en connaissance du contexte (pour un tableau de taille connue ça roule, pour une liste ça roule pas du tout).
 
L'abstraction, rendue nécessaire par le saucissonnage en briques élémentaires et de plus en plus forte est par contre préjudiciable, on se met à remplacer des interruptions par des while car l'API s'occupe de gérer ça dans son coin, mais au final on y perd énormément.
 
On peut aussi réfléchir à ce qu'impose un modèle objet, dont l'origine est bien la même puisqu'une instance d'objet n'est rien d'autre qu'une structure atomique : quid de l'utilisation des caches? Quid du bazar impliqué par le threading dans une instance faisant elle-même partie d'une appli threadée?
 
Il faut surtout savoir utiliser ce qu'on a à disposition, et si définir des objets "pion/fou/cavalier/tour/reine/roi" dérivés d'un objet abstrait "piece" a du sens, l'échiquier lui-même a tout intérêt à être représenté par un simple tableau avec des index renvoyant au type de pièce présent sur chaque case, de façon à limiter la lourdeur de l'évaluation à plusieurs tours.


Non mais la plupart du temps on conçois du code maintenable et clair, pas du code optimisable/optimisé.
 
Et si c'est trop lent, on optimise les portions à optimise, après profiling.
 
Dans l'absolue c'est jolie, c'est beau de vouloir faire du threading automatique, mais en avant nous vraiment besoin ? Dans quels cas ça apportera de vrai gain ?
 
Je pense que si Intel n'a pas suivi ce chemin, ni aucun autre constructeurs de CPU (y compris AMD qui a, à priori, exploré la piste), c'est parce que c'est bien plus rentable d'augmenter l'IPC au vu de la base de code que l'on a produite en plus de 50 ans et au vu de l'intérêt même de cette approche en terme de bénéfice/coût.
 
Car ça coûtera des transistors et des MHz tout ça hein.
 
Quand tu vois l'IPC d'un futur Broadwell, comparé à l'IPC d'un Banis, bon voilà, en 10 ans l'IPC a été plus que multiplié par 2, la fréquence idem, et les coeurs par 4. En 10 ans on a fait du x15-x20 en perfs brute à peu prêt...


Message édité par MEI le 28-10-2014 à 10:05:44

---------------
| AMD Ryzen 7 7700X 8C/16T @ 4.5-5.4GHz - 64GB DDR5-6000 30-40-40 1T - AMD Radeon RX 7900 XTX 24GB @ 2680MHz/20Gbps |
n°9313220
Singman
The Exiled
Posté le 29-10-2014 à 21:10:12  profilanswer
0Votes positifs
 

La programmation objet et sa généralisation effrénée des ces dernières années a introduit un alourdissement du code sans précédent dans l'histoire de l'informatique. L'utilisation des objets et donc l'abstraction que cela comporte rend extremement difficile l'optimisation par le compilateur ou par toutes autres méthodes intervenant après la compilation. Un code en objet est sensiblement plus lourd et plus lent que le même code en procédural. Mais le confort des programmeurs n'a pas de prix (c'est le cas de le dire...)

n°9313314
bjone
Insert booze to continue
Posté le 29-10-2014 à 23:26:21  profilanswer
0Votes positifs
 

J'ai pas test les Task de C#, mais en C++, un  
#pragma omp parallel for
c'est -justement- simplement faire une boucle for et mettre quelques mots clés de compilation pour chier du code multi-threadé :D
 
Après il y a aura toujours plus d'overhead qu'une queue de task faite maison avec amour, mais pour de la granularité moyenne, c'est top moumoute.
 
C'était une réponse à http://forum.hardware.fr/forum2.ph [...] 0#t9309861


Message édité par bjone le 29-10-2014 à 23:27:38
n°9313587
MEI
|DarthPingoo(tm)|
Posté le 30-10-2014 à 11:54:58  profilanswer
0Votes positifs
 

Singman a écrit :

La programmation objet et sa généralisation effrénée des ces dernières années a introduit un alourdissement du code sans précédent dans l'histoire de l'informatique. L'utilisation des objets et donc l'abstraction que cela comporte rend extremement difficile l'optimisation par le compilateur ou par toutes autres méthodes intervenant après la compilation. Un code en objet est sensiblement plus lourd et plus lent que le même code en procédural. Mais le confort des programmeurs n'a pas de prix (c'est le cas de le dire...)


Le vrai soucis c'est qu'aujourd'hui dans beaucoup de cas (voir la majorité en fait) c'est plus la puissance CPU ou la rapidité/quantité de mémoire/stockage le facteur limitant des perfs, les machines suivent quasi toujours (sauf usage de masse, mais souvent c'est plein de processus en // plutôt qu'un processus sur un gros jeu de données). Du coup faire du "beau" code reste primordial économiquement parlant.


---------------
| AMD Ryzen 7 7700X 8C/16T @ 4.5-5.4GHz - 64GB DDR5-6000 30-40-40 1T - AMD Radeon RX 7900 XTX 24GB @ 2680MHz/20Gbps |
n°9313699
bjone
Insert booze to continue
Posté le 30-10-2014 à 13:20:04  profilanswer
1Votes positifs
 

Singman a écrit :

La programmation objet et sa généralisation effrénée des ces dernières années a introduit un alourdissement du code sans précédent dans l'histoire de l'informatique. L'utilisation des objets et donc l'abstraction que cela comporte rend extremement difficile l'optimisation par le compilateur ou par toutes autres méthodes intervenant après la compilation. Un code en objet est sensiblement plus lourd et plus lent que le même code en procédural. Mais le confort des programmeurs n'a pas de prix (c'est le cas de le dire...)


Oui & non: c'est le programmeur et son niveau de maitrise du langage qui fait la vitesse d'un code (enfin l'algo/l'archi du bouzin et son cache-friendlyness en fait).  
En C++ tu ne payes pas pour ce que tu n'utilises pas, comme en C, c'est donc à toi de savoir ce que coûte ce que tu utilises.
Et je peux te dire que j'ai vu suffisamment de code en C et en (faux) C++ fait avec le cul pour savoir que le C++ peut parfaitement ne pas alourdir ni un projet, ni le temps d’exécution, mais au contraire: faire gagner du temps pour se focaliser sur les points chaud d'un code.
 


Message édité par bjone le 30-10-2014 à 19:08:11
n°9313704
MEI
|DarthPingoo(tm)|
Posté le 30-10-2014 à 13:22:27  profilanswer
1Votes positifs
 

Bah la STL par ex c'est by design fait pour être le plus rapide possible pour les fonctionnalités apportées.
 
Et le C++ est by design fait pour résoudre quasi tout soit dans le pré-processeur, soit dans le compilateur.
 
Donc en vrai la lourdeur induite par l'objet est faible et vrai essentiellement quand il y a polymorphisme.
 
On est pas dans .NET/Java & co non plus.


---------------
| AMD Ryzen 7 7700X 8C/16T @ 4.5-5.4GHz - 64GB DDR5-6000 30-40-40 1T - AMD Radeon RX 7900 XTX 24GB @ 2680MHz/20Gbps |
n°9315875
Profil sup​primé
Posté le 01-11-2014 à 21:57:07  answer
0Votes positifs
 

barbare128 a écrit :


 
Rien que le fait de le savoir, on sait tout de suite que c'est pas avant 30 ans qu'on aura franchit le cap du multithread ...


 
qu'est ce que tu veux dire par là ?

n°9317242
Singman
The Exiled
Posté le 03-11-2014 à 11:18:53  profilanswer
0Votes positifs
 

Vous me comparez le C avec le C++ alors que je vous fait une comparaison procédural / objet. Ca m'indique votre niveau de maitrise...

n°9317419
darkstalke​r
Saturn NTSC-J, What Else ?
Posté le 03-11-2014 à 14:31:47  profilanswer
0Votes positifs
 

Singman a écrit :

Vous me comparez le C avec le C++ alors que je vous fait une comparaison procédural / objet. Ca m'indique votre niveau de maitrise...


 
Non, tu racontes de la merde et ils te corrigent gentillement.
 
Bon, moi qui suis bien moins intelligent que singman, j'essaye toujours de comprendre ce qu'il y a de bien nouveau par rapport à un K5 (puis P6), son frontend, ses multiples unités d'execution out of order. Si on est passé à X coeurs au lieu de continuer à élargir un coeur, c'est bien qu'il y à une raison.
 
La couche logicielle magic-o-matique ?


---------------
Cyrix 5x86 120MHz, Tseng Labs ET4000/W32p VLB, Doom@45FPS <3
mood
Publicité
Posté le   profilanswer
 

 Page :   1  2
Page Suivante

Aller à :
Ajouter une réponse
 

Sujets relatifs
[HFR] Actu : Baisse de prix des APU AMD FM2+ et FM2[HFR] Focus : Enermax Twister Storm et Pressure en test
[HFR] Actu : Pilotes GeForce 344.48 WHQL[HFR] Actu : 1 Go de DDR4 en 20nm chez Samsung
[HFR] Actu : Broadwell-E en retard, RDV en 2016[HFR] Actu : Skylake-S LGA 1151 en image
Plus de sujets relatifs à : [HFR] Actu : Coeurs virtuels et parallélisme pour SoftMachines


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR