Logiciel pour du calcul matriciel efficace

Bonjour,

Toujours dans le cadre de mon projet de calcul de la position du soleil dans le ciel, je suis désormais confronté à un souci de performance.
Je cherche à modéliser la cinématique du mouvement de la terre au cours d’une année. On a donc 130 000° de rotation terrestre environ à modéliser. Je cherche à faire apparaitre des problèmes comme la différence de longueur du jour due à la variation de la vitesse de la terre sur son orbite, et la variation de « l’obliquité relative » qui mène aussi à une variation de la durée du jour, deux phénomènes retrouvés dans l’équation du temps. Ceux là, pour être traités confortablement, me demanderaient idéalement une précision de 4 secondes.
Cela fait donc.. près de 8 millions de lignes de calcul.
Chaque calcul consiste à appliquer une vingtaine de calculs matriciels 3x3.

Quel logiciel est le plus optimisé pour du calcul matriciel en masse ?
Je connais un peu matlab et python.
Le gain de performances sera-t-il notable par rapport à du VBA ? Sachant que j’ai appliqué les optimisations de base du VBA.

Merci

Tu continues à faire des choses étranges…
La première chose à faire serait de voir comment simplifier tes 20 produits de matrices, peut être en les regroupant au mieux.

Il faudrait voir quelles operations tu fais et comment tu calcules tes produits, comment tu les simplifies/optimises/ordre/memoire/etc. mais…

!!! Team FORTRAN !!! <3 (ou C, allez a la rigueur)

Plus serieusement, si c’est pour du pratique/cambouis, en terme de logiciel, matlab (/ octave, pour la version GNU) te suffira probablement.
Pas sur d’une amelioration considerable par rapport au vba, vu que matlab reste un langage pas bien efficace, mais bon.

thomasgara, post:3, topic:132123 a écrit:

Il faudrait voir quelles operations tu fais et comment tu calcules tes produits, comment tu les simplifies/optimises/ordre/memoire/etc. mais…

!!! Team FORTRAN !!! <3 (ou C, allez a la rigueur)

Plus serieusement, si c’est pour du pratique/cambouis, en terme de logiciel, matlab (/ octave, pour la version GNU) te suffira probablement.
Pas sur d’une amelioration considerable par rapport au vba, vu que matlab reste un langage pas bien efficace, mais bon.

Fortran représenterait quel gain d’efficacité ? Car dans l’affaire je dois aussi plotter et visualiser des données.
L’avantage d’excel c’est aussi de pouvoir visualiser les données facilement, y compris sous forme de tableau ou graphe.

Matlab j’y ai pensé car je pensais qu’il était optimisé pour les calculs matriciels ?
En plus je connais un peu.

Aucune gestion de la mémoire en vba.
Les optimisations de base du code consistent à calculer et écrire dans le code et non dans les cellules, puis tout écrire d’un coup à la fin.

Peut être que simplement déplacer le fichier sur le SSD de mon pc pourrait accélérer certaines opérations nécessitant d’accéder à la mémoire disque déjà…

phesm, post:2, topic:132123 a écrit:

Tu continues à faire des choses étranges…
La première chose à faire serait de voir comment simplifier tes 20 produits de matrices, peut être en les regroupant au mieux.

En écrivant le code je me suis aperçu que certaines matrices étaient identiques et je ne les calcule qu’une fois.
Les améliorations que je vois consistent peut être à remplacer trois calculs 31 en un calcul 33 mais à part ça…
Les calculs matriciels consistent à faire pivoter un point (confondu avec son vecteur radial) puis deux autres axes autour d’axes distincts, d’angles distincts, avec un cheminement différent pour les 3, donc je ne pense pas que ce soit facile d’en enlever.

On peut par contre peut être optimiser mon calcul de matrice de rotation (j’utilise la formule générale de matrice de rotation donnée par maple) et mon calcul de multiplication matricielle (triple boucle for) ?

Je cherche juste à faire une représentation cinématique du système terre-soleil, le problème cinématique est déjà assez compliqué en lui même. J’ai fait tout « correctement » et je trouve bien une équation du temps de la bonne forme, de la bonne amplitude, signe qu’il y a du vrai là dedans, mais à l’envers, ce qui reste incompris à ce stade.

