Firwen a écrit 562 commentaires

Je sais que c'est une caricature, mais une démarche en python est un peu différente. Elle dit que la majeure partie de ton application n'a pas besoin d'une performance importante. Donc coder la partie qui demande une grosse performance en c/c++/go/rust/julia et l'interfacer1 avec le reste de ton application en python peut être pertinent. Ça permet en plus d'avoir de coder la partie métier dans un langage de très haut niveau et la partie technique dans un langage qui permet d'accéder au très bas niveau.

Exactement. Python et C++ ne joue pas dans la même court.

• Python est fait pour faire du prototypage rapide avec du code qui finira difficilement maintenable due à son typage dynamique et ses performances.
• C++ est fait pour du code système avec des code base où la performance compte et des projets qui peuvent tourner 30 ans et toujours faire le boulot et être maintenu (déja vu).

D'ailleurs ironiquement python et ses modules sont principalement fait en C et C++ (CPython, Cython, numpy, tensorflow, SSL layer, pycurl, ….). Le restant étant un joli layer de scripts au dessus

Par exemple, pas mal de jeux utilisent le moteur Unity qui se code en C#.

Unity lui même est en C++. Le C# c'est principalement pour le scripting.

Simplement: Evite pip.

Comme stipulé plus haut, utilise Nix ou similaire (GUIX, Spack, EasyBuild).

Les packages managers langages spécifiques (pip, npm, gem, go-get ou cargo) sont des immondices dés que tu essaies d'ajouter du code natif (C,C++, fortran) à l'intérieur de ton package.

Ils favorisent par ailleurs aussi ce que j'appelle le syndrome des "îles séparées": Tout est re-développé et réinventé 20 fois pour chaque langage car utiliser dans un logiciel développé dans un langage tiers est horriblement pénible.

J'allais dire que tu es un marrant à utiliser un logiciel troué non patché, mais pour les flemmards pour info ça ne semble pas venir du logiciel lui même, le cracker (hacker? heu… pas le bon mot? En tous cas il s'amuse bien) dit "Escalation could have been avoided if developers only had the access they absolutely required and did not have root access to all of the servers." donc le tout est de ne pas filer l'accès à sa machine.

Yep, et ça donne également du crédit à l'encryption end to end.

Car ce genre de problème pourrait arriver à n'importe quel serveur de chat et avec des hackers avec un sens de l'humour nettement moins sympa.

Je ne connaissais pas Mellanox. Ils font du libre?

Mellanox est la raison principale derrière pourquoi la quasi totalité des drivers infiniband actuels sont libre et open source.

Ils sont aussi derrière l'Open Fabric Alliance qui fournit les tools et modules necessaires pour faire du RDMA.

https://www.openfabrics.org/

La quasi totalité des super computers à l'échelle mondiale et tous les gros clusters HPC ont du materiel Mellanox et sont tous sur Linux.

Sauf erreur de ma part, Nextcloud et Owncloud utilisent csync, non ?

Ils l'utilisent(-aient ? je suis plus sur que c'est d'actualité ) pour la synchronization bidirectionnel sur WebDAV. Rien à voir avec SSH.

Tu peux ajouter à la liste des projets scientifiques avec une bonne qualité de code :

• scipy
• scikit-learn: Librarie de Machine learning, excellente qualité
• CGAL: Une toolbox pour la geometrie, le meshing. Un monstre dans le domaine.
• libsvm: Support vector machine library, ça juste marche.
• BLIS : BLAS moderne et trés bien supporté venant d'une université du Texas.
• Tous les Projets qui viennent de Sandia national Lab ou l'ingénieurie est généralement trés bien fait incluant Trillinos et toutes ses libs associées
• Armadillo et MLPACK: Algébre linéaire et Machine Learning, d'une Université d'Australie
• Un bon nombre de language spécialisé incluant Lua, OCaml & Scala.
• Et beaucoup d'autres que je n'ai plus en tête.

Je n'ai pas dit que le monde académique ne produisait pas des logiciels de qualités, mais souvent que c'est exception, pas la norme. Pour des raisons de financement et d'organisations malheureusement.

