Métaprogrammation dans boost::numeric::ublas

Bonjour.

Est-ce que quelqu'un ici, s'y connaissant en métaprogrammation, aurait déjà regardé comment était codé uBlas de boost ?

En effet, je débute au niveau de la métaprogrammation (merci au tuto de Laurent Gomila) et comme je vise l'implémentation de tenseurs (c'est pour de la relativité générale), j'ai commencé à regarder comment était codée uBlas.

Contrairement à ce que je pensais à priori, le code est assez clair. Toutefois, je ne retrouve pas ce que Laurent Gomila explique dans son tutorial pour la classe vector. Aussi si quelqu'un s'était déjà penché sur la question, je me demandais quelle était la "stratégie" globale (quels fichiers définissent quoi et pourquoi) et les techniques de métaprogrammation employées dans ublas.

Merci beaucoup ;).

Bonjour,

Je n'ai pas regardé boost::ublas, mais je pense (comme pour les autres bibliothèques numériques performentes (***)) que le gros de la méta-prog concerne la mise en place d'expressions template.

Il y a surment plusieurs façon de mettre en place ce système, mais l'idée est toujours la même : construire à la compilation un arbre représentant le calcul pour pouvoir dérouler les boucles (*) et éviter la création de temporaire inutilement lourd (**).

Basiquement le code est une/des classes template servant a représenter une expression en utilisant une "tag class" pour représenter l'opération associé au noeud, grâce à ce tag on va pouvoir déterminer à la compilation quels opérations réaliser au runtime.

On peut imaginer diverses solutions pour indiquer les opérations : indiquer comment faire l'opération dans une fonction membre du tag (comme expliqué dans C++ Template Metaprogramming), le faire dans une fonctions membre de l'expression en utilisant la spécialisation partielle (comme l'a fait Laurent), et surment d'autre variante.

Tu devrais te pencher sur boost::proto, il peut t'aider dans cette tâche, c'est d'ailleurs l'un des exemples du tuto dans la doc de boost::proto (****).


(*) L'opération de calcul peut être seulement réalisé lors de l'utilisation d'un opérateur d'accés (et/ou d'affectation) à un élément d'un matrice, évitent ainsi un paquet de calculs intermédiaires inutiles.

(**) En plus de la création/destruction de variables temporaires on va avoir une baisse de performence du à un parcours répété de la matrice, alors qu'avec les expressions tempate le nombre de parcours est réduit.

(***) Le reste de la performence doit être apporté pas un choix de structure judicieux (NRC par exemple) et surment l'utilisation d'instructions SIMD (voir du GPU ?) mais je ne sais pas le poids que ca a réelement sur l'ensemble des performences.

(****) Va voir aussi les articles à son sujet sur C++Next (en anglais)

j'arrive trop tard tout a été dit ^^

+1 sur proto et sur l'utilisation du SIMD. Le calcul tensorielle me parait de grain trop fin pour devoir aller travailler sur une GPU.

Merci beaucoup pour cette réponse très détaillée.
Je vais me pencher là dessus.

EDIT après avoir jeté un oeil aux premières pages de la doc de boost::proto : c'est moi ou c'est carrément surpuissant ce truc ?

Question 1 : comme pour l'instant je suis encore en train de découvrir la métaprog, je ne suis pas certain de bien comprendre : quelle est la différence entre MPL et proto ?
MPL simplifie la métaprogrammation de façon générique, alors que proto est moins générique et simplifie spécifiquement les "expression templates" ?

Comme je débute je n'ai pas encore bien les idées claires. Mais est-ce que lors de la construction de mon arbre (je précise que je travaillerai tout le temps avec des vecteurs et matrices de tailles fixes, relativement petites), je pourrai tout à fait coder des opérateurs "complexes" sur mes matrices (par exemple imaginons le calcul d'un déterminant qui serait remplacé à la compilation directement par le bon "calcul" à partir de -,+,* des éléments de la matrice) ?

Merci

EDIT 2 : plus je lis, plus je me dis que c'est trop génial pour être vrai. C'est moi où ça rend vraiment la métaprog par "expression templates" simple et lisible ?

Question 2 : Y-a-t-il des un léger coût en perf (à l'exécution) de l'utilisation de proto ou c'est aussi efficace qu'un truc codé "lentement mais surement" à la main ?

MPL c'est un peu l'équivalent de la partie algo+conteneurs de la bibliothèque standard, alors que proto est destiné à l'écriture de DSEL (*) : un nouveau langage plus spécifique (ie qui a un objectif précis) au sein du C++ avec sa propre syntaxe (basé sur les opérateurs du C++), une partie de ce langage (l'arbre syntaxique) est calculé à la compilation, et l'autre partie (l'évaluation de l'abre) à l'execution. C'est basé sur des expressions templates et ca peut servir pour différentes choses (c'est le besoin spécique) : algèbre linéaire, lambda calcul par exemple (la doc de proto donne assez d'exemple pour se faire une idée du potentiel).

Pour ta seconde question : oui, je te laisse lire la doc de proto, il montre comment donner une sémantique spécifique à un opérateur. (Et de manière général si tu lis tout le tuto de la doc de proto tu devrais pouvoir faire ce que tu veux. (Elle est vraiment bien faite je trouve, du moins quand l'objectif est une utilisation "direct", pour faire des choses plus "tordue" c'est peut-etre une autre histoire ...)

Pour les coût, franchement je n'en sais rien, mais si il y en a il doivent être suffisament faible pour qu'il soit plus avantageux d'utiliser proto que de galèrer à obtenir quelque chose de mieux à la main (les bases des expressions templates se font bien à la main, mais dès qu'on approfondie un peu (**) ca peut devenir moins simple ...), proto à l'avantage de proposer une manière "simple" et "clair" de le faire, s'en priver n'a pas trop d'interet (***).

(*) DSEL : domain specific embedded language

(**) Lis le livre de David Abrahams sur MPL, les derniers chapitres sont consacrés au DSEL, et ses exemples sont l'écriture de DSEL, il montre comment faire (conception et réalisation) et ce n'est vraiment pas la chose la plus simple à faire ... il montre d'ailleurs que le cheminement pour arriver à quelque chose de bien est assez complexe : il faut trouver le moyen de faire la maximum de chose à la compilation tout en gardant une syntaxe viable pour l'utilisateur.

(***) Sauf si le but est d'apprendre à utiliser les expressions template (ou l'apport de la méta-prog pour le runtime).

PS: "lentement mais surement" AMA, refaire proto sans une bonne expérience de la méta-prog et de la syntaxe du C++, c'est plutôt "lentement et droit dans le mur"