Je pense que mon ordinateur pourrait faire tourner le calcul 10 à 15 fois plus vite au moins car à peine 7% du processeur est utilisé.
30 secondes pour l’année deviendrait 2 secondes, ça aiderait pas mal.

Profite de ce projet qui semble te tenir à cœur pour apprendre un nouveau langage (Python, par exemple, avec numpy / matplotlib).
Tu pourras ensuite constater les différences de performance s’il y en a.

Je ne pige pas l’expression « 8 millions de lignes de calcul ».

schnirelmann, post:5, topic:132123 a écrit:

Profite de ce projet qui semble te tenir à cœur pour apprendre un nouveau langage (Python, par exemple, avec numpy / matplotlib).
Tu pourras ensuite constater les différences de performance s’il y en a.

Je ne pige pas l’expression « 8 millions de lignes de calcul ».

13000 degrés de rotation terrestre par an.
Un degré de rotation c’est environ 4 minutes.
Pour passer à une résolution de 4 secondes ça fait donc 130000*60=7.8 millions de lignes de résultat plus exactement.
Mais chaque ligne de résultats résulte d’un seul calcul (les 10-15-20 matrices je sais plus).

Je propose Julia:

https://julialang.org/

Victoire !
Je trouve désormais une équation du temps correcte :

Le souci comme vous le voyez, c’est maintenant la performance du logiciel.
En 30 secondes j’ai pu tracer la courbe ci dessous qui n’est pas parfaite mais a clairement un sens physique.
Si je réduis la précision du calcul (écartement entre deux étapes supérieur à 1° de rotation terrestre) j’obtiens cette courbe qui a toujours du sens physique mais il faut le chercher… :
https://i.gyazo.com/efe168ae7a9a7e26e71ddd62444e4141.png
Si j’augmente au contraire la précision du calcul, j’obtiens une courbe plus lisse mais toujours pas bien lisse.
https://i.gyazo.com/4db6159106c89cb51dc064a011049779.png

J’ai maintenant un souci de précision.
Je me demande ce qui relève de la précision astronomique (gestion des années bissextiles, lente modification de l’orbite terrestre, etc..) et donc pour le coup des vrais professionnels et ce qui pourrait relever du manque d’optimisation/puissance du calcul, avec peut-être un souci de chiffres significatifs ou d’optimisations ad hoc du code (avec perte de généralité dans les résultats).

phesm, post:6, topic:132123 a écrit:

Pour passer à une résolution de 4 secondes ça fait donc 130000*60=7.8 millions de lignes de résultat plus exactement.
Mais chaque ligne de résultats résulte d’un seul calcul (les 10-15-20 matrices je sais plus).

Ok, dans n’importe quel autre vrai langage on ne parle pas de ligne, c’est juste une variable de dimension 8 millions.

Par exemple en Python :

x = linspace(-pi, pi, 8e6)
y = cos(x)
plot(x,y)	# graphe 2D de deux vecteurs de dimension 8 million

La ligne « y = cos(x) » prend moins d’une seconde à calculer sur mon PC.
Le graphe prend environ 1 seconde.

Comme vu plus haut, Julia est sympa à découvrir également.

C’est moi qui parle de ligne car je ne suis pas informaticien :slight_smile: ( ou :frowning: d’ailleurs )

Merci pour les chiffres !
Python est clairement plus rapide que excel !
Le calcul équivalent de x et de y=cos(x) prend environ une seconde (à peu près équivalent donc, pour la partie VBA).
Par contre le graphe de 8 millions de lignes, déjà, n’est pas possible. Il n’y a que 10^6 environ lignes de disponibles dans la feuille de calcul. L’écriture du tableau prend 1.75 secondes (étape inexistante en python, à moins que tu ne la demandes)

Par contre sur le graphe, là c’est autre chose.
6 secondes pour avoir un graphe de 1 millions de points. Avec un temps linéaire (ou presque). Si on tient compte du fait que tu as 8 millions de points, python serait 50 fois plus rapide !
Pourtant mon PC est une machine de guerre, le problème ne vient pas de là. Il vient certainement de l’accès requis au disque dur (plus lent) et au fait que excel n’utilise pas la pleine puissance de calcul de mon PC (mais 10% maximum environ)

