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

**Møgluglu** · 22/08/2014, 11h46

Tu peux tester toutes tes conditions en parallèle pour commencer.
Ensuite, tu peux utiliser un algo de préfixe parallèle (scan) pour compacter tes données. Ça rassemble toutes les données pour lesquelles la condition est évaluée à vrai.
Puis tu traites ces données compactes en parallèle pour faire le traitement à l'intérieur du if.

Mais dans le cas présent, le traitement à effectuer dans le if (juste une addition) est bien trop petit pour justifier une telle usine à gaz. Autant faire l'addition pour tout le monde, quitte à ajouter des zéros.

**FB74** · 22/08/2014, 11h50

Envoyé par Møgluglu

Tu peux tester toutes tes conditions en parallèle pour commencer.
Ensuite, tu peux utiliser un algo de préfixe parallèle (scan) pour compacter tes données. Ça rassemble toutes les données pour lesquelles la condition est évaluée à vrai.
Puis tu traites ces données compactes en parallèle pour faire le traitement à l'intérieur du if.

D'après ce que j'ai compris, les processeurs modernes incorporent une part de traitement conditionnel pour exploiter l'architecture multi-cœurs.... mais c'est en contradiction avec une politique d'économie d'énergie si on fait tourner les cœurs pour rien ?

[/ chieur]

**Møgluglu** · 22/08/2014, 14h26

Il y a deux choses différentes.
Ce dont on parlait, c'était de paralléliser un calcul en étant moins "work-efficient" : l'algorithme parallèle réalise plus d'opérations que l'algo séquentiel, mais sa plus longue séquence d'opérations est plus courte. Pour un calcul de préfixe parallèle de n éléments, l'algo séquentiel est en O(n), l'algo parallèle avec n processeurs est en O(log n) et fait O(n log n) opérations.

(Le préfixe parallèle, c'est l'algo qu'on utilise à chaque fois qu'on calcule une addition, pour propager les retenues.)

Là, tu parles plutôt de la spéculation, non ? Le fait de commencer du travail dont on est pas encore sûr qu'il soit utile ? Ça date d'avant le multi-cœur et tout le monde fait ça.
Ce n'est pas forcément contradictoire avec l'efficacité énergétique. La spéculation peut te permettre de terminer le calcul plus vite, d'éteindre le processeur ou passer à autre chose plus tôt et au final consommer moins d'énergie pour la tâche. La fonction performance / consommation n'est pas linéaire.

**BentheXIII** · 22/08/2014, 15h50

Envoyé par 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 :

Code:

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?

C'était un oubli

J'ai une erreur de compilation avec le pragma:quand je compile ça

Code:

  

void Pop::check_rebound_and_reflect(const std::vector<Circle> &in_bounds,const Circle &out_bounds){
  dq=0;
  #pragma omp parallel for reduction (+:dq)
  for(unsigned 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;
  }
}

j'obtiens

Code:

[ 12%] Building CXX object mycode/CMakeFiles/pic4.0.dir/source/Pop.cc.o
/home/benjamin/Documents/UIUC/uiuc-cpp/pic4.0/mycode/source/Pop.cc: In member function ‘void Pop::check_rebound_and_reflect(const std::vector<Circle>&, const Circle&)’:
/home/benjamin/Documents/UIUC/uiuc-cpp/pic4.0/mycode/source/Pop.cc:41:44: error: ‘Pop::dq’ is not a variable in clause ‘reduction’
   #pragma omp parallel for reduction (+:dq)
                                            ^
/home/benjamin/Documents/UIUC/uiuc-cpp/pic4.0/mycode/source/Pop.cc:42:3: error: invalid controlling predicate
   for(int i = 0; i != members.size(); ++i) {
   ^
make[2]: *** [mycode/CMakeFiles/pic4.0.dir/source/Pop.cc.o] Error 1
make[1]: *** [mycode/CMakeFiles/pic4.0.dir/all] Error 2
make: *** [all] Error 2

Je vais investiguer tout ça

edit1: Apparemment, OpenMP n'aime pas quand on passe un class member comme argument de reduction (http://openmp.org/forum/viewtopic.php?f=3&t=79). J'ai donc créé une variable DQ qui est passée à réduction et qui remplace dq dans le code C/C plus haut, et je copie juste dq=DQ à l'issue de la boucle. Première erreur résolue, mais j'ai toujours le problème du invalid predicate...

**Møgluglu** · 22/08/2014, 16h04

En copiant members.size() dans une variable locale avant la boucle pour ne pas avoir d'appel de fonction dans la condition ça va mieux?

**BentheXIII** · 22/08/2014, 16h07

Trouvé: Open MP n'autorise pas:

Une variable de boucle de type unsigned int i
Une condition de type i != N (uniquement =, < , >, =>, <=)

http://stackoverflow.com/questions/1...r-using-openmp

Maintenant ça compile. Je teste.

edit:

quasiment aucune différence sur le temps d'exécution (autour d'une seconde).

Pour info, check_rebound_and_reflect ressemble à ça désormais

Code:

void Pop::check_rebound_and_reflect(const std::vector<Circle> &in_bounds,const Circle &out_bounds){
  dq=0;
  double 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;
  }
  dq=DQ;
}

Ai-je besoin de déclarer en amont le nombre de thread à allouer? Y-a-t-il un moyen de voir combien de thread sont alloués par OpenMP, si cette allocation se fait automatiquement?

**FB74** · 22/08/2014, 16h46

Envoyé par Møgluglu

Là, tu parles plutôt de la spéculation, non ? Le fait de commencer du travail dont on est pas encore sûr qu'il soit utile ? Ça date d'avant le multi-cœur et tout le monde fait ça.

Voilà, c'est ça.

**vectra** · 22/08/2014, 16h48

#pragma omp parallel for num_threads( 3 )

**Møgluglu** · 22/08/2014, 17h01

Envoyé par BentheXIII

edit:

quasiment aucune différence sur le temps d'exécution (autour d'une seconde).

Tu compiles avec quel compilo, quelle implèm d'OpenMP, quelles options ? Tu passes bien les flags qui vont bien pour OpenMP ?

Ai-je besoin de déclarer en amont le nombre de thread à allouer? Y-a-t-il un moyen de voir combien de thread sont alloués par OpenMP, si cette allocation se fait automatiquement?

Par défaut c'est généralement autant que de threads matériels que la machine supporte.
Tu peux contrôler ça avec des variables d'environnement, pour éviter de toucher au code :
https://computing.llnl.gov/tutorials...nmentVariables

**BentheXIII** · 22/08/2014, 17h01

Merci Vectra, mais ça ne change quasiment rien. Je me doutais bien que la réduction du temps ne sera pas proportionnelle au nombre de threads, mais je suis quand même surpris. Je mets ça sur le compte de mon ignorance, y'a problablement un truc que j'ai mal fait quelque part.

edit: je compile avec gcc, en ayant au préalable généré les Makefiles avec CMake. Le fichier CMake le plus haut dans l'arborescence de mon code:

Code:

FIND_PACKAGE(deal.II 8.0 QUIET
  HINTS ${deal.II_DIR} ${DEAL_II_DIR} /~/bin/deal.II $ENV{DEAL_II_DIR}
  )
IF(NOT ${deal.II_FOUND})
  MESSAGE(FATAL_ERROR "\n"
    "*** Could not locate deal.II. ***\n\n"
    "You may want to either pass a flag -DDEAL_II_DIR=/path/to/deal.II to cmake\n"
    "or set an environment variable \"DEAL_II_DIR\" that contains this path."
    )
ENDIF()

DEAL_II_INITIALIZE_CACHED_VARIABLES()
PROJECT(pic4.0)

CMAKE_MINIMUM_REQUIRED(VERSION 2.8.8)
find_package(OpenMP)
if (OPENMP_FOUND)
    set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${OpenMP_C_FLAGS}")
    set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS}")
endif()

ADD_SUBDIRECTORY(mycode)

La séquence pour compiler est donc "cmake ." (à chaque fois que je change l'arbo des fichiers) et "make" ( sans options ...)

Pour l'implémentation d'open MP... heu, je me suis contenté de c/c l'instruction "#pragma...", de rajouter le find_package(OpenMP) (qui devait préexister sur mon pc, c'est une feature de base de C++11?), et c'est tout...

Le nombre max de threads est-il corrélé avec le nombre de cores dont dispose le processeur?

**Møgluglu** · 22/08/2014, 17h22

Envoyé par BentheXIII

Pour l'implémentation d'open MP... heu, je me suis contenté de c/c l'instruction "#pragma...", de rajouter le find_package(OpenMP) (qui devait préexister sur mon pc, c'est une feature de base de C++11?), et c'est tout...

