Discussion :

[Nanoc]

Bonjour,

Je travaille actuellement sur de la simulation numérique et j'utilise des nombres complexes dans mes calculs. En fait, je n'utilise que des opérations arithmétiques de base, donc pas de sin(), cos() ou autre fonction mathématique.

Pour l'instant, je me suis tourné vers la classe std::complex de la SL, mais je me demandais si il n'existait pas une autre alternative.
Des mesures ont montré que je passais près de 20% du temps d'exécution du programme dans la fonction operator-(double, complex) et environ 10% dans operator*. Ce sont donc de vrais goules d'étranglement.
Je me suis demandé si récrire une classe de nombres complexes en utilisant des expressions templates pour optimiser les calculs serait une bonne solution, mais avant cela, je préfère me renseigner pour savoir si il existe une réelle alternative.

Merci d'avance.

[Luc Hermitte]

Hum. Je sens le truc vicieux.
Pour avoir des infos de profiling, tu as dû passer en debug, ce qui a désactivé l'inlining (des fonctions de cette classe template)
Tu peux tenter avec des expressions templates, mais je ne suis pas sûr que tu y gagnes énormément.

[Nanoc]

Effectivement, les chiffres sont à prendre avec des pincettes. Ils ont été obtenus en désactivant l'optimisation d'inlining. Si je la réactive, je ne vois plus aucun appel de fonction et ne peu donc rien conclure.
C'est en quelque sorte le moindre mal que de devoir désactiver l'inlining pour voir où sont les "points chauds".

De plus, une fois le code inliné, il ne doit rester dans le code que des opérations arithmétiques impliquant des nombres complexes. D'où mon espoir de pouvoir améliorer cette partie du code.
Je ne peux pas changer l'algorithme ni la méthode utilisée. Il me faut donc chercher du côté de l'implémentation.

[JolyLoic]

Effectivement, les chiffres sont à prendre avec des pincettes. Ils ont été obtenus en désactivant l'optimisation d'inlining. Si je la réactive, je ne vois plus aucun appel de fonction et ne peu donc rien conclure.
C'est en quelque sorte le moindre mal que de devoir désactiver l'inlining pour voir où sont les "points chauds".

Sauf qu'entre la version inlinée et la version non inlinée, les points chauds ne sont pas au même endroit...
Est-ce que tu as globalement les mêmes performances entre les versions inlinées et les versions non inlinées ?

Comme Luc, j'ai l'intuition que les expression templates ne vont pas forcément te gagner beaucoup pour ce genre de code. Est-ce que tu as des possibilités de paralléliser ?

[Nanoc]

Oui oui, j'en suis bien conscient. La version inlinée est beaucoup plus rapide que la version avec les appels de fonction. (Environ 10x plus rapide en -O2 que sans). Mais ce qui peut être gagné sur la version "lente" ne devrait pas péjorer la version rapide. En tout cas j'ose l'espérer.

J'utilise déjà du parallélisme basique (OpenMP).

En fait, je pensais me tourner vers des expressions templates en dernier recours. Mais comme c'est un gros boulot, je préfère me renseigner avant.

[JolyLoic]

Si tu as une grosse différence entre les deux versions, tu vas passer du temps à optimiser du code qui n'existe pas et n'est donc jamais exécuté

Est-ce que tu as fait du profiling orienté parallélisme ? Histoire de voir si tu n'es pas dans des situations de false sharing ou autre ?

[Nanoc]

C'est vrai que je risque d'optimiser du "dead code".
Comme j'avais un peu de temps à tuer, j'ai essayé de réécrire une classe Complexe ne contenant que les opérateurs dont j'ai besoin et en prenant soin d'utiliser une forme canonique pour les signatures.

Sur mon Core 2 Duo 2GHz, mon code passe de 47s à 42s. Sur une autre station de travail, quadti-coeur, la différence est plus faible mais toujours en faveur de ma version pourtant assez basique. Les deux versions sont compilées avec GCC 4.4.x et utilisent le niveau d'optimisation -O2.
Aucune différence au niveau des résultats par rapport à la version utilisant std::complex<double>

Comme tout ça m'a l'air bien parti (bien que très surprenant), je vais me lancer dans des expressions templates.