Heureusement, il y a aussi maintenant de plus en plus de labos qui ont compris l'intêret économique,à garder leur pile logiciel "maintenanble" qui emploie maintenant des équipes d'ingénieures pour s'occuper de ça. Mais encore une fois, c'est souvent l'exception, pas la norme.

Mais bien sur… Tous les codes scientifiques sont pourris…

J'ai travaillé suffisamment avec des scientifiques pour avoir une opinion assez tranché sur la question:

Non, bien évidemment tous les code scientifiques ne sont pas pourris.

Mais à mon expérience ( qui n'engage que moi ) une grande parti du code issue du monde de la recherche est souvent bâclé, sans aucun respect des principes de base en ingénieure logiciel et souvent in-maintenable.

Ce n'est pas l'absolue, mais c'est souvent le cas. Et il y a des raisons à ça, des raisons humaines parfaitement compréhensibles. Les chercheurs sont payés, respectés et récompensés pour leur résultats, leurs publications et leur données.

Leurs programmes ne sont que des outils secondaires nécessaires à achever ça, rien d'autre. La pérennité, ré-usabilité, modularité, maintenabilité de leur code, ils s'en moquent… ils ne sont pas et ne seront jamais évaluer sur ça…. En tout cas pas dans 90% des labos de recherche, même dans l'informatique.

Et je peux parfaitement les comprendre, ils sont payé pour faire de la recherche, pas de ingénierie, ils font de la recherche. Faire de ingénierie correcte, ça prend du temps et de l'argent… Et ils ont souvent ni l'un, ni l'autre.

Et tant que les grand journaux de publications ne forceront pas la publication des outils sources, testés, et maintenu correctement pour des raisons de reproductibilité, ça restera comme ça.

Du calcul scientifique avec Rust? Tu as un lien que je rigole. Franchement c'est rigolo de voir certains academiques se precipiter sur la derniere nouveautes

c'est (souvent) le module du Phd student qui a fini en prod et que personne veut recoder :D

Tu peux remplacer Rust par le language X fashion du moment.

Non ça n'arrive pas tant que ça. De toute ma vie ça n'est arrivé qu'une fois en fait (je sais que tu va pouvoir citer pleins de cas, ça n'en fait pas la règle).

Ben tu as bien de la chance car ça m'arrive toute les semaines. Les gens qui font du machine learning où qui utilise intensivement python ( scientifiques ) ont une plétoire de dépendances en C, Fortran, C++, Rust et ma grand mère compilé en native derrière leur script. Et pip absoluement infame pour compiler du code natif.

C'est normal, un utilisateur ne devrait pas avoir besoin de s'en servir. Et jouer au power user moijecompilemesprog ne rend pas cette remarque fausse. Tu veux jouer avec les outils des développeurs, très bien.

Doc fait qu'en pratique tu auras besoin d'un second "package manager" / "installer" / "deployment system" X uniquement pour tes utilisateurs car celui que tu auras en CI sera différent. Ce qui au passage est potentiellement aussi une source de bug.

Pour ceux que je connais, ils n'est pas nécessaire d'avoir internet, c'est juste l'option par défaut parce qu'elle convient au plus grand nombre. Et oui dans ton environ haute sécurité, on installe pas n'importe quoi ce qui par définition montre qu'il y a peu de programmes qui sont construit pour.

Toi tu as pas encore essayer Bazel :D

Sans cloisonnement ? Soit. Mais tu paie une complexité démesurée. La complexité des systèmes n'augmente pas linéairement avec la taille (je crois avoir lu qu'elle est plutôt quadratique) donc empiler les logiciels et leurs dépendances sans cloisonnement et se dire que ça doit marcher c'est à minima assez joueur…

Et ignorer cette complexité et surtout les dépendances en Diamant c'est la garantie suprème de se foutre une balle dans le pied. De manière bien douloureuse, souvent aprés des semaines de débugging.

C'est la question des dev et des ops. Si les ops reprochent aux dev de ne pas utiliser les gestionnaires de dépendances systèmes, il faut bien comprendre que l'inverse est vrai aussi.

