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

  1. #1
    Chroniqueur Actualités

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

    Julia est un langage de programmation dont la première version remonte à août 2009. C’est un langage de haut niveau, performant et dynamique conçu pour le calcul scientifique. Il a une syntaxe familière aux utilisateurs d'autres environnements de développement similaires. Depuis sa première version stable, Julia est plébiscité comme l’un des meilleurs langages de la science des données, sinon le meilleur. D’après une récente étude, il serait capable de lire les fichiers CSV (ou Comma-Separated Values) 10 à 20 fois plus vite que les langages de programmation rivaux Python et R.

    Selon les auteurs de l’étude, la toute première tâche dans tout processus d’analyse de données consiste simplement à lire les données, et cela doit absolument être fait rapidement et efficacement pour que le travail le plus intéressant puisse commencer. Dans de nombreux secteurs et domaines, le format de fichier CSV est le format le plus utilisé pour le stockage et le partage des données tabulaires. Le chargement rapide et robuste des CSV est crucial, et il doit être bien adapté à une grande variété de tailles, de types et de formes de fichiers.

    L’étude a donc comparé les performances de lecture de huit ensembles de données réelles différents sur trois analyseurs CSV différents : fread de R, read_csv de Pandas et CSV.jl de Julia. Chacun d'eux est considéré comme étant le “meilleur de sa catégorie” dans les analyseurs CSV de R, Python et Julia, respectivement. Les trois outils ont une prise en charge robuste pour le chargement d'une grande variété de types de données avec des valeurs potentiellement manquantes, mais seuls fread (R) et CSV.jl (Julia) prennent en charge le multithreading.


    Pandas ne prend en charge que le chargement à thread unique. CSV.jl est en outre unique en ce sens qu'il est le seul outil entièrement implémenté dans son langage de haut niveau plutôt que d'être implémenté en C et enveloppé de R ou de Python. Pandas dispose d'un analyseur natif Python légèrement plus performant, il est nettement plus lent et presque toutes les utilisations de read_csv se font par défaut sur le moteur C. Ainsi, les benchmarks CSV.jl représentent ici non seulement la vitesse de chargement des données dans Julia, mais sont aussi indicatifs des types de performances possibles dans le code Julia ultérieur utilisé dans l'analyse.

    Les benchmarks suivants montrent que le CSV.jl de Julia est de 1,5 à 5 fois plus rapide que Pandas, même sur un seul thread. Avec le multithreading activé, il est aussi rapide ou plus rapide que read_csv de R. Enfin, les outils utilisés par l’équipe pour l'étalonnage sont BenchmarkTools.jl pour Julia, microbenchmark pour R et timeit pour Python. Voici les résultats obtenus.

    Analyse comparative sur les données homogènes

    Les ensembles de données homogènes sont des ensembles de données qui comportent le même type de données dans toutes les colonnes. La mesure de performance est le temps nécessaire pour charger un ensemble de données lorsque le nombre de threads passe de 1 à 20. Et comme Pandas ne prend pas en charge le multithreading, la vitesse d'un seul thread est indiquée pour tous les comptages de base. L’étude a été réalisée sur quatre catégories de données homogènes, dont des données flottantes uniformes et deux types de données de chaînes uniformes et des données sur Apple.

    En premier lieu, l’ensemble de données flottantes uniformes contient des valeurs flottantes disposées en 1 million de lignes et 20 colonnes. Pandas prend 232 millisecondes pour charger ce fichier CSV. Le fichier data.table, sur un seul thread, est 1,6 fois plus rapide que le fichier CSV.jl de Julia. Avec le multithreading, CSV.jl est à son meilleur, soit plus du double de la vitesse de data.table. Il est 1,5 fois plus rapide que Pandas sans multithreading, et environ 11 fois plus rapide avec. En second lieu, l’analyse comparative a porté sur le premier ensemble de données de chaînes uniformes.

    Cet ensemble contient des valeurs de chaîne dans toutes les colonnes et compte 1 million de lignes et 20 colonnes. Pandas prend 546 millisecondes pour charger le fichier. Avec R, l'ajout de threads ne semble pas entraîner de gain de performance. Avec un seul thread, CSV.jl est 2,5 fois plus rapide que data.table. Avec 10 threads, il est environ 14 fois plus rapide que data.table. Ensuite, il y a le second ensemble de données sur les chaînes uniformes. Les dimensions de cet ensemble sont les mêmes que celles de l'ensemble de données précédent. Cependant, chaque colonne comporte également des valeurs de type Missing (des données manquantes).

    Ici, Pandas prend 300 millisecondes. Sans threading, CSV.jl est 1,2 fois plus rapide que R, et avec, il est environ 5 fois plus rapide. Enfin, les données sur Apple concernent le cours des actions de l’entreprise. Cet ensemble de données contient 50 millions de lignes et 5 colonnes, et fait 2,5 Go. Les lignes sont les prix ouverts, élevés, bas et de clôture de l'action AAPL. Les quatre colonnes avec les prix sont des valeurs flottantes, et il y a une colonne de date. Avec un seul thread, CSV.jl est environ 1,5 fois plus rapide que fread.

    Avec le multithreading, CSV.jl est environ 22 fois plus rapide. read_csv de Pandas prend 34s pour lire le fichier, c'est plus lent que R et Julia.

    Performances sur des ensembles de données hétérogènes

    Dans cette partie de l’étude, la première comparaison s’est basée sur un ensemble de données mixtes. Cet ensemble de données comporte 10 000 lignes et 200 colonnes. Les colonnes contiennent les valeurs String, Float, DateTime et aussi des valeurs de types Missing. Ici, Pandas prend environ 400 millisecondes pour charger cet ensemble de données. Sans threading, CSV.jl est 2 fois plus rapide que R, et est environ 10 fois plus rapide avec 10 threads. L’analyse comparative suivante concerne un ensemble de données sur les risques hypothécaires, plus large.

    Cet ensemble de données sur les risques hypothécaires de Kaggle est un ensemble de données de type mixte, avec 356 000 lignes et 2190 colonnes. Les colonnes sont hétérogènes et ont des valeurs de type String, Int, Float, Missing. Pandas prend 119s pour lire dans cet ensemble de données. Avec un seul thread, fread est environ 2 fois plus rapide que CSV.jl. Mais avec plus de threads, Julia est soit aussi rapide, soit un peu plus rapide que R.

    Source : Julia Computing

    Et vous ?

    Que pensez-vous de cette étude ? Pertinente ou pas ?
    Entre Julia, Python et R, lequel utilisez-vous pour la science des données ? Pourquoi ?

    Voir aussi

    Sortie de Julia 1.3, avec une implémentation largement améliorée de l'exécution en multifil. Julia 1.4 se focalisera sur la diminution de la latence

    Science des données : Julia, R ou Python ? Un petit aperçu des avantages et inconvénients du langage Julia

    Julia et les graphes, présentation de la bibliothèque LightGraphs et de son écosystème, un tutoriel de Thibaut Cuvelier
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Responsable Qt & Livres

    On dirait plutôt que CSV.jl est plus lent que l'implémentation de R pour la lecture de fichiers CSV, mais exploite de manière beaucoup plus efficace le parallélisme. Resterait-il encore de la marge pour améliorer la performance ou bien cette dégradation est-elle nécessaire pour le parallélisme (c'est-à-dire qu'une implémentation sérielle serait nécessaire à côté) ?
    Vous souhaitez participer aux rubriques Qt (tutoriels, FAQ, traductions) ou HPC ? Contactez-moi par MP.

    Créer des applications graphiques en Python avec PyQt5
    Créer des applications avec Qt 5.

    Pas de question d'ordre technique par MP !

  3. #3
    Membre expérimenté
    Julia poyur remplacer Python
    Je vote pour remplacer Python par Julia. Il apporte une rapidité d'exécution bien supérieur avec une simplicité d'utilisation parfaite pour un langage de script (interprété). Il représente le parfait compromis, simplicité/efficacité.

    Bien que légèrement plus complexe que Python à aborder il offre un code plus clair et sécurisé car typé. Il n'est pas plus complexe que Python pour un développeur confirmé. C'est la première marche qui est un poil plus haute (Mais franchi par les scientifiques pas que par les informaticiens).

    Je me suis personnellement convertis a Julia pour le plus grand plaisir de mon PC
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

  4. #4
    Expert confirmé
    Citation Envoyé par abriotde Voir le message
    Je vote pour remplacer Python par Julia.
    Quand il y a besoin de performances bien meilleures que celles de Python, sans avoir besoin d'atteindre celles de C/C++/Rust, oui. Dans sa conception, Python a beaucoup sacrifié les performances, contrairement à Julia qui en a tenu compte.

    Citation Envoyé par abriotde Voir le message
    Bien que légèrement plus complexe que Python à aborder il offre un code plus clair et sécurisé car typé.
    J'avais testé un peu Julia, mais il n'a visiblement pas été conçu pour le typage statique. À ce niveau, il est même derrière Python.

    Python, au départ, était un langage dépourvu de typage statique. Mais, ensuite, depuis Python 3.5 avec PEP 484, on a un système d'annotations de types qui permet à des outils comme mypy de vérifier statiquement le typage, c'est-à-dire de repérer les erreurs de types sans avoir besoin d'exécuter le code. Précisons que, en Python, les annotations de type ne servent malheureusement pas à améliorer les performances. Dans la majorité des cas, elles forment une sorte de documentation pour laquelle des outils peuvent vérifier statiquement la cohérence avec le code.

    En Julia, les types servent à optimiser le code lors de la compilation à la volée, pas à faire du typage statique. Il n'y a pas d'équivalent à mypy en Julia. Et, comme pour Python, ça va être compliqué d'ajouter du typage statique a posteriori pour un langage qui n'a pas été pensé pour dès le départ.

    Par exemple, dans la bibliothèque standard de Julia, les types Year, Month, Week, Day, Hour, Minute, Second, Millisecond, Microsecond et Nanosecond sont définis ainsi :
    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    for T in (:Year, :Month, :Week, <img src="images/smilies/icon_biggrin.gif" border="0" alt="" title=":D" class="inlineimg" />ay)
        @eval struct $T <: DatePeriod
            value::Int64
            $T(v::Number) = new(v)
        end
    end
    for T in (:Hour, :Minute, :Second, :Millisecond, :Microsecond, :Nanosecond)
        @eval struct $T <: TimePeriod
            value::Int64
            $T(v::Number) = new(v)
        end
    end

    Source : https://github.com/JuliaLang/julia/b...s/src/types.jl

    C'est factorisé, c'est beau, mais comment un analyseur statique peut deviner qu'il a le droit d'exécuter ces boucles for pour y découvrir les définitions des types ?

    En langage D, qui est compilé et statiquement typé mais qui possède aussi une bonne puissance d'abstraction, on a une distinction claire entre foreach, pour lequel l'agrégat peut être évalué à l'exécution, et static foreach, pour lequel l'agrégat est évalué directement à la compilation, ce qui autorise à faire de la métaprogrammation dans la boucle. En Julia, par contre, il n'y a pas cette distinction.

  5. #5
    Membre averti
    Citation Envoyé par Pyramidev Voir le message
    Quand il y a besoin de performances bien meilleures que celles de Python, sans avoir besoin d'atteindre celles de C/C++/Rust, oui. Dans sa conception, Python a beaucoup sacrifié les performances, contrairement à Julia qui en a tenu compte.
    En général quand tu en vient à avoir besoin de perf importante en python tu va écrire les parties critiques en C et les wrapper, c'est ce qui est fait dans toute les libs scientifique de mémoire.

  6. #6
    Membre expérimenté
    En général quand tu en vient à avoir besoin de perf importante en python tu va écrire les parties critiques en C et les wrapper
    Oui mais c'est complexe tant à développer qu'a intégrer et à utiliser pour une performance parasité par l'interaction constante Python/C++. Si l'on peux en amont, dans 80% des cas éviter ce genre de pirouette on y gagne.
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

  7. #7
    Expert confirmé
    Citation Envoyé par Pyramidev Voir le message
    Quand il y a besoin de performances bien meilleures que celles de Python, sans avoir besoin d'atteindre celles de C/C++/Rust, oui.
    Les performances de Julia sont assez proches de C/C++/Rust, mais ça demande une certaine expertise pour y arriver...

    Citation Envoyé par Pyramidev Voir le message
    J'avais testé un peu Julia, mais il n'a visiblement pas été conçu pour le typage statique.
    C'est même le contraire : le typage dynamique fait partie des motivations initiales de Julia.

    Citation Envoyé par Pyramidev Voir le message
    ...
    C'est factorisé, c'est beau, mais comment un analyseur statique peut deviner qu'il a le droit d'exécuter ces boucles for pour y découvrir les définitions des types ?

    En langage D, qui est compilé et statiquement typé mais qui possède aussi une bonne puissance d'abstraction, on a une distinction claire entre foreach, pour lequel l'agrégat peut être évalué à l'exécution, et static foreach, pour lequel l'agrégat est évalué directement à la compilation, ce qui autorise à faire de la métaprogrammation dans la boucle. En Julia, par contre, il n'y a pas cette distinction.
    Julia a des types polymorphes, un compilateur JIT, et un système de macro basé sur l'AST. Ce n'est pas de l'analyse/évaluation statique à la D mais c'est également très puissant.

    Citation Envoyé par abriotde Voir le message
    Je vote pour remplacer Python par Julia. Il apporte une rapidité d'exécution bien supérieur avec une simplicité d'utilisation parfaite pour un langage de script (interprété). Il représente le parfait compromis, simplicité/efficacité.
    Julia c'est très bien pour les domaines relatifs au calcul et pour éviter le "two-language problem" mais Python a quand même beaucoup de domaines où il "juste fait le job".

  8. #8
    Responsable Qt & Livres

    Un autre utilisateur rapporte une accélération d'un facteur 334 en passant de Python à Julia : https://twitter.com/RobBlackwell/sta...40653222166534
    Vous souhaitez participer aux rubriques Qt (tutoriels, FAQ, traductions) ou HPC ? Contactez-moi par MP.

    Créer des applications graphiques en Python avec PyQt5
    Créer des applications avec Qt 5.

    Pas de question d'ordre technique par MP !

  9. #9
    Futur Membre du Club
    Et Java
    Que donnerait un benchmarking avec Java?

  10. #10
    Membre du Club
    Python peut être performant
    Je ne connais pas Julia, sans doute un très bon langage, par contre je connais python depuis presque 20 ans. J'ai fais un grand nombre de chose avec, dont des choses temps réel avec. Quand on se penche un tout petit peu sur l'optimisation du code, on arrive très facilement a produire du code rapide, est même extrêmement rapide. Pour certaine partie je n'aurai pas eu mieux en codant en c++, j'aurai même pu avoir pire si j'avais utilisé les stl (au fil des années les stl sont devenu extrêmement lourd en temps d'exécution).

    La règle de 80% du temps est passé dans 20% du code, est la même quelque soit le langage. Je suis prêt à parier qu'une petite optim aurai réduit la différence la rendant infime.

    Comme tout nouveau langage, Julia a sans doute des atouts, mais les forces de python, sont d'être présent depuis très longtemps, de disposer de modules additionnels dans tous domaines, de disposer de documentation, tutoriaux, d'avoir une grande stabilité, et une communauté très active. Tout cela n'est probablement pas existant sur Julia. Dans 10 ans si Julia est adopté, là il vaudra peut être le coup de s'y intéresser, sinon cela n'aura été qu'un nième langages de plus dans une galaxie de langages existants.

  11. #11
    Expert confirmé
    Citation Envoyé par remi_inconnu Voir le message
    Quand on se penche un tout petit peu sur l'optimisation du code, on arrive très facilement a produire du code rapide, est même extrêmement rapide. Pour certaine partie je n'aurai pas eu mieux en codant en c++, j'aurai même pu avoir pire si j'avais utilisé les stl (au fil des années les stl sont devenu extrêmement lourd en temps d'exécution).
    J'ai beaucoup de mal à y croire. Si tu as des liens ou des exemples de code où Python est plus rapide que C++, je serais curieux de les regarder.

###raw>template_hook.ano_emploi###