IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Julia Discussion :

Le langage Julia serait-il plus rapide que Fortran et plus propre que NumPy ?


Sujet :

Julia

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Dirigeant
    Inscrit en
    Juin 2016
    Messages
    3 160
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Dirigeant
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Juin 2016
    Messages : 3 160
    Points : 66 259
    Points
    66 259
    Par défaut Le langage Julia serait-il plus rapide que Fortran et plus propre que NumPy ?
    Le langage Julia serait-il plus rapide que Fortran et plus propre que NumPy ?
    Oui, selon Martin Maas, un développeur

    En dehors de Rust, Julia est l'autre langage de programmation qui a fait l'objet d'une grande publicité au cours de la dernière décennie. Destiné au calcul scientifique, il est le langage plébiscité pour remplacer Python, R et Fortran dans le domaine de la science des données. Dans une comparaison qu'il a faite dernièrement, Martin Maas, mathématicien et informaticien, a déclaré que Julia est plus rapide que Fortran et plus propre que NumPy (Python). Il estime que NumPy est limité au "mono-threading" dans de nombreux cas, est difficile à coder et à lire, et peut être beaucoup plus lent que Python et Fortran.

    Julia est un langage de programmation multiparadigme (entièrement impératif, partiellement fonctionnel et partiellement orienté objet) conçu pour le calcul scientifique. Il offre des gains de performance significatifs par rapport à Python (lorsqu'il est utilisé sans optimisation et calcul vectoriel en utilisant Cython et NumPy). Avec Julia, le temps de développement serait réduit d'un facteur 2 en moyenne. Les gains de performance seraient de l'ordre de 10 à 30 fois par rapport à Python (R serait encore plus lent. Les analystes estiment que le langage R n'a pas été construit pour la vitesse).

    Nom : 1.png
Affichages : 36195
Taille : 57,0 Ko

    Des rapports de l'industrie en 2016 indiquaient que Julia est un langage à fort potentiel et peut-être la chance de devenir la meilleure option pour la science des données s'il recevait un plaidoyer et une adoption par la communauté. La version 1.0 de Julia est sortie en août 2018 et il a le plaidoyer de la communauté de programmation et l'adoption par un certain nombre d'entreprises comme le langage préféré pour de nombreux domaines – y compris la science des données. En mars, la DARPA l'a choisi pour créer un framework devant permettre de multiplier par 1000 la vitesse de la simulation électronique.

    Nom : 3.png
Affichages : 5703
Taille : 41,8 Ko

    (ST : single-threaded ; MT : multi-threaded)

    Alors, est-il réellement meilleur que ces concurrents ? Après avoir réalisé quelques benchmarks sur Fortran, NumPy et Julia, Maas a déclaré que Julia était largement supérieur à ces deux outils et qu'il adoptait désormais Julia. Notons que NumPy (Numerical Python) est une bibliothèque Python utilisée pour travailler avec des tableaux. Elle dispose en outre de fonctions permettant de travailler sur l'algèbre linéaire, la transformation de Fourier et les matrices. NumPy a été créé en 2005 par Travis Oliphant. Il s'agit d'un projet open source et vous pouvez l'utiliser librement. Voici ci-dessous les résultats de ces tests.

    Julia vs Fortran vs Numpy : la vitesse et la clarté du code

    Julia est un langage assez nouveau, qui, entre autres choses, vise à résoudre le soi-disant "problème de ces deux langages" dans le calcul scientifique. En effet, Maas estime que les développeurs testent habituellement des idées dans un langage de prototypage rapide comme Matlab ou Python, mais lorsque les tests sont terminés et qu'il est temps d'effectuer des calculs sérieux, ils doivent utiliser un autre langage de programmation (compilé). « De nombreux outils existent pour faciliter la transition, et l'intégration de bibliothèques Fortran dans Python a été ma préférence jusqu'à présent », a-t-il déclaré.

    Nom : 2.png
