Réseau CPC BIENDEBUTER.NET Crunchez vos adresses URL
|
Calculez la conso électrique de votre PC
|
Hébergez vos photos
+ Reply to Thread
Page 194 of 194 FirstFirst ... 94 144 184 186 187 188 189 190 191 192 193 194
Results 5,791 to 5,819 of 5819
  1. #5791
    Merci gluglu
    oui, oeuf corse: un seul process écrit. D'ailleurs un seul process créera le MMF et écrira dedans, les autres feront de la lecture voire du copy-on-write.

    Finalement, la question sera : performance d'un accès à un tableau versus accès via un stream (.NET, pas de pointeurs toussa).
    A moins que je puisse demander à un objet .NET managé de s'allouer dans le MMF mais faut pas rêver, je ne suis plus en C++... d'ailleurs c'est peut-être moins casse-gueule aussi...

  2. #5792
    Genre on peut faire ça en .Net ? C'est pas censé être managé et tout ?
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution." · 6hit combo!

  3. #5793
    Quote Originally Posted by TiNitro View Post
    Finalement, la question sera : performance d'un accès à un tableau versus accès via un stream (.NET, pas de pointeurs toussa).
    A moins que je puisse demander à un objet .NET managé de s'allouer dans le MMF mais faut pas rêver, je ne suis plus en C++... d'ailleurs c'est peut-être moins casse-gueule aussi...
    OK, tu as le choix entre MemoryMappedFile.CreateViewStream et MemoryMappedFile.CreateViewAccessor ?
    Ça dépend de l'implèm qui est dessous, mais vu que ça dérive de UnmanagedMemoryStream et UnmanagedMemoryAccessor respectivement, le wrapper ne doit pas être épais (bon, ça fait déjà beaucoup de shadokeries pour un simple pointeur...)

    Du coup si tu ne fais que des accès séquentiels, utilise un stream, sinon un accessor.
    Pour passer des objets .Net, tu es probablement censé passer par la sérialisation. Si c'est deux process différents, c'est deux VM .Net différentes avec chacun son GC, ses propres metadata associées aux objets et ses mécanismes de synchro. Si tu partages directement un objet managé entre les deux ça risque de mal se passer... Même si ça serait le plus efficace.
    Last edited by Møgluglu; 19/08/2014 at 16h33.

  4. #5794
    C'est un poil trop technique pour moi, mais regarde la version 4.5, ils ont bossé à mort sur le multi-thread sur cette version

  5. #5795
    Quote Originally Posted by Møgluglu View Post
    Pour passer des objets .Net, tu es probablement censé passer par la sérialisation. Si c'est deux process différents, c'est deux VM .Net différentes avec chacun son GC, ses propres metadata associées aux objets et ses mécanismes de synchro. Si tu partages directement un objet managé entre les deux ça risque de mal se passer... Même si ça serait le plus efficace.
    Du coup c'est mort niveau perf
    Profil Steam - Déteste le Java et les épinards

  6. #5796
    Quote Originally Posted by Møgluglu View Post
    Pour passer des objets .Net, tu es probablement censé passer par la sérialisation. Si c'est deux process différents, c'est deux VM .Net différentes avec chacun son GC, ses propres metadata associées aux objets et ses mécanismes de synchro. Si tu partages directement un objet managé entre les deux ça risque de mal se passer... Même si ça serait le plus efficace.

    Ouais c'pour ça que je disais faut pas rêver. En C++ je saurais allouer un objet sur une plage mémoire existante, là je ne voyais même pas comment ça pourrait fonctionner, je suis d'accord avec toi.

    @Tomaka: faut voir pour les performances, pas sur que ça dégrade les perfos par rapport à des objets managés du genre vecteur ou tableaux.
    Après, c'est sur qu'on va payer cher en managé par rapport à du code natif mais bon, j'ai pas le temps de former mon équipe et d'en faire des gens suffisamment experts en C++, sans compter qu'avec .Net il y a des facilité de développement et des bibliothèques qui valent leur pesant de cahouètes.

    Je vous tiens au courant...

    ---------- Post added at 17h39 ---------- Previous post was at 17h33 ----------

    Quote Originally Posted by deathdigger View Post
    C'est un poil trop technique pour moi, mais regarde la version 4.5, ils ont bossé à mort sur le multi-thread sur cette version
    Ouais mais ça ne change rien, en managé tu as une gestion de la mémoire centralisée, unique par processus et qui gère évidemment bien le multithread. Concrètement, c'est le run-time .net qui alloue et désalloue la mémoire.

    La ta mémoire est partagée entre plusieurs processus, il faudrait pouvoir lui dire dans tous les processus sauf un de ne pas s'occuper de la gestion mémoire sur ces objets. Bref, même si on y arrive, c'est une grosse bouse qu'on n'arrivera pas à maintenir et qui risque même de tomber sur une mise à jour du Framework.

    Je vais faire des tests: créer des classes .net avec des accesseurs qui tapent sur un stream, et pas de données membre à part l'offset. Du coup, pas de duplication des données, et on verra comment ça bombarde, je pense que je vais faire (ou faire faire hé hé hé gnark gnark .. pardon) un mini projet pour vérifier les performances.

  7. #5797
    Je fais des tests avec Mongodb, n'ayant fait que du SQL et du db2, c'est un peu déroutant. J'ai réussi à trouver une UI pas trop mal pour gérer les bases, mais je pense que l'apprentissage va être aride

  8. #5798

  9. #5799
    Bon, avant tout, je n'ai jamais fait de .NET, je dis peut être des conneries ().

    TiNitro, si j'ai bien suivi tu veux partager des objets entre plusieurs processus .NET ? Les MMF ont l'air d'être ce que recommande la doc .NET pour la communication entre plusieurs processus effectivement. (http://msdn.microsoft.com/en-us/libr...v=VS.100).aspx)

    Ton idée c'est d'écrire un MMF depuis un processus et y accéder via les autres comme un stream ?

    C'est pour écrire un fichier de sortie "once and for all" ou bien pour maintenir des objets persistant pour un programme qui tourne h24? Tu peux donner plus de contexte ou c'est trop critique?

    Tu peux pas avoir des pointeurs pointant vers le MMF pour les composantes simples de tes objets ? http://stackoverflow.com/questions/7...ed-file-in-net (semble être un peu dirty, mais vu ce que tu as dit, tu es prêt à supporter ce genre de risque )

  10. #5800
    Une petite étude marrante à propos des différents subreddits dédiés aux langages de programmation: https://github.com/Dobiasd/programmi...ster/README.md

    J'aime beaucoup ce graph (nombre d'utilisation du mot par 10000 commentaires) :

    Profil Steam - Déteste le Java et les épinards

  11. #5801
    Java n'est pas si mal placé.





    Il y aurait donc pire.

  12. #5802
    Quote Originally Posted by FB74 View Post
    Il y aurait donc pire.
    Si tu ne connais pas bien le PHP, je t'invite à lire le lien dans l'étude : http://eev.ee/blog/2012/04/09/php-a-...of-bad-design/
    Ainsi que ça : http://www.reddit.com/r/lolphp/
    Profil Steam - Déteste le Java et les épinards

  13. #5803
    Cela dit ce sont les langages les plus communs qui sont devant donc c'est pas si étonnant. Sur le graph une fois passé le C# (8ème) on arrive sur des langages plus confidentiels ou anciens.

    Enfin php et javascript méritent leur places, rien que pour les types, je n'en sais pas énormément mais j'me rend bien compte que quelque-chose ne tourne pas rond .

  14. #5804
    Quote Originally Posted by Sp1d3r View Post
    Bon, avant tout, je n'ai jamais fait de .NET, je dis peut être des conneries ().

    Ton idée c'est d'écrire un MMF depuis un processus et y accéder via les autres comme un stream ?

    C'est pour écrire un fichier de sortie "once and for all" ou bien pour maintenir des objets persistant pour un programme qui tourne h24? Tu peux donner plus de contexte ou c'est trop critique?
    Pour maintenir des objets; on peut le voire comme une optimisation, j'ai une machine avec n processus qui tournent, chaque processus utilisent beaucoup de mémoire dont une bonne partie est identique entre tous les processus. Je pourrait donc la partager au lieu de la dupliquer, et également la charger à l'avance pour accélérer le démarrage des processus. Je me demande si c'est plus clair maintenant...

    Quote Originally Posted by Sp1d3r View Post
    Tu peux pas avoir des pointeurs pointant vers le MMF pour les composantes simples de tes objets ? http://stackoverflow.com/questions/7...ed-file-in-net (semble être un peu dirty, mais vu ce que tu as dit, tu es prêt à supporter ce genre de risque )
    Le lien pointe vers une technique qui permet de faire une recopie de donnée, ce que je cherche à faire c'est à éviter cette duplication pour avoir un véritable partage. Chose que je peux faire en .NET en ayant des objets dont les accesseurs de propriétés accèdent au MMF suivant un offset donné. Chose que j'aurais pu faire en C++ en passant le pointeur sur le MMF à son opérateur new.

    Un test s'impose.

  15. #5805
    [EDIT] : Mauvaise section !
    Lol : Erthands. Starcraft 2 : Aldrian. Steam : slifaen. Wildstar : Linya (Treespeaker Exile). Lenara sur le mumble.

  16. #5806
    Coin,
    j'ai développé une simulation basée sur une bibli FEM C++ open source (Deal.II), que j'ai intégré dans un cycle de calcul de mon cru. Une image sera surement plus claire:


    Bref. Le Field Solver, c'est Deal.II donc c'est pas moi qui touche. Par contre, le machin appelé "Space Charge Weighting Scheme" (SCWS) est de mon cru. Pleins de For loops sur des cellules d'un maillage.

    Pour avoir vu pleins de références relatives à ce type de simulations, rendre le code capable de tirer parti de plusieurs cores pourrait réduire le temps requis par le SCWS. Sauf que j'y connais rien en multithreading . J'ai cru comprendre que scinder une énorme ForLoop en plusieurs loops plus petites, et réunir le tout au final était l'essence du multithreading. Ca tombe bien parce que c'est mon problème.

    On m'a conseillé une librairie (OpenMP) qui semble adaptée, mais j'aurais aimé des exos un peu plus pratiques que ceux fournis dans la doc de la librairie.

    Des ressources conseillées pour un noob comme moi?

    Merci
    Quote Originally Posted by Colargol View Post
    Mais globalement l'ingenieur en France il bosse un peu a l'africaine: ca marche mais ca fait pas serieux

  17. #5807
    Tu fais quoi avec ça BentheXIII ?

    Une particule qui se meut dans un plasma ?

  18. #5808
    "Une" particule? J'aimerais bien . Mais oui c'est l'idée.
    Quote Originally Posted by Colargol View Post
    Mais globalement l'ingenieur en France il bosse un peu a l'africaine: ca marche mais ca fait pas serieux

  19. #5809
    Quote Originally Posted by BentheXIII View Post
    "Une" particule? J'aimerais bien . Mais oui c'est l'idée.
    En fait t'étudies un plasma particule par particule en considérant les autres comme étant un nuage "pondéré" de charges.

  20. #5810
    J'ai en fait des macros particules que je tracke avec une description lagrangienne classique. Une macro particule a la masse de N particules et la charge de N particules. Je calcule une densité de charge rho avec le SCWS, qui est utilisée par le Solver pour résoudre Div E = rho/epsilon_0 . J'en déduit le champ, qui me donne la force modifiant la distribution de particules, and so forth.

    La "pondération", c'est dans l'évaluation de rho: rho est évaluée aux nodes du maillage, et j'utilise les fonctions d'interpolations associées au maillage pour pondérer la contribution de chaque macro-particule à la space charge.

    Mais on dévie du sujet la
    Quote Originally Posted by Colargol View Post
    Mais globalement l'ingenieur en France il bosse un peu a l'africaine: ca marche mais ca fait pas serieux

  21. #5811
    Quote Originally Posted by BentheXIII View Post
    Mais on dévie du sujet la
    Ouais.

    Mais c'est intéressant.

  22. #5812
    Quote Originally Posted by BentheXIII View Post
    Pour avoir vu pleins de références relatives à ce type de simulations, rendre le code capable de tirer parti de plusieurs cores pourrait réduire le temps requis par le SCWS. Sauf que j'y connais rien en multithreading . J'ai cru comprendre que scinder une énorme ForLoop en plusieurs loops plus petites, et réunir le tout au final était l'essence du multithreading. Ca tombe bien parce que c'est mon problème.

    On m'a conseillé une librairie (OpenMP) qui semble adaptée, mais j'aurais aimé des exos un peu plus pratiques que ceux fournis dans la doc de la librairie.
    Oui, OpenMP est ton ami. Scinder la boucle en boucles plus petites exécutées par des threads, en général, ce n'est pas toi qui t'en occupes, tu laisses faire OpenMP.
    Si tes itérations sont indépendantes, ça se ramène à mettre un
    #pragma omp parallel for
    devant ta boucle principale.

    Après, tu peux avoir besoin de faire du tiling (pour favoriser la localité dans les caches), ou d'aider le compilo à faire de la vectorisation. Mais c'est pas de la parallélisation proprement dit.

    Vectra doit être au taquet sur tout ça.

    Elles ont quelle gueule tes boucles for, en termes de dépendances ? Est-ce que chaque nœud est indépendant, ou tu dois accéder aux voisins ?

  23. #5813
    Bah ouais, OpenMP, c'est vraiment très facile et très efficace, au moins dans des cas simples. Faut voir la tronche des boucles aussi...
    L'intérêt d'OpenMP, c'est notamment le gain de bande passante mémoire dû à l'usage optimal du bus mémoire (bien que je ne me l'explique pas).

    La vectorisation, c'est utile à condition de ne pas être trop memory-bound (comme dans mon cas). Quand y'a pas assez de calculs à accélerer, c'est nettement moins efficace mais on est rarement broucouille. Quant à la possibilité de faire des écritures hors-cache, grâce à des instructions du même jeu que celles de la vectorisation, c'est quand-même drôlement efficace pour accélerer les écritures (edit) quand on écrit sur de gros tableaux.


    D'ailleurs, mon DFDJ, c'est qu'une telle technique (pourtant connue et relayée) a déjà fait l'objet d'un brevet . Ok, soit-disant dans le contexte du garbage-collecting, mais quand-même .
    Last edited by vectra; Yesterday at 08h40.

  24. #5814
    ça semble encourageant, merci! je reviendrai très bientôt avec encore plus de questions, d'ici là je vous invite à jeter un coup d'oeil à mon repository GitHub et à la doc du programme.

    Pas tapey, je débute juste!

    La doc: http://bbercovici.github.io/
    Le repository: cf page d'accueil de la doc

    Les ForLoops inception, c'est principalement dans Pic.cc.

    Et pardonnez le ton un peu abêtissant de l'intro, c'est pour les personnes de mon groupe de recherche qui y connaisse encore moins que moi.
    Last edited by BentheXIII; Yesterday at 01h55.
    Quote Originally Posted by Colargol View Post
    Mais globalement l'ingenieur en France il bosse un peu a l'africaine: ca marche mais ca fait pas serieux

  25. #5815
    C'est dans Pic::assemble_matrix le for loop inception ?

    À première vue ça a l'air assez inoffensif effectivement. Mais pourquoi tu parcours deux fois de suite sur i et j plutôt que de mettre tout dans la même boucle ? Il y a des dépendances planquées qui font que tu dois attendre d'avoir fini de tout calculer avant de toucher à system_matrix ?

    Dans distribute_charge, tu as des calculs d'histogramme. C'est moins évident à paralléliser mais ça doit pouvoir bien se faire avec des atomics.

    Sinon ton indentation fait saigner des yeux.

  26. #5816
    Hello Mogluglu, merci d'avoir jeté un coup d'oeil. Désolé pour l'indentation à l'arrache, Sublime aime pas les forloops à une seule instruction (donc sans {}), et j'avais trainé pour corriger. Je mettrai prochainement la documentation à jour.

    Pour Pic::assemble_matrix, je suis obligé d'avoir deux boucles imbriquées sur i et j afin de pouvoir parcourir tous les éléments de la matrice globale, que ce soit lors de l'évaluation des fonctions de base
    Code:
      for (unsigned int i=0; i<dofs_per_cell; ++i){
          for (unsigned int j=0; j<dofs_per_cell; ++j){
            for (unsigned int q_point=0; q_point<n_q_points; ++q_point){
              cell_matrix(i,j) += (fe_values.shape_grad (i, q_point) *
               fe_values.shape_grad (j, q_point) *
               fe_values.JxW (q_point));
            } 
          } 
        }
    ou lors de l'assemblage proprement dit
    Code:
     for (unsigned int i=0; i<dofs_per_cell; ++i){
          for (unsigned int j=0; j<dofs_per_cell; ++j){
            system_matrix.add (local_dof_indices[i],local_dof_indices[j],cell_matrix(i,j));
          }
        }
    Pour revenir au multithreading: il suffit donc de prédéclarer #pragma omp parallel for devant chaque double boucle, et OpenMP se charge de distribuer le calcul entre les processeurs?

    Sinon, qu'est-ce qu'un histogramme dans le contexte du multithreading?
    Quote Originally Posted by Colargol View Post
    Mais globalement l'ingenieur en France il bosse un peu a l'africaine: ca marche mais ca fait pas serieux

  27. #5817
    Quote Originally Posted by BentheXIII View Post
    Hello Mogluglu, merci d'avoir jeté un coup d'oeil. Désolé pour l'indentation à l'arrache, Sublime aime pas les forloops à une seule instruction (donc sans {}), et j'avais trainé pour corriger. Je mettrai prochainement la documentation à jour.

    Pour Pic::assemble_matrix, je suis obligé d'avoir deux boucles imbriquées sur i et j afin de pouvoir parcourir tous les éléments de la matrice globale,
    (...)
    Est-ce que tu as des dépendances de données qui rendent cette version fusionnée des deux boucles incorrectes ?
    Code:
      
    for (unsigned int i=0; i<dofs_per_cell; ++i)
    {
          for (unsigned int j=0; j<dofs_per_cell; ++j)
          {
              for (unsigned int q_point=0; q_point<n_q_points; ++q_point)
              {
                  cell_matrix(i,j) += (fe_values.shape_grad (i, q_point) *
                                           fe_values.shape_grad (j, q_point) *
                                           fe_values.JxW (q_point));
              } 
              system_matrix.add (local_dof_indices[i],local_dof_indices[j],cell_matrix(i,j));
          } 
    }
    Pour revenir au multithreading: il suffit donc de prédéclarer #pragma omp parallel for devant chaque double boucle, et OpenMP se charge de distribuer le calcul entre les processeurs?

    Sinon, qu'est-ce qu'un histogramme dans le contexte du multithreading?
    Pour les pragmas, ce n'est pas aussi simple si tu as un calcul similaire à celui d'un histogramme : si tu écris plusieurs fois à un même endroit dans ta boucle, il faut que tu t'assures que tu ne le fasses pas de manière concurrente, même si tes écritures sont commutatives et associatives. D'où le rajout d'un pragma atomic pour indiquer que seul un thread simultanément peut écrire à l'emplacement visé par l'instruction qui suit. (Globalement pour un histogramme, tu vas incrémenter des cases d'un tableau en fonction d'une valeur lu pour tes éléments, donc avec un pragma atomic tu t'en sors pas trop mal pour peu d'effort.)

    Mais avant de commencer à rajouter des pragmas, même si ce n'est pas très compliqué et très rapide, je te conseillerai de passer un coup de profiler histoire d'identifier les portions de code critiques de ton application.
    Last edited by Sp1d3r; Today at 01h06. Reason: associatives et commutatives

  28. #5818
    Bien vu Sp1d3r, autant commencer par ça

    Je ne crois pas que ça pose problème, je testerai très prochainement

    edit: pour un run sur un seul pas de temps, c'est en moyenne plus court de 1 à 3 secondes que la version précédente (environ 59s contre environ 62s). Comme la vraie simulation prend 400 pas de temps, on lorgne sur un gain de pas loin de 20 minutes. Pas mal!

    edit 2: un autre gros, gros point bloquant de mon code est la méthode Pop::check_rebound_and_reflect(...) qui teste l'update de la position de chaque particule et vérifie si une d'entre elle n'a pas touché un obstacle. Si c'est le cas, la trajectoire est modifiée pour tenir compte du rebond. Chaque itération de la boucle for dans Pop::check_rebound_and_reflect() est indépendante car affecte des particules différentes.

    Code:
    void Pop::check_rebound_and_reflect(std::vector<Circle> &in_bounds, Circle &out_bounds){
      dq=0;
      //#pragma omp parallel for
      for(typename std::vector<std::shared_ptr<Particle>>::iterator it=members.begin(); it!= members.end(); ++it){
         if((*it)->check_rebound_and_reflect(in_bounds,out_bounds)==true)
          dq=dq+(*it)->get_charge();
      }
    }
    Pour tirer parti du multithreading dans ce cas précis, suffit-il d'ajouter la déclaration
    Code:
     #pragma omp parallel for
    juste avant le for (comment dans le snippet de code ci dessus)? Vu ce que mon compilateur me renvoie, j'imagine que non...
    Last edited by BentheXIII; Today at 02h18.
    Quote Originally Posted by Colargol View Post
    Mais globalement l'ingenieur en France il bosse un peu a l'africaine: ca marche mais ca fait pas serieux

  29. #5819
    Ha, j'ai peu d'expérience en C++ et OpenMP, mais de mémoire, il y a quelques soucis avec les itérateurs... Tu peux écrire cette boucle avec un for classique ou pas ? Sinon, il y a toujours des solutions mais regarde déjà si tu exprimer ta boucle différemment (i.e. avec un indice).

    Une fois que tu auras résolu ce problème, dans cette boucle, tu veux faire une réduction de type somme (tu veux que dq valent la somme des dq trouvé pour chaque thread), donc il faut mettre dans le pragma. (#pragma openmp parallel for reduction (+:dq))

    Tu as tenté de rajouter des pragmas pour la PIC::assemble_matrix ?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts