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 :

Julia serait capable de lire les fichiers CSV dix à vingt fois plus vite que Python et R


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 249
    Points
    66 249
    Par défaut 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.

    Nom : z1.png
Affichages : 271853
Taille : 36,4 Ko

    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


    Avatar de dourouc05
    Homme Profil pro
    Ingénieur de recherche
    Inscrit en
    Août 2008
    Messages
    26 609
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur de recherche
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2008
    Messages : 26 609
    Points : 188 582
    Points
    188 582
    Par défaut
    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 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 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 éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 460
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 460
    Points : 6 064
    Points
    6 064
    Par défaut
    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, :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.

  5. #5
    Membre confirmé Avatar de Andarus
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2008
    Messages
    137
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2008
    Messages : 137
    Points : 455
    Points
    455
    Par défaut
    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 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
    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
    Invité
    Invité(e)
    Par défaut
    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


    Avatar de dourouc05
    Homme Profil pro
    Ingénieur de recherche
    Inscrit en
    Août 2008
    Messages
    26 609
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur de recherche
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2008
    Messages : 26 609
    Points : 188 582
    Points
    188 582
    Par défaut
    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
    Homme Profil pro
    Étudiant
    Inscrit en
    Mars 2015
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Mars 2015
    Messages : 4
    Points : 8
    Points
    8
    Par défaut Et Java
    Que donnerait un benchmarking avec Java?

  10. #10
    Membre du Club
    Profil pro
    Inscrit en
    Avril 2010
    Messages
    28
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2010
    Messages : 28
    Points : 52
    Points
    52
    Par défaut 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
    Invité
    Invité(e)
    Par défaut
    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.

  12. #12
    Expert éminent sénior
    Avatar de Sve@r
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Février 2006
    Messages
    12 631
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Février 2006
    Messages : 12 631
    Points : 30 865
    Points
    30 865
    Billets dans le blog
    1
    Par défaut
    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.

    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é.
    En effet, face à la pertinence de tels arguments...

    Citation Envoyé par abriotde Voir le message
    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é

    Citation Envoyé par abriotde Voir le message
    Je me suis personnellement convertis a Julia pour le plus grand plaisir de mon PC
    On dirait une pub de télé-shopping !!!

    Citation Envoyé par dourouc05 Voir le message
    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...

    Citation Envoyé par SimonDecoline Voir le message
    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 !!!")...
    Mon Tutoriel sur la programmation «Python»
    Mon Tutoriel sur la programmation «Shell»
    Sinon il y en a pleins d'autres. N'oubliez pas non plus les différentes faq disponibles sur ce site
    Et on poste ses codes entre balises [code] et [/code]

Discussions similaires

  1. Réponses: 0
    Dernier message: 20/02/2018, 09h21
  2. Réponses: 3
    Dernier message: 11/01/2015, 21h00
  3. Réponses: 2
    Dernier message: 13/09/2014, 23h28
  4. Sur mobile, les Data URI sont 6 fois plus lentes que les requêtes HTTP
    Par rodolphebrd dans le forum Général Conception Web
    Réponses: 0
    Dernier message: 30/07/2013, 11h32
  5. Lire un fichier CSV dont les données contiennent des points
    Par black cat747 dans le forum MATLAB
    Réponses: 16
    Dernier message: 23/02/2011, 12h51

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