Le topic de la programmation, string, chaînes, cuir et compagnie

[rOut]

Genre on peut faire ça en .Net ? C'est pas censé être managé et tout ?

[Møgluglu]

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.

[deathdigger]

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

[Tomaka17]

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

[TiNitro]

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 ----------

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.

[deathdigger]

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

[moimadmax]

Son anagramme fonctionne aussi, l'apprentissage va être raide

[Sp1d3r]

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 )

[Tomaka17]

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) :

[FB74]

Java n'est pas si mal placé.





Il y aurait donc pire.

[Tomaka17]

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/

[Nattefrost]

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 .

[TiNitro]

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...

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.

[Ardan]

[EDIT] : Mauvaise section !

[BentheXIII]

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 :smile:. 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

[FB74]

Tu fais quoi avec ça BentheXIII ?

Une particule qui se meut dans un plasma ?

[BentheXIII]

"Une" particule? J'aimerais bien . Mais oui c'est l'idée.

[FB74]

"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.

[BentheXIII]

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

[FB74]

Mais on dévie du sujet la

Ouais.

Mais c'est intéressant.

[Møgluglu]

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 :smile:. 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 ?

[vectra]

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 .

[BentheXIII]

ç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.

[Møgluglu]

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.

[BentheXIII]

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

  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

 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?

[Sp1d3r]

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 ?

  
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.

[BentheXIII]

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.

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

 #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...

[Sp1d3r]

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 ?

[Møgluglu]

Ouep, d'ailleurs je ne suis pas sûr qu'OpenMP gère les réductions conditionnelles. Dans le doûte, j'écrirais un code bête et méchant de ce genre :

void Pop::check_rebound_and_reflect(std::vector<Circle> &in_bounds, Circle &out_bounds){
  dq=0;
  #pragma omp parallel for reduction (+:dq)
  for(int i = 0; i != members.size(); ++i) {
     double charge;
     if(members[i]->check_rebound_and_reflect(in_bounds,out_bounds)) {
         charge = members[i]->get_charge();
      }
      else {
         charge = 0;
      }
      dq = dq + charge;
  }
}

in_bounds et out_bounds ne sont pas const, c'est un oubli ou elles peuvent être modifiées par Particle::check_rebound_and_reflect?

[FB74]

Ouep, d'ailleurs je ne suis pas sûr qu'OpenMP gère les réductions conditionnelles.

D'ailleurs d'un point de vue "répartition" (dans le cas d'un traitement parallèle) c'est difficile de gérer du conditionnel... puisque ça engage du séquentiel par définition, non ?

Simple remarque de béotien de la programmation.