Discussion :

[Supernul]

Bonjour,

Dans le cadre de mes travaux de recherche, je développe des modèles qui commencent à être de plus en plus gourmands en temps de calcul et certains algorithmes (comme un dérivé de l'approximation de Vogel en recherche opérationnelle, qui use des boucles) ne sont pas parallèlisables. Sur les données de test, Python fait encore le travail mais dès qu'on utilise les jeux de données complet, les temps de calcul explosent.

J'utilise Python car c'est le langage prédominant dans le domaine de l'information géographique (modélisation, simulation, apprentissage (ML, DL, stats), analyse), donc collaboration simplifiée avec d'autres chercheurs et une batterie de packages pour créer des GUI et du standalone (utilisateur final et certains collègues qui se limitent au clic-bouton) afin que les outils développés ne restent pas dans les placards.

J'envisage de passer à un autre langage en remplacement ou complément comme :
- C++ (complément) : +rapidité, +bibliothèques existantes, -courbe d'apprentissage, -problème des deux langages
- Java (remplacement) : +multiplateforme, +présent dans le domaine, -intégration avec les outils existants (QGIS en python/C++)
- Julia (remplacement) : +courbe d'apprentissage, -pas certain que tout soit "facilement" faisable (GUI, standalone)

Je suis preneur de tout commentaire, remarque, réflexion, ... avant de me positionner.
Merci par avance.

[dourouc05]

Sur les données de test, Python fait encore le travail mais dès qu'on utilise les jeux de données complet, les temps de calcul explosent.

Es-tu sûr que ce problème est dû à Python ou est-ce juste que le problème est trop difficile/l'algorithme pas assez efficace ? Utilises-tu déjà Python au bout de ses capacités (numpy, opérations vectorielles) ?

certains algorithmes (comme un dérivé de l'approximation de Vogel en recherche opérationnelle, qui use des boucles) ne sont pas parallèlisables

À quel point n'est-ce pas parallélisable ? N'as-tu pas de jeu de données assez gros pour qu'une boucle complète ne soit pas parallélisable, justement ? Je ne connais pas l'approximation de Vogel, mais ça semble être un problème de transport, que l'on peut résoudre comme un LP avec une méthode de point intérieur parallélisable (au moins l'algèbre linéaire).

J'envisage de passer à un autre langage en remplacement ou complément comme :

Python sera difficile à battre en termes d'écosystème. Avec du C++ et du Julia, tu pourras communiquer assez efficacement avec Python. La transition de Python à C++ sera douloureuse (sauf si tu as déjà de bonnes habitudes de programmation en C++).

- Java (remplacement) : +multiplateforme, +présent dans le domaine, -intégration avec les outils existants (QGIS en python/C++)

Niveau performance, Java n'est plus aussi horrible qu'à ses débuts, mais je reste dubitatif pour des codes d'analyse numérique. Oui, il existe beaucoup de bibliothèques d'algèbre linéaire, par exemple, mais j'ai du mal à avoir des comparaisons avec des bibliothèques natives (implémentations de BLAS comme MKL ou OpenBLAS) : http://lessthanoptimal.github.io/Jav...1_12_Xeon1250/ est le seul exemple que j'ai trouvé et je n'y comprends pas grand-chose.

- Julia (remplacement) : +courbe d'apprentissage, -pas certain que tout soit "facilement" faisable (GUI, standalone)

Julia sera probablement, des trois, le plus facile à apprendre venant de Python. Maintenant, tu ne dois pas forcément faire un choix drastique entre Julia et Python : pyjulia te permet d'appeler du code Julia depuis Python et PyCall d'appeler du code Python depuis Julia (y compris des bibliothèques plus compliquées comme PyQt ou PyGTK pour les interfaces graphiques). Redistribuer un paquet Python qui utilise Julia sera probablement un tantinet emmerdant (soit installer Julia en même temps que ton paquet, soit compiler ton paquet Julia comme une bibliothèque partagée), probablement plus que si c'était du code C++, mais c'est possible (et ça deviendra plus facile avec le temps).

[Supernul]

Bonjour,

Merci pour ce retour détaillé.

C'est effectivement un problème de transport pour l'affectation des demandes aux parcelles. Avec un collègue informaticien non spécialiste de l'optimisation, nous avions testé deux autres approches relevant de l'algèbre linéaire qui ne donnaient pas un résultat satisfaisant. J'ai testé une approche basée sur le problème du sac-à-dos qui ne correspond pas aux caractéristiques du problème à résoudre.
J'utilise intensivement numpy et scipy pour tout le modèle et scikit, tensorflow plus spécifiquement pour la partie calibration et segmentation.

Je vais me renseigner sur la méthode du point intérieur.