Discussion :

[Bill Fassinou]

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

[dourouc05]

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é) ?

[abriotde]

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

[Pyramidev]

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.

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, :Day)
    @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.

[Andarus]

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.

[abriotde]

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.

[Invité]

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...

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.

...
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.

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".

[dourouc05]

Un autre utilisateur rapporte une accélération d'un facteur 334 en passant de Python à Julia : https://twitter.com/RobBlackwell/sta...40653222166534

[diyoyo]

Que donnerait un benchmarking avec Java?

[remi_inconnu]

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.

[Invité]

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.

[Sve@r]

Bonjour

Python n'a jamais argumenté d'être le meilleur en quoi que ce soit. Même ses plus fervents partisans le savent et le disent parfaitement que Python n'est pas le meilleur langage en quoi que ce soit. Ce n'est pas son but. Son but est juste d'essayer d'être à la fois très sympa, très facile à apprendre, très présent dans tous les domaines généraux de l'informatique. Et à mon avis il y a parfaitement réussi.
Je n'ai absolument rien contre celui qui viendra me dire "oui j'ai utilisé Julia pour tel besoin et franchement j'ai été super content parce qu'en Python j'aurais eu tel problème que je n'ai pas eu avec Julia". Mais tous les mono-neurones qui viennent dire "meuh il faut remplacer Python par Julia" (avec le "il faut" bien ancré du haut de leur certitude) ils n'ont rien compris à Python, il est possible qu'ils n'aient rien compris à Julia mais surtout ils n'ont pas lu cette citation de Herbert Mayer qui dit "Aucun langage de programmation n'est parfait. Il n'existe même pas un langage meilleur que d'autre ; il n'y a que des langages en adéquation ou peu conseillés pour des buts particuliers."

Ok, Julia lit les CSV 20 fois plus vite que Python et alors ? J'ai développé 6 projets différents en Python et je n'ai eu à lire qu'une seule fois du CSV. Et en plus le CSV (qui fait en moyenne 9000 lignes sur 14 colonnes) je ne le lis qu'une fois à peu près tous les 4 mois (quand mon client a de nouvelles infos) pour charger la bdd. Ca me prend à peu près 3mn (je viens de relancer un chargement juste pour chronométrer). Ok, si demain on me donne un projet où il faudra lire du CSV de plusieurs milliers de lignes à répétition qui arrive à chaque secondes ok peut-être que je penserai à Julia mais d'ici là, Python s'interface avec Qt, Tk, Gtk, MySQL, Postgres, SQLIte, Json, son csv n'est pas dégueu, possède des librairies de traitement de matrices, d'analyse de trames réseau, de programmation parallèle, asynchrone, peut calculer les fractions, les nombres complexes, les nombres décimaux sans perte d'exactitude bref il me permet de faire tout ce qui me passe par la tête et le fera, très certainement pas aussi rapidement que Julia pour le CSV mais peut-être plus rapidement pour tout le reste.

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é.

En effet, face à la pertinence de tels arguments...

il offre un code plus clair et sécurisé car typé

Pourquoi plus clair ? Parce que typé ? Je ne vois pas trop le rapport (millefeuille argumentatif). Ou alors typé c'est juste pour justifier le sécurisé. Toutefois Python aussi il est typé

Je me suis personnellement convertis a Julia pour le plus grand plaisir de mon PC

On dirait une pub de télé-shopping !!!

Un autre utilisateur rapporte une accélération d'un facteur 334 en passant de Python à Julia : https://twitter.com/RobBlackwell/sta...40653222166534

Tout dépend sur quoi il a travaillé et surtout comment il a fait ses benchmarks parce qu'il ne dit pas grand chose à ce sujet, et surtout ne donne pas ses codes. A ce niveau, moi aussi je peux en donner sur n'importe quoi des facteurs d'accélération...

Si tu as des liens ou des exemples de code où Python est plus rapide que C++, je serais curieux de les regarder.

A tout hasard... print("Hello World !!!")...