Optimization du code FEM

J'ai regardé le problème de perf de votre code.

J'ai tout d'abord constaté chez moi le même problème que celui observé mardi après-midi:

• Compilé sous windows, la boucle openmp d'assemblage tournait chez moi, sur 1 thread, en ~43s; ce qui est comparable au laptop de Louis.
• Le même code, sous ubuntu, sur une machine identique (core i9 10900X), tournait en ~9s (comme sur le mac de C. Geuzaine).

J'ai alors testé un autre compilateur sous windows (Microsoft Visual Studio). Le problème était toujours là, en pire (~50s).

Sans compiler avec OpenMP, le problème était identique. Ce n'était donc pas un problème lié à OpenMP.

J'ai donc regardé plus en détail les instructions de votre code. Le problème venait du fait que vous passiez la plupart de vos arguments de fonction par copie (sans le &). J'ai donc ajouté un passage par référence pour la plupart des arguments où ça manquait (le plus critique était évidemment les vecteurs de vecteurs de triplets lors de l'assemblage).

Pour améliorer encore les perfs, j'ai changé les "vecteur de vecteurs" en "vecteurs de listes". Cette dernière modif n'est pas vraiment nécessaire d'après mes mesures de temps CPU. Néanmoins je l'ai laissée (cela évite des désallocations de mémoire lors des push_backs).

Il y a encore des améliorations possibles (sortir certaines définitions hors des boucles), mais j'ai arrêté là parce que c'était suffisant pour avoir un code qui tourne de manière instantanée.

Au final, l'assemblage du test my_geo.geo avec nx=200et ny=80 tourne en 0.1s sous windows (et 0.06s sous ubuntu). Ceci avec 1 seul thread. Un speedup de ~500 donc, sans utiliser OpenMP.

Vous voyez donc l'importance des pages 46-47 de des slides sur l'API Gmsh qui expliquent pourquoi utiliser des références lors du passage des arguments de fonction.

Vous pouvez merger le code de ce merge request. Il viendra modifier la branche test_openmp que vous pourrez ensuite merger avec votre brache master. Vérifiez tout de même vos autres tests avant.