Affichages : 5691
Taille : 16,2 Ko

    « Par exemple, envelopper un peu de Fortran avec F2PY semble être un moyen très pratique d'utiliser (et de distribuer) un code Fortran efficace que tout le monde peut exécuter. Je garde également une trace des différentes façons d'utiliser Fortran en Python dans ce post. Maintenant, Julia vise à résoudre ce problème d'une manière radicale. L'idée est d'utiliser un seul langage de programmation, qui a à la fois un mode interactif, adapté au prototypage rapide, mais qui peut aussi être compilé et exécuté à la performance C/Fortran », a ajouté le mathématicien.

    Selon Maas, Numpy serait limité au "mono-threading" dans de nombreux cas, difficile à coder et à lire et plus lent que ces alternatives. En outre, Fortran offrirait d'excellentes performances avec un code assez simple, mais certains habillages seraient nécessaires pour appeler Fortran à partir de langages de haut niveau comme Python. Enfin, Julia serait plus rapide et plus facile à écrire que Numpy et serait même capable de battre les performances de GFortran (compilateur GNU Fortran).

    Lisibilité du code : l'impact de la vectorisation manuelle

    Ici, Maas a d'abord déclaré que les opinions sur la lisibilité du code sont, bien sûr, subjectives, avant d'expliquer pourquoi il pense que Numpy offre la pire expérience en matière de qualité. Selon lui, jusqu'à présent, les langages interprétés ont nécessité une réécriture manuelle des boucles lors des opérations vectorielles. Avec un peu de pratique, cela devient peut-être une tâche facile, mais, selon Maas, la vectorisation manuelle du code serait une mauvaise pratique. « Je préfère écrire des boucles for et laisser le compilateur les vectoriser pour moi », a déclaré Mass. Considérez le code Numpy suivant, par exemple.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    n = len(a)
    M = np.exp(1j*k*(np.tile(a,(n,1))**2 + np.tile(a.reshape(n,1),(1,n))**2))
    Selon Maas, à première vue, vous ne pourrez pas deviner ce que ce code fait ni raisonner sur les performances du code. En outre, il vous sera également difficile de deviner la dimension de la sortie de M. Voici ci-dessus le même code réécrit avec Julia.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    do j=1,n
    do i=1,n
    
        M(i,j) = exp( (0,1)*k * sqrt(a(i)**2 + a(j)**2) )
    
    end do
    end do
    Les deux extraits de code ci-dessus représentent la formule mathématique suivante : M_{ij} = e^{i k \sqrt{a_i^2 + a_j^2}}.

    Selon Mass, il n'est pas étonnant qu'ils [les développeurs du langage] aient appelé Fortran "FORmula TRANslator" en premier lieu. Maas estime qu'il est intéressant de noter que la syntaxe de Julia est exactement similaire à cet égard. « Donc, même si je suis d'accord avec l'idée que Python est un beau langage pour travailler, je ne pense pas qu'il en soit de même pour Numpy. Oui, Numpy nous permet de rester dans un framework Python et de faire des choses avec de simples one-liners [uniligne – un paradigme informatique], mais le code Numpy qui en résulte devient difficile à lire par la suite », a-t-il déclaré.

    Autres comparaisons entre Python et Julia

    Julia possède plusieurs fonctionnalités et ressources avantageuses pour l'apprentissage automatique et la science des données. Il a été conçu en mettant l'accent sur le calcul numérique et scientifique. La syntaxe conviviale de Julia en fait un langage idéal pour les utilisateurs de Matlab, Octave, Mathematica, R, entre autres langages et environnements informatiques. Avec ses propres bibliothèques natives d'apprentissage automatique, Julia devrait attirer davantage d'experts en science des données à l'avenir. Un exemple d'une telle bibliothèque est Flux, et elle est composée de plusieurs modèles idéaux pour des cas d'utilisation standard.

    Elle offre un support solide pour l'interopérabilité avec d'autres paquets Julia. Flux est entièrement écrit en Julia, ce qui signifie que les utilisateurs peuvent y apporter des modifications. En revanche, Python est un langage polyvalent. Bien qu'il n'ait pas été conçu spécifiquement pour la science des données, Python offre de nombreux avantages aux spécialistes de l'apprentissage automatique et des données. Les spécialistes de l'apprentissage automatique et les scientifiques des données utilisent Python, par exemple, pour l'analyse des émotions et le traitement du langage naturel (NLP).

    En effet, les bibliothèques Python offrent un moyen pratique d'écrire des algorithmes très performants. Python existe depuis environ 30 ans, au cours desquels il a établi des relations solides avec de nombreux paquets tiers. Cela a attiré de nombreux utilisateurs. Toutefois, l'un des inconvénients associés à Python est la vitesse. Python met en œuvre de grandes améliorations, notamment au niveau de l'interpréteur Python. Le nouvel interpréteur PyPy v7.1 est rapide et fiable. Les progrès réalisés dans le domaine du traitement parallèle et multicœur devraient permettre d'accélérer Python.

    Python vs Julia : l'apprentissage automatique

    Python est utilisé pour un large éventail de tâches. Julia, en revanche, est principalement développé pour effectuer des tâches d'apprentissage automatique et de statistique. Parce que Julia a été explicitement conçu pour le travail statistique de haut niveau, il a plusieurs avantages sur Python. En algèbre linéaire, par exemple, Julia Vanilla montrerait de meilleures performances que Python Vanilla. Ceci serait principalement dû au fait que, contrairement à Julia, Python ne supporte pas toutes les équations et matrices réalisées en apprentissage automatique.

    Alors que Python est un excellent langage, en particulier avec NumPy, Julia serait supérieur à lui lorsqu'il s'agit de l'expérience non packagée, Julia étant plus adapté aux calculs d'apprentissage automatique. Le système d'opérandes de Julia serait seulement comparable à celui de R. En outre, Python serait un peu plus faible en ce qui concerne les performances, et serait un gros revers.

    Les performances en matière de vitesse

    Selon des analystes, les développeurs de Julia ont voulu créer un langage de programmation rapide. La vitesse de Julia serait égale à celle des langages compilés comme Fortran et C. Parce que ce n'est pas un langage interprété, Julia s'appuie sur les déclarations de type dans l'exécution des programmes impliquant une compilation au moment de l'exécution. Avec Julia, un développeur bénéficierait d'une grande vitesse sans nécessairement appliquer des techniques artisanales de profilage et d'optimisation. Cela ferait de Julia une solution aux problèmes de performance.

    Il serait rapide d'exécuter des programmes avec Julia compte tenu de ses fonctions numériques et de calcul complexes. De plus, il serait développé avec une fonction de distribution multiple pour assurer une définition rapide des types de données tels que les tableaux et les nombres. Par rapport à Python, des tests montrent que Julia est plus rapide. Cependant, les développeurs de Python s'efforcent d'améliorer la vitesse de Python. Certains des développements qui peuvent rendre Python plus rapide sont les outils d'optimisation, les compilateurs JIT tiers et les bibliothèques externes.

    Utilisation en science des données

    Python est utilisé pour effectuer de nombreuses tâches, dont les plus importantes sont l'analyse de données. L'une des raisons pour lesquelles Python est un outil privilégié en science des données est son écosystème favorable comprenant des applications, des outils et des bibliothèques qui rendent l'analyse de données et le calcul pratiques et rapides. Le langage Julia est né avec à l'esprit la demande croissante d'analyse de données et la nécessité de disposer d'un meilleur langage de programmation pour effectuer ces tâches.

    Selon les analystes, les développeurs de Julia ont concentré leur attention sur la création d'un langage dédié au calcul scientifique, à l'algèbre linéaire à grande échelle, à l'apprentissage automatique, au calcul parallèle et distribué. Julia aurait amélioré la vitesse de Python et aurait offert aux scientifiques des données la possibilité d'effectuer des calculs et des analyses en toute simplicité.

    Polyvalence des deux langages

    Avec Julia, les experts en sciences des données peuvent écrire des projets à partir d'autres langages et les compiler en envoyant des chaînes de caractères. Cela se produit parce que Julia est un langage de programmation polyvalent avec un code universellement exécutable en LaTeX, C, Python et R. En outre, il faudrait moins de temps pour exécuter des bouts de code complexes et importants en Julia qu'en Python. RCall et PyCall seraient très importants, étant donné que Julia est désavantagée en matière de paquets. Ainsi, vous pourrez faire appel à R et Python lorsque le besoin s'en fera sentir.

    Il est important de noter que Python est un outil fiable pour le développement Web, l'automatisation et les scripts. Ainsi, pour un langage polyvalent, Python est la meilleure option.

    Outillage et soutien communautaire

    Tout langage de programmation nécessite un soutien en matière d'outils. Au fil des ans, les utilisateurs de Python ont bénéficié d'une communauté de programmation active et solidaire, avec un support d'outils amélioré, des interfaces et des systèmes construits par cette communauté. En revanche, le support pour Julia est encore jeune. Dans son cas, le support pour des ressources importantes et des outils de débogage est minimal. Le soutien de la communauté est tout aussi important pour un langage de programmation. Considérant que Julia est un langage relativement nouveau, la taille de sa communauté est également petite.

    Il est intéressant de noter que cette communauté est très enthousiaste et s'agrandit de jour en jour. Python existe depuis des décennies, et au cours de cette période, un important soutien communautaire s'est progressivement développé. Cette grande communauté signifie des solutions adéquates aux problèmes majeurs et de multiples ressources pour répondre aux besoins des développeurs.

    Conclusion

    Python, un langage bien établi, est très important pour les domaines de la science des données et de l'apprentissage automatique. Bien que Julia soit relativement nouveau, avec moins de communauté et de support d'outils, il présente de nombreux avantages par rapport à Python. Julia a été développé pour surmonter les problèmes de vitesse. Sa familiarité avec C, R, Python et l'environnement de répartition multiple est un atout supplémentaire.

    Source : Martin Maas

    Et vous ?

    Que pensez-vous des arguments avancés par Martin Maas ? Êtes-vous de son avis ou pas ? Pourquoi ?
    Quel est votre avis sur la rivalité Python vs Julia ?
    Pensez-vous que Julia surpassera à l'avenir Python, Fortran et R ?

    Voir aussi

    Bienvenue sur julia.developpez.com

    Julia est le lauréat du prix de la DARPA pour créer un framework, devant permettre de multiplier par 1000 la vitesse de la simulation électronique


    Python serait la compétence la plus demandée pour la science des données au détriment de R, selon une analyse portant sur plus de 15 000 offres d'emploi de spécialistes des données

    Le langage de programmation Julia serait capable de lire les fichiers CSV dix à vingt fois plus vite que Python et R, selon une étude

    Les raisons de l'adoption accélérée du langage Julia : un langage polyvalent, mais plus scientifique, supporte l'introspection et la métaprogrammation, selon Lee Phillips
    Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  2. #2
    Invité
    Invité(e)
    Par défaut
    J'étais surpris que Julia ST soit plus performant que Fortran ST dans le benchmark. Je suis donc allé lire l'article. Le mec a utilisé f2py et probablement gfortran comme compilateur, c'est la pire configuration qui soit.

  3. #3
    Membre chevronné
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juillet 2007
    Messages
    884
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Juillet 2007
    Messages : 884
    Points : 2 018
    Points
    2 018
    Par défaut
    Le mec a utilisé f2py et probablement gfortran comme compilateur, c'est la pire configuration qui soit
    Ca reste que ce n'est pas vraiment un argument. Ce sont les outils de base open-source, ceux que tous utilisent.
    Évidemment qu'en mettant un expert du langage, et en achetant le compilateur a 4 ou 5 zéro, tu fera mieux... mais peut-être en Julia aussi. Le tout c'est qu'un scientifique qui a quelques notions informatique puisse faire un programme performant. Rappelons que l'idée est de faire de la data-science (donc par des non expert informatique, mais des climatologue, géologues, généticiens...) pas de concevoir une IA (avec optimisation du processeur)...
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

  4. #4
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par abriotde Voir le message
    Ca reste que ce n'est pas vraiment un argument. Ce sont les outils de base open-source, ceux que tous utilisent.
    Évidemment qu'en mettant un expert du langage, et en achetant le compilateur a 4 ou 5 zéro, tu fera mieux... mais peut-être en Julia aussi. Le tout c'est qu'un scientifique qui a quelques notions informatique puisse faire un programme performant. Rappelons que l'idée est de faire de la data-science (donc par des non expert informatique, mais des climatologue, géologues, généticiens...) pas de concevoir une IA (avec optimisation du processeur)...
    Le code fortran est appelé depuis un script python via f2py, et lui retourne un tableau d'une taille plus ou moins conséquente. Au-delà du fait que gfortran ne produit pas le code le plus optimisé du marché loin de là, le fait que l'interpréteur python doive "digérer" le tableau retourné par l'appel fortran pour le traduire en un schéma de données python, et ce de la manière la plus inefficace possible, n'aide pas niveau benchmark.

  5. #5
    Membre éprouvé

    Profil pro
    Inscrit en
    Décembre 2010
    Messages
    103
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2010
    Messages : 103
    Points : 1 035
    Points
    1 035
    Billets dans le blog
    1
    Par défaut Appeler Fortran avec f2py double le temps de calcul...
    Comme dit par Jeff_67, appeler Fortran depuis Python est une mauvaise idée pour faire un benchmark.
    La communauté Fortran-lang a analysé le problème ici (en anglais) :
    https://fortran-lang.discourse.group...han-numpy/1405

    En faisant le benchmark avec du Fortran pur bien conçu, le temps de calcul est divisé par 2 !

    Rappelons que le premier compilateur Fortran est sorti en 1957 : c'était non seulement un des premiers compilateurs (probablement le premier commercialement parlant), mais aussi un compilateur avec des optimisations déjà élaborées afin d'obtenir un code quasiment aussi rapide qu'un code écrit en assembleur. Il y a donc derrière les compilateurs Fortran 65 ans d'expérience en terme d'optimisation. Comme le C, le Fortran exploite au mieux le matériel et il est difficile de gagner grand chose. Benchmarker sur des algorithmes courts pour résoudre des problèmes très précis n'a de pertinence que pour comprendre comment fonctionnent les compilateurs et voir si on peut encore les améliorer ; et pour apprendre les bases d'un langage.

  6. #6
    lvr
    lvr est déconnecté
    Membre extrêmement actif Avatar de lvr
    Profil pro
    Responsable de projet fonctionnel
    Inscrit en
    Avril 2006
    Messages
    909
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Responsable de projet fonctionnel
    Secteur : Arts - Culture

    Informations forums :
    Inscription : Avril 2006
    Messages : 909
    Points : 1 360
    Points
    1 360
    Par défaut
    Citation Envoyé par vmagnin Voir le message
    Comme dit par Jeff_67, appeler Fortran depuis Python est une mauvaise idée pour faire un benchmark.
    Oui, mais elle reflète son paradigme de travail : 1) je prototype, 2) j'optimise mon prototype.
    En Numpy: il prototype en Numpy, et il optimise avec des inclusions Fortran. Numpy pour le proto, car prototyper en Fortran est plus compliqué, les inclusions Fortran, car il ne veut pas perdre son proto en réécrivant tout en Fortran.
    En Julia, il protype en Julia, et optimise en Julia.
    Son benchmark semble donc cohérent avec son cas d'utilisation.

  7. #7
    Membre extrêmement actif
    Avatar de Madmac
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2004
    Messages
    1 685
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Alimentation

    Informations forums :
    Inscription : Juin 2004
    Messages : 1 685
    Points : 1 376
    Points
    1 376
    Billets dans le blog
    7
    Par défaut
    Je serais curieux de voir les résultats avec différentes version de Fortran.

    Pour le reste, aucune surprise. Dans le domaine des statistiques et du deep-learning, Python a un énorme concurrent.

  8. #8
    Membre éprouvé

    Profil pro
    Inscrit en
    Décembre 2010
    Messages
    103
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2010
    Messages : 103
    Points : 1 035
    Points
    1 035
    Billets dans le blog
    1
    Par défaut Titre
    Son benchmark semble donc cohérent avec son cas d'utilisation.
    Oui, mais disons que le titre de l'article de Martin Maas est accrocheur et ne reflète pas exactement ce qui est fait.

Discussions similaires

  1. Access plus rapide que SQL server ????? (débutante)
    Par 24 faubourg dans le forum MS SQL Server
    Réponses: 10
    Dernier message: 21/12/2005, 17h36
  2. [D7] composants plus rapides que dbExpress pour Oracle 8i
    Par Magnus dans le forum Bases de données
    Réponses: 2
    Dernier message: 10/10/2005, 12h06
  3. Plus rapide que bresenham ?
    Par mathieu_t dans le forum Algorithmes et structures de données
    Réponses: 3
    Dernier message: 01/06/2005, 13h28
  4. [VB6] timer plus rapide que 1 d'interval
    Par windob dans le forum VB 6 et antérieur
    Réponses: 12
    Dernier message: 24/02/2004, 00h16
  5. Réponses: 8
    Dernier message: 31/10/2003, 16h21

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo