IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Actualités Discussion :

La loi de Moore est elle encore pertinente ?

  1. #21
    Rédacteur

    Homme Profil pro
    Comme retraité, des masses
    Inscrit en
    avril 2007
    Messages
    2 978
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 80
    Localisation : Suisse

    Informations professionnelles :
    Activité : Comme retraité, des masses
    Secteur : Industrie

    Informations forums :
    Inscription : avril 2007
    Messages : 2 978
    Points : 5 151
    Points
    5 151
    Par défaut
    Salut!
    Seulement comme ça évolue trop rapidement on peut pas tout maîtriser.
    C'est vrai; alors, il faut faire des choix.
    Jean-Marc Blanc
    Calcul numérique de processus industriels
    Formation, conseil, développement

    Point n'est besoin d'espérer pour entreprendre, ni de réussir pour persévérer. (Guillaume le Taiseux)

  2. #22
    Membre actif
    Profil pro
    Inscrit en
    juillet 2009
    Messages
    162
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2009
    Messages : 162
    Points : 274
    Points
    274
    Par défaut
    Citation Envoyé par Bourgui Voir le message
    Tu me dis que mon exemple est faux , je veux bien, mais stp dit moi pourquoi il est faux, comment se comporte les processeur (ou cœur), et en quoi répartir des éléments d'une taches plutôt que les taches elles mêmes fait gagner du temps.
    Cela ne sert à rien de paralléliser tes taches "enregistre", "cherche", "recalcule" et "compte" pour un même acheteur puisque chacune de ces tâches est dépendante de la précédente (où alors tu es capable de débiter le compte du mec sans qu'il ait choisi son article ... ce qui est du vol )

    Sur un serveur d'application, chaque requête entrante est associée à un thread et chaque thread sera exécuté entièrement sur 1 proc. Dans l'exemple que tu donnes, le développeur n'a rien à gérer.

    On parle des développeurs mais moi je pense que tant que les langages n'intègrent pas intrinsèquement la notion de parallélisme dans leur syntaxe, on restera avec une gestion historique et complexe de ce parallélisme.
    Plus on abstrait cette notion, plus elle sera utilisée.

  3. #23
    Rédacteur

    Homme Profil pro
    Consultant / formateur Oracle et SQL Server
    Inscrit en
    décembre 2002
    Messages
    3 428
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Consultant / formateur Oracle et SQL Server

    Informations forums :
    Inscription : décembre 2002
    Messages : 3 428
    Points : 7 863
    Points
    7 863
    Par défaut
    Citation Envoyé par sparthane777 Voir le message
    La loi de Moore certes s'avère être dépassée mais restera quand-même la base de la technologie des processeurs : voir ici et ici
    Bonjour

    Je trouve assez extraordinaire d'arriver à justifier une phrase qui ne veut rien dire par un lien d'une extrême qualité ! (Grand merci pour ce lien).
    1) parler de "loi de Moore", ça a à peu près autant de sens que de parler de "loi d'Elisabeth Teissier". Il ne s'agit de rien de plus que d'une conjecture, d'une prédiction, d'une prévision.
    2) l'article explique que cette prédiction (pour peu qu'on trouve un consensus sur sa signification) a globalement toujours été fausse
    3) comment peut-on dire qu'une prédiction, serait "à la base de la technologie des processeurs", alors que cette technologie existait avant le prédiction, et que la prédiction s'est révélée fausse ??
    Consultant / formateur Oracle indépendant
    Certifié OCP 12c, 11g, 10g ; sécurité 11g

    Ma dernière formation Oracle 19c publiée sur Linkedin : https://fr.linkedin.com/learning/oracle-19c-l-administration

  4. #24
    Provisoirement toléré Avatar de sparthane777
    Profil pro
    Inscrit en
    avril 2010
    Messages
    318
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2010
    Messages : 318
    Points : 379
    Points
    379
    Par défaut
    Citation Envoyé par FR119492 Voir le message
    Salut!

    C'est vrai; alors, il faut faire des choix.
    Jean-Marc Blanc
    T'en fait pas pour mes choix mais merci
    In CODE we trust
    Loppsi (Brice, Sarkozy);
    fatal error : cannot call to unprivated function !

  5. #25
    Membre confirmé

    Homme Profil pro
    Ingénieur systèmes et réseaux
    Inscrit en
    août 2007
    Messages
    509
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur systèmes et réseaux

    Informations forums :
    Inscription : août 2007
    Messages : 509
    Points : 613
    Points
    613
    Par défaut
    Citation Envoyé par Gordon Fowler Voir le message
    [B][SIZE="4"]
    Dans une tribune publiée dans le magasine Forbes, l'ingénieur en chef doute fortement que la loi de Moore puisse encore s'appliquer aux processeurs (CPU) : « Les performances des CPUs ne peuvent plus doubler tous les 18 mois », constate-t-il, « et cela va poser un grave problème à de nombreuses industries qui reposent sur cette croissance des performances ».
    Je n'ai pas envie de lancer un débat trollesque mais je trouve que cet article n'est pas assez clair sur certains points.
    Déjà la définition de la loi de Moore n'est pas exacte. L'auteur en donne une définition précise :
    The backdrop to this issue is a paper written by Gordon Moore, the co-founder of Intel ( INTC - news - people ). Published 45 years ago this month, the paper predicted the number of transistors on an integrated circuit would double each year (later revised to doubling every 18 months). This prediction laid the groundwork for another prediction: that doubling the number of transistors would also double the performance of CPUs every 18 months.
    Elle stipule que c'est le nombre de transistors sur un circuit intégré qui doublera tous les 18 mois pas la performance du CPU. L'augmentation de la performance CPUs n'est qu'une conséquence directe de la loi Moore.
    Aujourd'hui, on constate que bien que la vitesse des CPU a baissé mais le nombre de transitors que l'on met sur un circuit a augmenté.

    Citation Envoyé par Gordon Fowler Voir le message
    La programmation dite linéaire consiste à exécuter les instructions les unes après les autres pour obtenir un résultat souhaité. La programmation parallèle consiste au contraire à décomposer les tâches pour les faire exécuter simultanément par différents CPU. On comprend aisément le gain de vitesse que peut représenter ce modèle.
    Programmation dite "linéaire"??? Tu parles de la programmation batch?? Cela fait plusieurs années (> 20) que l'on fait du temps partagé. Cela plusieurs années que les processeurs peuvent lire des blocs d'instruction.
    Il est bien possible de faire la programmation parallèle sur une architecture monocoeur. Sinon les librairies développées en C (pthread), en ou java (java.lang.Runnable) ou dans n'importe quel langage n'aurait pas lieu d'etre.


    Citation Envoyé par Gordon Fowler Voir le message
    Elle touchera aussi les développeurs. Surtout par manque de formation, précise-t-il. « Convertir la quantité gigantesque de programmes séquentielles (NDR : ou linéaires) existant pour les faire tourner sur une architecture parallèle est une formidable tache, qui est rendue encore plus difficile par la pénurie de programmeurs formés à la programmation parallèle ».
    Je ne sais pas pour d'autres, mais moi à la fac, j'en fais. On développe meme sur la PS3 pour faire des calculs matriciels.

  6. #26
    Expert confirmé

    Profil pro
    Leader Technique
    Inscrit en
    juin 2005
    Messages
    1 756
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Leader Technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2005
    Messages : 1 756
    Points : 4 165
    Points
    4 165
    Par défaut
    Citation Envoyé par Bourgui Voir le message
    Justement par rapport à ce que tu dis, imaginons un environnement avec un serveur où il y a 4 demandes en même temps pour la vente d'un produit.

    Version linéaire :
    proc1 : enregistre,cherche,recalcule,compte
    proc2 : enregistre,cherche,recalcule,compte
    proc3 : enregistre,cherche,recalcule,compte
    proc4 : enregistre,cherche,recalcule,compte

    Version parallèle :

    proc1 : enregistre,enregistre,enregistre,enregistre
    proc2 : cherche,cherche,cherche,cherche
    proc3 : recalcule,recalcule,recalcule,recalcule
    proc4 : compte,compte,compte,compte


    C'est simplifié mais en gros c'est ça, donc les 4 demandes de vente prennent le même temps
    Ce que B.AF suggérait c'était :

    Version linéaire :
    - proc1 : enregistre, cherche, recalcule, compte

    Version Parallèle :
    - proc1 : enregistre
    - proc2 : cherche, recalcule
    Lorsque proc1 et proc2 ont terminé :
    - proc3 : compte

    Dans la version linéaire, tu as la réponse en 4 temps.
    Dans la version parallèle, seulement en 3 temps.

    Du moins c'est la théorie, qui serait à peu près vrai à faible charge (si la machine n'a qu'une seule transaction à traiter, ou si tu fais du calcul lourd pour un seul utilisateur).

    Mais sur un serveur, lorsque la charge augmente et que le serveur doit traiter un grand nombre de transactions simultanées, tu as un problème de files d'attentes qui se rajoute :
    Tu n'as pas suffisament de processeurs pour traiter immédiatement toutes les opérations de chaque transactions.
    - Donc dans la version linéaire : Tu fais la queue une fois. Ton tour arrive sur le CPU, tu fais tes 4 opérations et tu as la réponse.
    - Dans la version parallèle, tu prends une première file d'attente pour le proc1 et tu exécutes les deux opérations. En même temps, tu prends une deuxième file d'attente pour le proc2 et tu fais ton opération. Une fois que les deux ont terminé (donc tu gardes la plus grande des deux durées : Attente1 + operation 1 + operation 2, Attente 2 + Opération 3), tu prends une troisième file d'attente pour avoir le processeur et exécuter la dernière opération.
    Donc tu passes de 1 attente + 4 opérations à 2 attentes + 3 opérations.

    Sachant que lorsque la charge augmente, la durée des opérations ne changent pas, mais les temps d'attentes augmentent avec la longueur des files...

    Et pour couronner le tout, une fois que tu as obtenu le CPU, tu peux avoir besoin d'autres ressources pour effectuer ton traitement (par exemple des accès disques ou réseau)... C'est alors que surviennent les risques de blocages et de famines...

    C'est toute la difficultée de la programmation parallèle, on ne peut pas découper n'importe quoi n'importe comment pour obtenir de meilleures performances. Il faut trouver la bonne architecture de découpage, et le bon ordonnencement des traitements.

    J'aurais limite tendance a dire la version linéaire : le proc n'est jamais en attente de la fin d'une tache vu qu'elles sont faites dans l'ordre donc pas de temps proc perdu.
    C'est plus compliqué que ça.
    Car en fait, même dans la version linéaire, tu vas faire des I/O (accès disques, réseaux...). Donc le processeur va être bloqué en attente des résultats.
    Avec un minimum de parallélisme, le processeur pourrait être utilisé pour faire autre chose. Par exemple, commencer les calculs d'une autre transaction...

    Donc il n'y a pas de réponse évidente à la question. Il faut savoir ce qu'on fait et ce qui se passe dans les traitements pour établir l'architecture qui donnera les meilleurs résultats :
    - En termes de temps de réponse.
    - En termes d'utilisation des ressources (charger au maximum les CPU pour qu'ils ne soient pas à se tourner les pouces alors qu'il y a des traitements en attente).

  7. #27
    Expert confirmé

    Profil pro
    Leader Technique
    Inscrit en
    juin 2005
    Messages
    1 756
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Leader Technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2005
    Messages : 1 756
    Points : 4 165
    Points
    4 165
    Par défaut
    Citation Envoyé par publicStaticVoidMain Voir le message
    Programmation dite "linéaire"??? Tu parles de la programmation batch?? Cela fait plusieurs années (> 20) que l'on fait du temps partagé. Cela plusieurs années que les processeurs peuvent lire des blocs d'instruction.
    Il est bien possible de faire la programmation parallèle sur une architecture monocoeur. Sinon les librairies développées en C (pthread), en ou java (java.lang.Runnable) ou dans n'importe quel langage n'aurait pas lieu d'être.
    Il n'a jamais été dit que la programmation parallèle était une nouveauté. Bien sûr elle existe depuis l'apparition des traitements interactifs dans l'informatique. A la base c'était pour rentabiliser au mieux les processeurs en servant un autre utilisateur pendant que le premier réfléchissait à ce qu'il voulait faire.

    Mais même si elle existe depuis longtemps, elle reste encore assez peu utilisée. Mis à part le système d'exploitation et les drivers de périphériques, la plupart des appli sont purement monotâches.
    En grande partie à cause de la difficulté pour paralléliser efficacement un problème séquentiel par nature !
    Depuis des années on a amélioré les performances des ordinateurs en faisant des processeurs plus rapides, afin que les traitements séquentiels soient plus performants.

    Le sujet de cette discussion, c'est qu'aujourd'hui, les concepteurs des processeurs n'arrivent plus à gagner en performances pures.
    Donc pour continuer à avoir des machines plus puissantes, à faire des traitements plus rapidement, il faut faire en sorte de se tourner vers le parallélisme.
    Or s'il est assez simple de multiplier les CPU sur un serveur et gérer des transactions indépendantes en parallèle, il est beaucoup plus difficile de découper efficacement une même transaction en éléments parallélisables.

  8. #28
    Provisoirement toléré Avatar de sparthane777
    Profil pro
    Inscrit en
    avril 2010
    Messages
    318
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2010
    Messages : 318
    Points : 379
    Points
    379
    Par défaut
    Citation Envoyé par Franck SORIANO Voir le message
    Car en fait, même dans la version linéaire, tu vas faire des I/O (accès disques, réseaux...). Donc le processeur va être bloqué en attente des résultats.
    Avec un minimum de parallélisme, le processeur pourrait être utilisé pour faire autre chose. Par exemple, commencer les calculs d'une autre transaction...
    Il y a pas les protocoles IRQ qui se chargent des périphériques ?
    In CODE we trust
    Loppsi (Brice, Sarkozy);
    fatal error : cannot call to unprivated function !

  9. #29
    Provisoirement toléré Avatar de sparthane777
    Profil pro
    Inscrit en
    avril 2010
    Messages
    318
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2010
    Messages : 318
    Points : 379
    Points
    379
    Par défaut
    Citation Envoyé par Franck SORIANO Voir le message
    Or s'il est assez simple de multiplier les CPU sur un serveur et gérer des transactions indépendantes en parallèle, il est beaucoup plus difficile de découper efficacement une même transaction en éléments parallélisables.
    Ou beaucoup plus simples, et moins gourmands en ressource que d'utiliser des multicores, mais l'inconvénient reste quand même le prix
    In CODE we trust
    Loppsi (Brice, Sarkozy);
    fatal error : cannot call to unprivated function !

  10. #30
    Expert confirmé

    Profil pro
    Leader Technique
    Inscrit en
    juin 2005
    Messages
    1 756
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Leader Technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2005
    Messages : 1 756
    Points : 4 165
    Points
    4 165
    Par défaut
    Citation Envoyé par sparthane777 Voir le message
    Il y a pas les protocoles IRQ qui se chargent des périphériques ?
    Les IRQ servent à interrompre le traitement en cours sur le processeur pour lui dire qu'un périphérique nécessite son attention.

    Dans un fonctionnement parfaitement linéaire et synchrone, si tu dois lire un fichier, il va falloire que tu positionnes la tête de lecture au dessus du cylindre que tu veux lire, donc que tu attendes que le mouvement mécanique soit terminé. Il faut aussi que tu attendes que le secteur à lire passe sous la tête...
    Tout ces temps d'attente sont relativement long. Le CPU aurait le temps de faire beaucoup de calcul pendant ce temps.
    Donc dans un fonctionnement purement linéaire, tu as de nombreux temps d'attentes qui sont perdus et qui pourraient servir à autre chose.

    Au contraire, avec un fonctionnement multi-tâche, tu as un premier traitement qui veut réaliser un accès disque. Il lance son I/O sur le périphérique et la tâche est bloquée jusqu'à ce que le périphérique ait terminé.
    Donc le processeur est libre et va commuter pour exécuter une autre tâche activable.
    Lorsque le périphérique a terminée son I/O, il va déclencher une IRQ pour que le processeur sache que l'opération est terminée. Il pourra alors rendre la première tâche activable, et elle reprendra son exécution dès que le CPU sera disponible...
    Mais on est déjà dans une architecture parallèle. Pour tirer parti de ce fonctionnement, il faut avoir quelque chose à faire pendant qu'on attend la fin de l'I/O.
    C'est comme ça qu'on peut faire du multi-tâche avec un seul CPU...

    Ou beaucoup plus simples, et moins gourmands en ressource que d'utiliser des multicores, mais l'inconvénient reste quand même le prix
    Désolé, je ne comprends pas ce que tu veux dire.

  11. #31
    Provisoirement toléré Avatar de sparthane777
    Profil pro
    Inscrit en
    avril 2010
    Messages
    318
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2010
    Messages : 318
    Points : 379
    Points
    379
    Par défaut
    Citation Envoyé par Franck SORIANO Voir le message
    Les IRQ servent à interrompre le traitement en cours sur le processeur pour lui dire qu'un périphérique nécessite son attention.

    Dans un fonctionnement parfaitement linéaire et synchrone, si tu dois lire un fichier, il va falloire que tu positionnes la tête de lecture au dessus du cylindre que tu veux lire, donc que tu attendes que le mouvement mécanique soit terminé. Il faut aussi que tu attendes que le secteur à lire passe sous la tête...
    Tout ces temps d'attente sont relativement long. Le CPU aurait le temps de faire beaucoup de calcul pendant ce temps.
    Donc dans un fonctionnement purement linéaire, tu as de nombreux temps d'attentes qui sont perdus et qui pourraient servir à autre chose.

    Au contraire, avec un fonctionnement multi-tâche, tu as un premier traitement qui veut réaliser un accès disque. Il lance son I/O sur le périphérique et la tâche est bloquée jusqu'à ce que le périphérique ait terminé.
    Donc le processeur est libre et va commuter pour exécuter une autre tâche activable.
    Lorsque le périphérique a terminée son I/O, il va déclencher une IRQ pour que le processeur sache que l'opération est terminée. Il pourra alors rendre la première tâche activable, et elle reprendra son exécution dès que le CPU sera disponible...
    Mais on est déjà dans une architecture parallèle. Pour tirer parti de ce fonctionnement, il faut avoir quelque chose à faire pendant qu'on attend la fin de l'I/O.
    C'est comme ça qu'on peut faire du multi-tâche avec un seul CPU...
    Ah oui ça remonte quand même à 2 ans
    Désolé, je ne comprends pas ce que tu veux dire.
    En fait, je voulais m'interroger sur l'avantage d'utiliser des technolgies multicores pour le développement en parallèle, si toutefois ça s'avérait utile.
    Mettons que demain je me prenne un Athlon X6 (eh ouais je suis un fou ), je veux dire on reproduirait 6 * le développement parallèle, ou bien c'est prédestiné à carrément autre chose les technologies multicores ?
    In CODE we trust
    Loppsi (Brice, Sarkozy);
    fatal error : cannot call to unprivated function !

  12. #32
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Manager / Cyber Sécurité
    Inscrit en
    mai 2004
    Messages
    9 985
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Manager / Cyber Sécurité

    Informations forums :
    Inscription : mai 2004
    Messages : 9 985
    Points : 27 493
    Points
    27 493
    Par défaut
    Bonjour,

    Ayant suivi une formation enseignant le parallelisme, je suis surpris de voir a quel point ce domaine est méconnu en informatique. D'ailleurs, ce que j'ai lu du débat jusqu'ici ne faisant que confirmer ce que je pensais.

    Il n'y a pas un, mais des parallelismes. Et c'est d'ailleurs ce qui fait sa force, meme si c'est aussi ce qui participe a sa meconnaissance.

    Si je reprend l'exemple :
    Version linéaire 1 :
    proc1 : enregistre,cherche,recalcule,compte
    proc2 : enregistre,cherche,recalcule,compte
    proc3 : enregistre,cherche,recalcule,compte
    proc4 : enregistre,cherche,recalcule,compte

    Version parallèle 1 :

    proc1 : enregistre,enregistre,enregistre,enregistre
    proc2 : cherche,cherche,cherche,cherche
    proc3 : recalcule,recalcule,recalcule,recalcule
    proc4 : compte,compte,compte,compte


    Version linéaire 2 :
    - proc1 : enregistre, cherche, recalcule, compte

    Version Parallèle 2 :
    - proc1 : enregistre
    - proc2 : cherche, recalcule
    Lorsque proc1 et proc2 ont terminé :
    - proc3 : compte
    La version lineaire 1 est en fait du parallelisme (cas tres particulier, qui ne sera efficace que dans de rares cas), de meme que les deux versions paralleles.
    La version parallele 2 est effectivement celle qui, dans le cas present, nous donne un meilleur temps, en ayant effectue une tache en 3 unites de temps au lieu de 4.
    Mais le calcul parallele adresse principalement des calculs longs, pour lesquels le gain va etre sur la duree globale, et non pas sur le fait d'avoir une tache en moins.

    Si on considere 4 processeurs, et un modele parallele en pipeline, on peut avoir la chose suivante (je passe volontairement la phase d'initialisation, et considere les calculs N a N+ ):

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    proc1 : enregistre N,  enregistre N+1,  enregistre N+2,  
    proc2 : cherche N-1,   cherche N,       cherche N+1, 
    proc3 : calcul N-2,    calcul N-1,      calcul N, 
    proc4 : compte N-3,    compte N-2,      compte N-1,
    Ce modele permet, si on enleve les phases d'initialisation et de finalisation, de diviser le temps total de calcul par le nombre de processeurs !! Le gain est colossal, a condition que le probleme soit modelisable sous forme de pipeline, ce qui n'est pas toujours le cas.

    Pour en revenir a la question premiere :
    Cela fait des annees que je milite pour le calcul parallele au sein des entreprises, mais je constate que l'idee actuellement la plus repandue est que ca ne sert a rien, il suffit de 2 choses :
    • multi-threader et laisser faire l'OS
    • acheter une machine plus puissante


    De ce que j'ai vu, les entreprises n'ont pas encore pris conscience que la loi de Moore (stricto-cinsu, c'est a dire en nombre de transistor ) est obsolete, et que donc leur sacro-sainte regle a la noix de changer de machine ne pourra continuer a fonctionner.

    Peut-etre que certains s'apercevront que le parallelisme est la meilleure solution. Meme si, je l'avoue, cela demande de former pas mal de monde. Mais que l'on commence deja par s'y mettre avec ceux qui ont des competences dans le domaine
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

  13. #33
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Manager / Cyber Sécurité
    Inscrit en
    mai 2004
    Messages
    9 985
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Manager / Cyber Sécurité

    Informations forums :
    Inscription : mai 2004
    Messages : 9 985
    Points : 27 493
    Points
    27 493
    Par défaut
    Citation Envoyé par sparthane777 Voir le message
    Mettons que demain je me prenne un Athlon X6 (eh ouais je suis un fou ), je veux dire on reproduirait 6 * le développement parallèle, ou bien c'est prédestiné à carrément aut' chose les technologies multicores ?
    Tu peux faire ce que tu veux : exécuter le même code sur des données d'entrées différentes, ou exécuter du code différent en fonction du processeur.
    Tu peux aussi utiliser 4 processeurs pour une tache, 1 pour une autre et le dernier libre pour l'OS ou écouter de la musique.

    Toutes les solutions sont envisageables. Le but est de trouver le meilleur rapport entre le temps de développement, la complexité de mise en oeuvre de la situation, le temps de calcul final, le type de processeurs à disposition, le nombre de processeurs, ...
    Le bon parallélisme tient compte de tous ces paramètres, et te sort un joli programme miracle qui optimise tout ça. Enfin en théorie bien sûr
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

  14. #34
    Provisoirement toléré Avatar de sparthane777
    Profil pro
    Inscrit en
    avril 2010
    Messages
    318
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2010
    Messages : 318
    Points : 379
    Points
    379
    Par défaut
    Citation Envoyé par gangsoleil Voir le message
    Tu peux faire ce que tu veux : exécuter le même code sur des données d'entrées différentes, ou exécuter du code différent en fonction du processeur.
    Tu peux aussi utiliser 4 processeurs pour une tache, 1 pour une autre et le dernier libre pour l'OS ou écouter de la musique.

    Toutes les solutions sont envisageables. Le but est de trouver le meilleur rapport entre le temps de développement, la complexité de mise en oeuvre de la situation, le temps de calcul final, le type de processeurs à disposition, le nombre de processeurs, ...
    Le bon parallélisme tient compte de tous ces paramètres, et te sort un joli programme miracle qui optimise tout ça. Enfin en théorie bien sûr
    Okay ... de ce que j'ai compris, le développement en plus du multicores optimise la répartition des tâches en fonction de toutes les données parmi lesquelles celles que tu as citées.
    C'est parfaitement clair, pour l'instant j'ai pas trop le temps de voir des tutoriels là-dessus, mais si un jour j'en ai l'occasion je penserais à ce thread et je suis ouvert à des tutoriels en C/C++ là-dessus.
    En tout cas, je vous remercie de ce briefing

    "Peut-être que certains s'apercevront que le parallélisme est la meilleure solution. Même si, je l'avoue, cela demande de former pas mal de monde. Mais que l'on commence déjà par s'y mettre avec ceux qui ont des compétences dans le domaine "

    J'approuve totalement
    In CODE we trust
    Loppsi (Brice, Sarkozy);
    fatal error : cannot call to unprivated function !

  15. #35
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Manager / Cyber Sécurité
    Inscrit en
    mai 2004
    Messages
    9 985
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Manager / Cyber Sécurité

    Informations forums :
    Inscription : mai 2004
    Messages : 9 985
    Points : 27 493
    Points
    27 493
    Par défaut
    Citation Envoyé par sparthane777 Voir le message
    le développement en plus du multicores optimise la répartition des tâches en fonction de toutes les données parmi lesquelles celles que tu as citées.
    Je précise un peu : le développement du parallélisme doit se faire en plus de l'utilisation des multi-coeurs.

    Si on prend, un PC standard avec un CPU a 4 coeurs, on peut envisager par exemple les scénarios suivants :
    Mode normal : firefox, winamp, un petit jeu à la con dans un coin, avec en arrière-plan Thunderbird et open-office. Chacun doit pouvoir disposer d'un peu de puissance de calcul, et pour cela il semble raisonnable de laisser l'OS gérer le truc.
    Mode gros jeu : la, incontestablement, le parallélisme explicite (c'est-à-dire que le jeu est développe pour utiliser plusieurs processeurs) devient intéressant : on calcule plusieurs choses en même temps sur les différents coeurs, et aussi sur le GPU de la carte graphique, qui se charge de l'affichage.
    Dans ce cas, l'OS ne doit pas avoir en charge la répartition des différents calculs sur les processeurs ni sur les coeurs.

    Ce mode est aussi applicable pour les PC que pour les serveurs, et pour tous les types d'applications. Mais il faut de la volonté, du temps, et de l'argent pour que ça commence à se démocratiser.
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

  16. #36
    Provisoirement toléré Avatar de sparthane777
    Profil pro
    Inscrit en
    avril 2010
    Messages
    318
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2010
    Messages : 318
    Points : 379
    Points
    379
    Par défaut
    Citation Envoyé par gangsoleil Voir le message
    Je precise un peu : le developpement du parallelisme doit se faire en plus de l'utilisation des multi-coeurs.

    Si on prend un PC standard avec un CPU a 4 coeurs, on peut envisager par exemple les scenarii suivants :
    Mode normal : firefox, winamp, un petit jeu a la con dans un coin, avec en arriere plan thunderbird et open-office. Chacun doit pouvoir disposer d'un peu de puissance de calcul, et pour cela il semble raisonnable de laisser l'OS gerer le truc.
    Mode gros jeu : la, incontestablement, le parallelisme explicite (c'est a dire que le jeu est developpe pour utiliser plusieurs processeurs) devient interessant : on calcule plusieurs choses en meme temps sur les differents coeurs, et aussi sur le GPU de la carte graphique, qui se charge de l'affichage.
    Dans ce cas, l'OS ne doit pas avoir en charge la repartition des differents calculs sur les processeurs ni sur les coeurs.

    Ce mode est aussi applicable pour les PC que pour les serveurs, et pour tous les types d'applications. Mais il faut de la volonté, du temps, et de l'argent pour que ca commence a se democratiser.
    Si on prend mon cas à moi qui veut profiter des nouveautés qui sortent parce que le métier me tiens à coeur, je vais dépenser un budget pour avoir une carte mère récente , une CG récente et un pross récente avec une alim de base adaptée à la conso ... je pense que c'est plus de la volonté qu'il faut, après les autres facteurs temps et argent relèvent plus de l'indécision .
    Enfin c'est perso mon avis. Je veux réellement apprendre en restant en veille technologique permanente.
    Sinon pour en revenir au multicores, les cartes mères permettent de les activer ou pas, donc effectivement ça change rien au développement en parallèle et linéaire, sur un Core, après quand on active tout les coeurs, faudrait surtout se mettre à la page, et développer des méthodes permettant d'optimiser le parallèle en fonction des coeurs présents dans le pross ... enfin, moi je me la sens tester sur du multicores un script par exemple permettant d'effectuer du parallèle.
    Bref, merci du renseignement, je reviendrais bientôt vers vous pour de plus amples informations
    In CODE we trust
    Loppsi (Brice, Sarkozy);
    fatal error : cannot call to unprivated function !

  17. #37
    Expert confirmé

    Profil pro
    Leader Technique
    Inscrit en
    juin 2005
    Messages
    1 756
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Leader Technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2005
    Messages : 1 756
    Points : 4 165
    Points
    4 165
    Par défaut
    Citation Envoyé par gangsoleil Voir le message
    Il n'y a pas un, mais des parallélismes.
    Oui, "programmation parallèle" c'est un terme générique qui désigne simplement le fait de faire plusieurs choses en même temps.
    Après il peut se décliner d'un grand nombre de façons (multi-threading, calculs vectoriels, ...).

    Si je reprends l'exemple :

    La version linéaire 1 est en fait du parallélisme (cas très particulier , qui ne sera efficace que dans de rares cas),
    Détrompe-toi. C'est le fonctionnement classique d'un serveur. Et c'est généralement ce qui donne les meilleures performances : Tu attends une fois pour obtenir le processeur, tu fais tes 4 opérations, tu as terminé.
    D'un point de vue, théorie des files d'attente, tu es dans la configuration où tu as une file d'attente unique, avec N guichets pour dépiler la file. C'est la configuration optimale qui permet de minimiser le temps d'attente des clients et d'utiliser au maximum chaque guichet.
    Dans les autres architectures, tu attends un processeur libre pratiquement à chaque opération.
    Dans le premier cas, tu fais la queue une fois. Tu arrives au guichet, tu réalises toutes tes opérations.
    Dans les autres cas, tu fais la queue une fois. Tu arrives au guichet, tu réalises une seule opération. Et tu retournes faire la queue pour pouvoir faire la deuxième.
    Dans les deux cas, les guichets travaillent de la même façon. Le nombre total d'opérations traitées est le même. Le temps de traitement est le même. Mais dans le deuxième cas, tu ajoutes de nombreux temps d'attente qui allongent les temps de réponse... le tout à charge constante.

    Si on considère 4 processeurs, et un modelé parallèle en pipeline, on peut avoir la chose suivante (je passe volontairement la phase d'initialisation, et considère les calculs N a N+ ):

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    proc1 : enregistre N,  enregistre N+1,  enregistre N+2,  
    proc2 : cherche N-1,   cherche N,       cherche N+1, 
    proc3 : calcul N-2,    calcul N-1,      calcul N, 
    proc4 : compte N-3,    compte N-2,      compte N-1,
    Ce modelé permet, si on enlève les phases d'initialisation et de finalisation, de diviser le temps total de calcul par le nombre de processeurs !! Le gain est colossal, à condition que le problème soit modélisable sous forme de pipeline, ce qui n'est pas toujours le cas.
    En fait, c'est la même chose que dans "linéaire 1", mais en pire : Le calcul se fait aussi en 4 temps, mais avec des synchronisations obligatoires entre chaque étape :
    Proc1 exécute "enregistre N". Il faut attendre que Proc2 ait terminé "cherche N-1" pour pouvoir enchaîner "Cherche N". Et si Proc2 termine "Chercher N-1" avant que proc1 n'ait terminé "Enregistre N", il va devoir attendre que Proc1 ait fini !
    Dans cette version, tu vas diviser le temps de traitement global par le nombre de processeurs, mais il faut ajouter les temps d'attente dûs aux synchronisations.
    Dans la version linéaire 1, tu n'as pas ces temps de synchronisation alors que tu divises également le temps de traitement global par le nombre de CPU du fait que tu traites une transaction par CPU.

    Mais dans la pratique, du fait des blocages, linéaire 1 et parallèle 2 seront identiques, car tu découpes ton traitement en tâches à exécuter, et l'OS va attribuer le CPU en fonction des tâches activables. Dès que le traitement d'une étape va bloquer sur une E/S, le CPU sera ré-attribué à une autre tâche, ce qui donnera parallèle 2 en pratique.

    Pour en revenir a la question première :
    Cela fait des années que je milite pour le calcul parallèle au sein des entreprises, mais je constate que l'idée actuellement la plus répandue est que ça ne sert a rien, il suffit de 2 choses :
    • multi-threader et laisser faire l'OS
    • acheter une machine plus puissante
    Pourtant comme tu l'as dit toi-même, multi-threader c'est déjà du calcul parallèle.
    Et oui, il vaut mieux faire confiance à l'OS pour attribuer le CPU aux threads activables plutôt que d'essayer de faire le travail à sa place.

    Je reprends ton exemple de Parallèle 2. Si tu affectes les tâches aux CPU sans qu'un CPU ne puisse servir à un autre traitement, tu vas rapidement rencontrer des problèmes de synchronisation : Les 4 opérations ne mettant pas exactement le même temps pour s'exécuter, le CPU qui exécute la tâche la plus longue sera rapidement saturé, tandis que les autres seront en famine...
    Si tu laisses faire l'OS, il fera en sorte que les CPU soient chargés au maximum de ce qui est exécutable.

    Citation Envoyé par gangsoleil
    Mode gros jeu : la, incontestablement, le parallélisme explicite (c'est-à-dire que le jeu est développe pour utiliser plusieurs processeurs) devient intéressant : on calcule plusieurs choses en même temps sur les différents coeurs, et aussi sur le GPU de la carte graphique, qui se charge de l'affichage.
    Dans ce cas, l'OS ne doit pas avoir en charge la répartition des différents calculs sur les processeurs ni sur les coeurs.
    Le jeu est un bon exemple où le parallélisme est intéressant en effet. Mais pas en attribuant explicitement les tâches aux CPU.
    C'est même un bon exemple d'inefficacité : le GPU ne peut exécuter que des calculs graphiques. Donc si les CPU sont saturés par exemple pour calculer l'IA, tu ne peux pas utiliser la puissance du GPU pour décharger le CPU.
    C'est un peu moins vrai dans l'autre sens, mais même dans ce cas, on ne fait pas un équilibrage dynamique de la charge entre "calcule par le GPU" ou calcul par le CPU.
    Donc on se retrouve avec une puissance de calcul d'un côté qui n'est pas utilisée, et une autre de l'autre qui est saturée !

    Bon dans ce cas, on ne peut pas vraiment faire autrement.
    Mais le principe reste le même si tu réserves manuellement les CPU pour des tâches données.

    Ca a un sens si tu fais du temps réel et que tu veux être sûr d'avoir un CPU disponible pour réagir à un événement donné critique, mais si tu cherches une utilisation optimale de ta puissance de calcul, il ne faut jamais qu'un CPU se tourne les pouces (ou alors il qu'a ce moment il n'y ait rien à faire).
    Et le meilleur moyen d'y parvenir, c'est de laisser l'OS attribuer le CPU aux tâches activables.

    Citation Envoyé par sparthane777
    Sinon pour en revenir au multicores, les cartes mères permettent de les activer ou pas, donc effectivement ça ne change rien au développement en parallèle et linéaire, sur un Core, après quand on active tout les coeurs, faudrait surtout se mettre à la page, et développer des méthodes permettant d'optimiser le parallèle en fonction des coeurs présents dans le pross ... enfin, moi je me la sens tester sur du multicores un script par exemple permettant d'effectuer du parallèle.
    Et bien si, si tu programmes en linéaire, tu ne multi-thread pas ton appli. Donc tu ne tireras profis des différents coeurs que si tu as d'autres applications à exécuter en même temps, ou que c'est un serveur qui exécute plusieurs transactions en même temps (mais dans ce cas, c'est le serveur qui est multi-threadé). Pour une appli cliente pure, ce n'est pas très intéressant. Tu as acheté de la puissance de calcul que tu n'utilises pas.
    Pour faire de la programmation parallèle dans ton appli, il faut la multi-threadée, mettre en place les synchros indispensables.
    Et ça ne servira probablement à rien dans l'hypothèse d'un serveur.

  18. #38
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Manager / Cyber Sécurité
    Inscrit en
    mai 2004
    Messages
    9 985
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Manager / Cyber Sécurité

    Informations forums :
    Inscription : mai 2004
    Messages : 9 985
    Points : 27 493
    Points
    27 493
    Par défaut
    Bonjour,

    Dans mon post, j'ai confondu deux cas. Merci de m'avoir corrigé.

    Concernant le calcul sur GPU, cela fait l'objet actuellement de tres nombreuses recherches, afin de pouvoir calculer dessus et aussi de pouvoir recuperer le resultat (ce qui est evident avec un CPU et qui ne l'est plus sur un GPU). Mais il s'agit la d'un autre debat.

    Concernant le fait de laisser un OS organiser les processus sur les differents coeurs disponibles, je ne suis pas d'accord avec toi pour dire que c'est la meilleure chose a faire. Ou tout du moins pas tant que les algorithmes des OS seront ceux qui sont actuellement implementes.
    Prenons un programme mono-threade, qui prend 100% d'un coeur. Faisons-le tourner sur une machine à 4 coeurs, avec un OS actuel, et regardons ce qui se passe :
    Le système te dit que le CPU global est utilisé à 25%, ce qui est vrai
    Si tu regardes la charge réelle par CPU, tu t'aperçois que ton processus se ballade un quantum sur un coeur, deux sur un autre, etc etc etc ... Ceci est également vrai sur des machines multi-processeurs.
    Dans ce cas précis, tu as 3 CPU qui ne font rien, et un qui tourne à bloc. Et plutôt que de dédier un CPU à cette tache, ce qui implique de ne pas avoir a recharger tous les registres et les mémoires caches, le système le ballade de partout, perdant un temps fou.
    D'ailleurs, si tu as l'occasion de faire le test en dediant un processeur du système à ta tache, tu verras le gain de performance (enfin la encore, ce n'est pas vrai, car ça va dépendre de la tache, et principalement de ses accès mémoires).


    Je pense que le problème du parallélisme est bien montré ici : il est nécessaire de l'adapter en fonction d'un très grand nombre de paramètres, et il est difficile de trouver des règles géneriques.

    On peut aussi évoquer le parallélisme utilisé par les physiciens, qui programment en Fortran. Pourquoi ce langage ?? L'une des raisons est qu'il existe des compilateurs qui sont capables de générer des codes parallèles à partir de code linéaire. Alors certes, on n'a pas le même gain que si le programme était écrit de manière parallèle, mais cela ne mobilise pas un informaticien en plus du physicien lors de la phase de developpement. Et le gain par rapport à un programme linéaire est tout même important d'après ce que j'ai compris.
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

  19. #39
    Membre averti
    Inscrit en
    décembre 2007
    Messages
    222
    Détails du profil
    Informations forums :
    Inscription : décembre 2007
    Messages : 222
    Points : 409
    Points
    409
    Par défaut
    Et moi qui croyais que le seul instrument fiable de traitement parallèle de l'information était le Yi-King...
    La sécurité de l'emploi
    "Ce n’est pas une pratique médicale sensée que de risquer sa vie en se soumettant à une intervention probablement inefficace afin d’éviter une maladie qui ne surviendra vraisemblablement jamais."
    Docteur Kris Gaublomme, médecin belge ("Vaccins et maladies auto-immunes")

  20. #40
    Expert confirmé

    Profil pro
    Leader Technique
    Inscrit en
    juin 2005
    Messages
    1 756
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Leader Technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2005
    Messages : 1 756
    Points : 4 165
    Points
    4 165
    Par défaut
    Citation Envoyé par gangsoleil Voir le message
    Concernant le fait de laisser un OS organiser les processus sur les différents coeurs disponibles, je ne suis pas d'accord avec toi pour dire que c'est la meilleure chose à faire. Ou tout du moins pas tant que les algorithmes des OS seront ceux qui sont actuellement implémentes.
    Prenons un programme mono-thread, qui prend 100% d'un coeur. Faisons-le tourner sur une machine à 4 coeurs, avec un OS actuel, et regardons ce qui se passe :
    Le système te dit que le CPU global est utilisé à 25%, ce qui est vrai
    Si tu regardes la charge réelle par CPU, tu t'aperçois que ton processus se ballade un quantum sur un coeur, deux sur un autre, etc etc etc ... Ceci est également vrai sur des machines multi-processeurs.
    Dans ce cas précis, tu as 3 CPU qui ne font rien, et un qui tourne à bloc. Et plutôt que de dédier un CPU à cette tache, ce qui implique de ne pas avoir à recharger tous les registres et les mémoires caches, le système le ballade de partout, perdant un temps fou.
    D'ailleurs, si tu as l'occasion de faire le test en dédiant un processeur du système à ta tache, tu verras le gain de performance (enfin la encore, ce n'est pas vrai, car ça va dépendre de la tache, et principalement de ses accès mémoires).
    La situation que tu décris n'est un problème que dans le cas où :
    1. La tâche dure suffisamment longtemps sans réaliser la moindre I/O ni synchronisation pour se faire préempter.
    2. Le traitement qui est aussi long est capable de travailler en ayant toutes les données dans le cache, sans jamais aller chercher de données en mémoire centrale.

    C'est quand même un cas assez rare. D'autre part, tu ne peux changer de coeur qu'à l'issue de la fenêtre de préemption (ou d'une synchronisation), et même à ce moment-là, il n'est pas dit que l'OS te réaffecte sur un autre.

    Mais la plupart du temps, tu n'utilises pas le CPU pendant plus de 15 minutes sans réaliser une E/S (ou alors il faut revoir ton algorithme...). Donc ta tâche va être suspendue en attente d'une E/S.
    Et au moment où elle pourra repartir, tu as tout intérêt à ce qu'elle reparte sur le premier CPU disponible, plutôt que de devoir attendre que celui sur lequel tu l'as affecté soit libre !

Discussions similaires

  1. [PHP 5.4] l'api réflexion est elle encore d'actu ?
    Par dedis dans le forum Langage
    Réponses: 1
    Dernier message: 21/08/2013, 13h48
  2. Réponses: 9
    Dernier message: 08/07/2011, 11h09
  3. Réponses: 113
    Dernier message: 30/12/2010, 23h32
  4. Réponses: 18
    Dernier message: 27/08/2010, 09h34
  5. Réponses: 6
    Dernier message: 23/12/2006, 17h36

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo