Rust `std::fs` est-il plus lent que Python ? Non, c’est un problème matériel

Les bindings Python d’OpenDAL sont-ils plus lents que Python ?

• OpenDAL est une couche d’accès aux données qui permet de récupérer efficacement des données depuis divers services de stockage.
• Des signalements indiquent que les bindings Python d’OpenDAL sont plus lents que Python lui-même.
• Plusieurs hypothèses sont avancées, comme le cache interne de Python, l’accélération de la lecture de fichiers ou encore le surcoût supplémentaire de PyO3.

Le service Fs d’OpenDAL est-il plus lent que Python ?

• Le problème implique plusieurs éléments, dont Rust, OpenDAL, Python et PyO3.
• Il est constaté que le service fs d’OpenDAL, implémenté en Rust, est lui aussi plus lent que Python.

Rust std::fs est-il plus lent que Python ?

• OpenDAL implémente son service fs via std::fs.
• Il est confirmé qu’une implémentation utilisant std::fs de Rust est elle aussi plus lente que Python.

Rust std::fs est-il plus lent que Python ? Vraiment ?

• Le résultat selon lequel Rust std::fs serait plus lent que Python est remis en question.
• L’auteur apprend à analyser les appels système avec strace.
• L’analyse des résultats de strace ne permet pas d’expliquer pourquoi Python est plus rapide alors que les deux utilisent mmap.

Pourquoi utiliser mmap ici ?

• mmap ne sert pas seulement à mapper un fichier en mémoire, mais aussi à allouer de grandes zones mémoire.
• Lorsqu’on demande de la mémoire avec malloc, glibc peut utiliser mmap pour effectuer l’allocation.

Python utilise-t-il le même allocateur mémoire que Rust ?

• Python utilise un allocateur mémoire optimisé pour les petites allocations appelé pymalloc.
• pymalloc est optimisé pour les petits objets, tandis que les grosses allocations passent par PyMem_RawMalloc() et PyMem_RawRealloc().

Rust est-il plus lent que Python avec son allocateur mémoire par défaut ?

• mmap est soupçonné d’être à l’origine du problème.
• Il est découvert qu’un programme Rust devient plus rapide que Python après être passé à jemalloc.

Rust n’est-il plus lent que Python que sur mon ordinateur ?

• Le fait que Rust fonctionne plus lentement que Python ne se produit que sur une machine particulière.
• Des informations détaillées sur le CPU et la mémoire sont fournies.
• Même après avoir ajusté les mécanismes d’atténuation des vulnérabilités CPU, Transparent Hugepage et l’affinité des cœurs CPU, les résultats ne changent pas.
• À l’aide d’un programme eBPF, il est confirmé qu’au niveau des appels système aussi, Rust est plus lent que Python.

Le C est-il plus lent que Python ?

• Une version implémentée en C s’avère elle aussi plus lente que Python.

Le C est-il plus lent que Python ? Sans offset spécifié !

• Une différence dans l’offset des zones mémoire est mise en évidence, et l’ajustement de cet offset améliore les performances du programme C.
• Il est confirmé que, sur les CPU AMD Ryzen, l’absence de certains offsets entraîne une baisse de performances.

L’AMD Ryzen 9 5900X est-il lent sans offset spécifié ?

• Il est confirmé qu’il s’agit d’un problème lié au CPU, et un développeur du noyau prend part à la discussion.
• Un profilage avec perf confirme à nouveau qu’en l’absence de cet offset, les performances se dégradent.

L’avis de GN⁺ : Le point le plus important de cet article est que Rust et C peuvent, dans certains environnements matériels, fonctionner plus lentement que Python, et que cela peut être lié à l’allocation mémoire ainsi qu’à certains comportements spécifiques du CPU. Cet article montre, à travers l’exploration des nombreux facteurs qui influencent les performances logicielles, à quel point l’interaction entre matériel et logiciel peut être complexe. Cette enquête offre une leçon précieuse pour résoudre les problèmes inattendus qui peuvent survenir dans le monde de l’ingénierie logicielle.

[GN⁺]

Avis sur Hacker News

• Avis sur une prémisse déroutante

  Un utilisateur s’étonne que certains pensent que les fonctions de la bibliothèque standard de Python sont écrites en pur Python. Il trouve intéressante la différence de performances, puisque la méthode de lecture de fichiers de Python comme OpenDAL sont des wrappers Python autour de code natif, mais estime qu’il est étrange de dire que c’est « plus lent que Python ». Il s’attend à ce que les fonctions de la bibliothèque standard de Python soient implémentées en code natif et optimisées individuellement. Il n’a pas été surpris que la conclusion de l’article soit liée au fonctionnement du code natif, et même s’il a été surpris par certaines réponses, il reconnaît que c’était un article très intéressant malgré un point de départ déroutant.

• Discussion sur les indicateurs de fonctionnalités CPU

  Il existe deux indicateurs dédiés de fonctionnalités CPU qui signalent que les instructions REP STOS/MOV sont rapides et utilisables comme séquences d’instructions courtes pour memset/memcpy. Écrire à la main des routines optimisées pour chaque nouvelle génération de CPU est une souffrance qui dure depuis des décennies. L’utilisateur se demande si cela ne devrait pas désormais faire partie des suites de tests de timing des fabricants de CPU.

• Lien vers un bug glibc connexe

  Un lien vers un bug glibc lié à Zen 4 est fourni.

• Réaction positive à l’article

  Un utilisateur dit qu’il s’attendait à se moquer d’une mauvaise utilisation de std::fs, mais que l’article enchaîne les détours et les mystères ; il le juge très bien écrit et extrêmement intéressant.

• Très bonne appréciation de l’article

  Un autre utilisateur estime que c’est l’article le plus intéressant qu’il ait lu cette semaine et salue l’excellente qualité de l’écriture.

• Proposition de résolution du problème

  Comme solution évidente, il est proposé d’envoyer un patch modifiant la méthode du noyau copy_user_generic afin d’utiliser une autre implémentation de copie mémoire lorsque le CPU est détecté comme problématique et que l’alignement mémoire déclenche le bug de lenteur.

• Informations sur l’allocateur par défaut de Rust

  Des informations sont données sur le fait que l’allocateur par défaut de Rust était jemalloc jusqu’en 2018, avec un lien connexe.

• Réflexions des développeurs Rust pour améliorer les performances

  Un utilisateur se demande si les développeurs Rust devraient envisager de passer à jemallocator pour améliorer les performances, si c’est un moyen pour tout le monde d’obtenir des gains « gratuits », si des bases de code en C pourraient aussi en bénéficier, et s’il reste actuellement des performances inexploitées.

• Explication des différences CPU entre AMD et Intel

  Il est expliqué que la manière dont AMD gère le stockage de chaînes diffère d’Intel, et qu’il vaut mieux ne pas l’utiliser avant de dépasser la taille du L2 du CPU. Une fois ce seuil franchi, utiliser le stockage de chaînes devient avantageux et devrait fonctionner à « vitesse DRAM », mais comme le coût de démarrage est élevé, il faut utiliser des chargements/stockages vectoriels 256 bits jusqu’à atteindre ce seuil.

• Transmission de l’article aux bonnes personnes

  Un utilisateur indique avoir transmis cet article aux personnes concernées.