Je ne reprochent ni à l'un ni à l'autre: ils ont tous les deux leur raison. Le problème de la situation actuel c'est qu'il n'y a rien pour satisfaire les deux, alors que techniquement il n'y a aucun barrière à ce que ça soit le cas.

Se plaindre c'est bien marrant (quoi que), mais personne n'arrive à spécifier un truc qui soit intéressant pour les 2 types d'utilisation

Nix ? Spack ? Bazel (que je considérerai comme une failure ) ?

maven, npm, pip, cargo…

Pour plusieurs raisons :

• Parce que tous ces outils vivent sur leur petite île langage spécifique et n'ont aucune compatibilité entre eux. En pratique, tu as trés rapidement un cas où tu veux utiliser une lib Rust associé à une lib C++ dans un module python

• Tous ces outils sont orienté "devs" et généralement très peu approprié pour un utilisateur final

• Tous ces outils téléchargent le monde en considérant que: Internet est toujours disponible, Installer spécifier les dépendences à la main est inutile. Ces deux préceptes sont faux dans beaucoup environnement ( environnent haute sécurité proxifié, intrégration dans un écosystème plus grand qui a déjà des dépendances et où tu veux eviter les dépendances en Diamant )

C'est quoi un logiciel propre? En C89 avec autotools?

Pour avoir fait suffisamment de packaging, tous les packagers s'accordent sur les points suivant:

Un logiciel "propre" a packagé c'est:

• un logiciel qui n'embarque pas ses dépendances

• un logiciel qui ne dépend pas sur du code propriétaire ou à license problématique.

• un logiciel qui a un tool standard pour builder ( pas un script louche qui tombe en marche le 31 du mois sur la machine du voisin uniquement)

• un logiciel qui compile/install en environnement isolé sans télécharger internet 2 fois.