Rien à voir avec le disque dur car tout est en mémoire. Ça vient du fait que Excel n’est pas fait pour faire ça.

Mais du coup je ne pige pas les 8 millions de ligne, si Excel a une limite à 6 millions. Enfin c’est pas très grave : Excel n’est pas fait pour ce job.

Tu devrais te mettre à un autre langage, ce type de projet est parfait pour s’en donner la motivation :

  • Arrête tes développements sous Excel
  • Reproduis les fonctionnalités actuelles dans un autre langage (généralement on est assez content à cette étape)
  • Amuse-toi un peu à comparer les performances si ça te tient à cœur
  • Améliore ton programme dans le nouveau langage uniquement

Bonjour,

Puisqu’il est question de suggérer autre chose, pour les temps de calcul dont tu as besoin, il y a des outils dédiés à ça, mais je ne vois pas d’autre solution que d’utiliser le C ou le C++.

Pour tes calculs, je suggère glm : https://github.com/g-truc/glm

Pour l’interface graphique, je suggèrerais : https://github.com/ocornut/imgui (ultra portable, tous les OS majeurs), associé à SDL2 (pour le fenêtrage et la super portabilité)/

Pour le tracé des courbes, j’utiliserais ImPlot (basé sur ImGui) : https://github.com/epezent/implot

Avec une machine récente, ça devrait se faire autour des 400 fps minimum. Mais c’est du C++

Comme les autres, personnes ayant répondu, je pense qu’il vaut mieux oublier Excel :slight_smile: , mais c’est toutefois un excellent choix pour ce qu’on appelle une preuve de concept. Dans une conception saine, c’est très intéressant de « concrétiser » une idée, rien que pour l’expliquer aux autres, avec un tableur ou un outil interprété basique.

Ce ne sont que des suggestions, et je retourne à mes copies ^^^

thomasgara, post:3, topic:132123 a écrit:

!!! Team FORTRAN !!! <3 (ou C, allez a la rigueur)

Team Julia <3 <3 <3

En vrai, Fortran j’aime beaucoup comme ça, mais le langage est un peu sénile. En pratique pour faire des trucs concrets rapidement sur des vecteurs de grande taille (genre fft) il faut de la mémoire aligné (sinon il fait pas mieux que python en fait), sauf que le language a été conçu à l’époque des processeurs 8bits, donc la gestion de mémoire en 64 bits ça marche vraiment pas.

Le C il y a rien à dire, ça fait le taff, mieux que tout le reste d’un certain point de vue, il faut juste aimer quoi :grin:

Mais comme tout le monde je plussois l’avis général : oui python c’est lent, et ne parlons pas d’excell pour faire du calcul scientifique. Tu peux utiliser pleins de trucs, ça demande juste un peu de temps de prise en main. Je recommande peut être plutôt Julia ou LuaJIT que C. Mais sinon à priori pour du calcul matriciel je pense que Fortran peut très bien faire l’affaire.

Après faudrait voir les codes, du python bien écrit avec 0 lignes en pur python (full numpy/scipy, avec des numpy.roll, matmul et co) ça tourne plutôt très vite, surtout si on accélère avec des packages de type JIT (Just-In-Time compilation).

oui python c’est lent, et ne parlons pas d’excel pour faire du calcul scientifique

Ca n’a pas beaucoup de sens.
Oublions déjà Excel qui n’est pas fait pour ça.
Python non plus mais personne ne fais les calculs en python.
Quand on fait du numpy ou du scipy, les calculs sont fait en fortran ou en C sous le manteau. Ce n’est pas toujours ultra optimisé et il y a qlqs overheads mais ce n’est pas la lenteur des boucles en python qui limite quoique ce soit.
La parallelisation dépend aussi directement de la façon dont les libs blas/lapack ont été compilées. rien à voir avec le python lui même.

Julia, oui c’est intéressant car le design du langage est bien foutu.

Pour info :
https://www.mathworks.com/help/matlab/math/lapack-in-matlab.html
https://reference.wolfram.com/language/tutorial/SomeNotesOnInternalImplementation.html#7441
« For dense arrays, LAPACK algorithms extended for arbitrary precision are used when appropriate.
BLAS technology is used to optimize for particular machine architectures »

bref tout le monde utilise ces libs qui vont bien et wrap tout ça a sa sauce.