Non, OpenMP n'est pas lié à la norme C++, c'est une extension pour Fortran et C qui marche aussi en C++ (d'où la syntaxe à base de #pragma). Si tu utilises gcc, ça doit être libgomp ton implémentation d'OpenMP.

Si j'ai bien compris ton code cmake, il teste si OpenMP est installé, et s'il le trouve il ajoute les flags qui vont bien. Sinon il fait comme si de rien n'était.
Du coup il le trouve ou pas sur ta machine ? À la fin, g++ est invoqué comment ?

Le nombre max de threads est-il corrélé avec le nombre de cores dont dispose le processeur?

Oui. Tu peux mettre un thread par cœur, par exemple. Mais c'est ce qu'il devrait faire par défaut.

**BentheXIII** · 22/08/2014, 17h26

J'imagine qu'il le trouve, car si je commente le bloc

Code:

find_package(OpenMP)
if (OPENMP_FOUND)
    set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${OpenMP_C_FLAGS}")
    set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS}")
endif()

Après avoir appelé cmake . et lancé la compilation, j'ai un warning

Code:

/home/benjamin/Documents/UIUC/uiuc-cpp/pic4.0/mycode/source/Pop.cc:42:0: warning: ignoring #pragma omp parallel [-Wunknown-pragmas]
   #pragma omp parallel for reduction (+:DQ)
 ^

Si le bloc est actif, plus de warning lors de la compilation, et la trace de cmake . est

Code:

-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Try OpenMP C flag = [-fopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Success
-- Try OpenMP CXX flag = [-fopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Success
-- Found OpenMP: -fopenmp  
-- Configuring done
-- Generating done
-- Build files have been written to: /home/benjamin/Documents/UIUC/uiuc-cpp/pic4.0

Donc OpenMP est bien trouvé j'ai l'impression.
edit: je pensais qu'il me suffisait de jeter un oeil au Makefile pour avoir la réponse à ma question, mais cmake . génère pléthore de fichier donc il est un peu dur de s'y retrouver.
J'ai trouvé un fichier link.txt contenant ceci:

Code:

/usr/bin/c++   -pedantic -fpic -Wall -Wpointer-arith -Wwrite-strings -Wsynth -Wsign-compare -Wswitch -Wno-unused-local-typedefs -Wno-long-long   -std=c++11 -Wno-parentheses -Wno-long-long -fopenmp -Og -ggdb -Wa,--compress-debug-sections     -Wl,--as-needed -rdynamic -pthread -ggdb CMakeFiles/pic4.0.dir/source/Pop.cc.o CMakeFiles/pic4.0.dir/source/Particle.cc.o CMakeFiles/pic4.0.dir/source/Ion.cc.o CMakeFiles/pic4.0.dir/source/Pic.cc.o CMakeFiles/pic4.0.dir/source/Electron.cc.o CMakeFiles/pic4.0.dir/source/Circle.cc.o CMakeFiles/pic4.0.dir/source/Initializer.cc.o CMakeFiles/pic4.0.dir/source/main.cc.o  -o pic4.0 -rdynamic "/~/bin/deal.II/lib/libdeal_II.g.so.8.1.0" /usr/lib/liblapack.so.3gf /usr/lib/libblas.so.3gf -lm -lquadmath -lc -ldl -Wl,-rpath,"/~/bin/deal.II/lib"

ça ressemble fortement à une liste d'options passée à un compilateur. Et je ne vois aucune mention à OpenMP. Comment se fait-il que j'ai réussi à compiler le code

Je vais rajouter à main nue l'option "-fopenmp" dans la liste et voir si ça change quelque chose... Il y a bien le flag -fopenmp dans le tas...

**Robix66** · 25/08/2014, 23h51

Aujourd'hui je cherchais à dessiner sur un stream vidéo, rien de bien méchant (pour l'instant, ça se compliquera légèrement plus tard), je commence à faire quelques essais de trucs sales en WPF, comme superposer un Canvas sur lequel je vais dessiner : "mouais, bon ça va être chaud pour les redimensionnements en cours de route, mais en bricolant ça va le faire". Sauf qu'en plus on ne peut pas "gommer" le canvas simplement, une petite recherche plus tard je tombe sur un mec qui pose la même question, "ben non, c'est pas fait pour, pour jouer avec les pixels, utilise un WriteableBitmap". Bon bah ok, de toutes façons j'ai que des cercles à faire, ça devrait pas être bien long, même si le seul accès est le buffer.

Pis je continue machinalement le thread et le message suivant c'est "va voir WriteableBitmapEx".
Toutes ces fonctions dont j'avais maudit l'absence en WPF.

**Tomaka17** · 27/08/2014, 11h00

Microsoft essaie de déposer un brevet pour le RAII

http://www.freepatentsonline.com/y2014/0196015.html

Ce n'est même pas ambigu. Le paragraphe d'introduction pourrait presque servir de définition du mot "RAII" dans un dictionnaire.

Ils essaient aussi de brever le mot-clé "const" on dirait: http://www.freepatentsonline.com/y2014/0196008.html

**Sahnvour** · 27/08/2014, 11h15

On peut breveter des trucs pareils ?

Ça s'est déjà vu pour des concepts/features de langages de prog ?

**Robix66** · 27/08/2014, 11h38

Ouais, les équipes Midori et M# ont fait un tir groupé en juillet :

Après, sur ce qui a trait au langage, pas certain qu'ils cherchent à s'en servir contre les autres (Joe Duffy voulait que M# soit open source). Mais s'ils cherchent à breveter des trucs existant...

**rOut** · 27/08/2014, 17h41

Microsoft. Les mecs sont vraiment à la rue.

**Tomaka17** · 28/08/2014, 12h01

Apparemment Microsoft se fait plus d'argent en brevets liés à Android qu'en vendant des licenses Windows Phone : http://www.howtogeek.com/183766/why-...d-device-sold/

C'est marrant d'avoir autant de brevets pour une entreprise qu'on dit tout le temps à la ramasse niveau mobile

In reality, Microsoft has never had to defend their Android patents in court. Rather than risk an expensive court battle with Microsoft, Android manufacturers just pay Microsoft for a license so they can get on with business. It’s generally cheaper to pay off “patent trolls” than to fight them in court, and this is even more true for a company with cash reserves as big as Microsoft’s.

Ahh, tout s'explique

**rOut** · 31/08/2014, 00h24

Tiens, Khronos se décide enfin à jeter le bébé avec l'eau du bain et à repartir de 0 pour OpenGL. Ils ont l'air d'avoir compris le message avec Mantle / DX12 / Metal. Y'a plus qu'à espérer qu'ils fassent un truc bien.

**Tomaka17** · 01/09/2014, 23h03

À l'époque où j'avais détaillé un peu le langage Rust j'avais écrit qu'il manquait un gros truc que sont les associated types (la possibilité de déclarer des typedef dans des traits).
Hé ben ce sera très bientôt mergé

https://github.com/rust-lang/rust/pull/16377

Du coup le Rust est en train de devenir le langage parfait.

Demain sera posté un article sur "la route vers la version 1.0", qui est je crois maintenant prévue aux alentours de janvier.

**rOut** · 01/09/2014, 23h05

Du coup le Rust est en train de devenir le langage parfait.

Certes...

**Tomaka17** · 01/09/2014, 23h09

Pour l'instant 100 % des programmeurs de ce topic qui ont une bonne expérience du Rust ont déclaré que c'était un langage parfait.

**war-p** · 01/09/2014, 23h41

On sent le mec objectif...

**rOut** · 01/09/2014, 23h48

C'est quoi une bonne expérience, pour un langage qui n'a pour l'instant aucune application releasée et utilisée en vrai ?

**Tomaka17** · 02/09/2014, 08h43

C'est déjà un peu utilisé en production, notamment par OpenDNS.

Je dis "une bonne expérience" parce que j'ai déjà écrit un serveur web, un début de proof-of-concept pour un framework web, une alternative à GLFW, et un wrapper pour Lua, en plus de contribuer à plusieurs autres projets, de réécrire mon p'tit projet de jeu dans ce langage et de traîner en permanence sur l'IRC officiel.
Par contre je n'ai pas contribué au compilateur Rust lui-même, vu que sous windows c'est la croix et la bannière pour réussir à le compiler.

**deathdigger** · 02/09/2014, 10h00

Y'a une version de .Net de Rust, pour qu'on essaie ?

**Robix66** · 02/09/2014, 13h53

Envoyé par deathdigger

Y'a une version de .Net de Rust, pour qu'on essaie ?

Y a M# qui fera la même chose.

**Foudge** · 02/09/2014, 14h09

Envoyé par Tomaka17

Par contre je n'ai pas contribué au compilateur Rust lui-même, vu que sous windows c'est la croix et la bannière pour réussir à le compiler.

Parce qu'il est lui aussi codé en Rust ?

**Patate** · 02/09/2014, 15h01

D'après la doc oui.

**Tomaka17** · 02/09/2014, 15h25

Le compilo officiel est effectivement codé en Rust, ce qui permet du coup à tout un chacun d'écrire des plugins pour le compilo.

Les plugins permettent de faire des choses phénoménales, comme par exemple cette librairie faite pour écrire des programmes embedded qui interagissent de façon safe avec l'extérieur : http://zinc.rs/.

Ou bien encore ces bindings opengl qui génèrent automatiquement les fonctions Rust en lisant les specifications officielles en XML: https://github.com/bjz/gl-rs
Le jour où OpenGL 4.5 est sorti, on a changé une valeur de "4.4" en "4.5", et hop ça marche (quasiment) tout seul.

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

Outils de la discussion

Règles de messages