Pour prendre un contre exemple parfait, je recommence de regarder ce talk de la fosdem qui décrit parfaitement un software désigné avec le cul (veuillez pardonner l'expression) et quasi impossible a packagé

https://archive.fosdem.org/2018/schedule/event/how_to_make_package_managers_cry/

-12 Pour ça. Les traditions se perdent, les gens manquent cruellement de second degré pour un Vendredi…

J'ai testé Flatpak pour certains logiciels (comme Retroarch) et c'est étrange ça fout un merdier et ce n'est pas clair ! La sandbox est étrange, tu as accès entièrement au /home/ mais le /var/share/ est à part ?!

En un nom et parce que c'est Vendredi: Lennart Poettering.

Et oui, l'idée originel derrière Flatpak c'est Lennart. Un homme qui, comme tout le monde le sait a toujours fait des softwares simple, fiable et minimaliste comme systemd, avahi ou pulseaudio.

C'est trop gros comme troll ou ça passe quand même pour un Vendredi ?

Je suppose qu'il supporte pas de faire un « install » dans un répertoire précis, mais uniquement à la racine ?

Non je parle de RPATH & DT_RUNPATH : https://en.wikipedia.org/wiki/Rpath

RPATH t'autorise à encoder directement dans tes libraries le chemin d'accés à leur dépendance. Ce qui rend l'installation de tes logiciels dans un environment "prefixé" (cad en dehors de /usr/lib ) plus simple à utiliser.

Tu veux parler de build_rpath et install_rpath de l'objet executable (https://mesonbuild.com/Reference-manual.html#executable) ?

Exactement, Ils l'ont donc ajouté. Trés bonne nouvelle.

Le RPATH à l'installation est souvent indispensable en environment HPC si on veut eviter d'avoir des LD_LIBRARY_PATH à 300 entrées…

J'ai donné une chance à Meson sur un de mes derniers projets et je dois dire qu'il avait des avantages pour lui :

• Syntaxe claire et explicite ( Pas de variable non existante qui sont mise à "null" à la CMake, ou de bordel sans nom mixant m4 et bash à la autotools )

• Excellente intégration avec pkg-config

• Rapide

• Bonne documentation.

Ceci dit, il a échoué très rapidement et je suis revenu à CMake quand j'ai réalisé qu'il supportait pas les RPATH à l'installation….

Alors là, je ne suis pas d’accord. J’ai vu plus d’une fois des problèmes liés au NAT, soit à l’équipement soit parce qu’il y avait des incompréhensions entre équipes qui ne parlaient pas des mêmes range IP. Ça a un coût et plus les réseaux grandissent, plus les NAT s’empilent plus ces erreurs arrivent.

Je ne travaille pas directement pour les FAIs, donc tu es certainement plus informé que moi sur ça. J'espère par ailleurs que tu as raison, car la situation sur le mobile ( en Europe ) est déprimante ( et je reste gentille ).

Le fait que la plupart des logiciels de VoIP, vidéo call sur smartphone sont victime d'une instabilité permanente est par ailleurs souvent lié à ça ….

Si tu lis le mon message, je ne parle pas de problème pour l’utilisateur final mais pour ceux qui gèrent les réseaux. Ce n’est pas le NAT de la box qui pose problème mais l’empilement de CGNAT côté opérateur ou les différents NAT entre différents réseau chez celui qui fournit le service.

J'ai bien compris ton message. Mais je ne suis pas réellement convaincu par cet argument là. L'empilement des NATS est une chose qui est déja en place et dont les opérateurs sont habitués depuis des années. Ils peuvent le rester encore pour beaucoup d'autres.

Tu as des preuves sur cette mauvaise gestion de l’IPv6 ? Parce que Akamai voit 71% (en 2016) des utilisateurs Verizon Wireless en Ipv6 (L’article complet).

Je voyage pas mal. Et la quasi intégralité des pays où j'ai été et utiliser le réseau mobile, j'étais en IPv4, peu importe le provider. Verizon est l'exception, non la règle.

La liste des pays inclue la quasi intégralité de l'Europe, le Canada, Les états Unis, la Chine, le Japon, la Corée…. même situation partout.

Quand le coût du NAT deviendra tellement élevé qu'il n'en vaudra plus la peine. Et je parle aussi des coûts liés au début. Quand une adresse IP est modifiée quatre fois sur le chemin (parce qu'elle passe dans plusieurs tunnel entre plusieurs boîtes qui ont des plans d'adressage qui se chevauchent) ça complique le debug.

J'aimerai être aussi optimiste que toi.

En pratique, 90% du trafique est maintenant du trafique HTTP / WebSocket ou autre verrue ajouté sur HTTP qui n'a pas de problème avec le NAT traversal. Donc NAT ou pas, c'est pratiquement transparent pour l'utilisateur final…

Et tant que l'utilisateur final ne sera pas impacté, rien ne changera.

Encore pire, une bonne partie de ce même trafique est du trafique mobile, venant de téléphones qui ne gère pas ou mal IPv6.

pour NUMAPROF j'étais au CERN jusqu'au mois dernier.

Le monde est petit :)

Je peux te demander ton labo d'attache ?

Maîtriser les allocations (nombres et tailles) est une chose, mais les gains importants en performance résident surtout sur les accès.

Les allocations sont déjà un bon debut. Ca permet entre autres d'évaluer la fragmentation qui a aussi un impact sur les accès.

Merci pour ce petit billet sur les outils du monde HPC, c'est assez rare d'en voir donc d’autant plus appréciable.

Le profilage mémoire est malheureusement un domaine assez peu connu et très peu enseigné qui est pourtant tout aussi significatif que le profilage du temps d'execution….Les allocateurs standard ayant généralement la fâcheuse tendance à ne pas beaucoup aimer le multi-threading et encore moins les arch NUMA.

Sinon, une licence MIT, simple, efficace, et bien connue. Elle semble être une bonne façon de laisser quelqu'un d'autre (ou une plus grosse équipe) prendre le code et en faire ce qu'ils veulent. Il faudra leur faire confiance pour que leurs évolutions restent libres, par contre, car il n'y aura pas d'obligation contractuelle.

Ou AGPL, et tu n'auras pas le problème numéro.