Ça vous arrive de douter de "l'efficacité" d'un langage de programmation... ?

Bonjour à tous,

Il y a depuis quelques jours un certain doute que je ne parviens pas à dissiper ; et d'ailleurs, quand j'y pense, je me rappelle plusieurs moments où j'ai eu ce même doute, que j'ai en fin de compte depuis des années et qui continue de revenir par intermittence…

Est-ce qu'il vous arrive de douter de l'efficacité d'un langage de programmation ? Le mot est probablement mal choisi, mais sachons que j'entends par efficacité : rapidité d'exécution, fiabilité d'un résultat retourné, capacité d'une fonction à supporter plusieurs appels consécutifs… Et ce même sans avoir à aborder des problématiques qui requiert de gros calculs ou quoi que ce soit : on reste dans des choses très simples. (Bien sûr, on ne parle pas des erreurs humaines ou ce genre de choses.)

Car voilà. Je travaille en ce moment sur une application en Node.js, un simple tchat, histoire de découvrir un peu plus le truc. Côté client, le JavaScript gère l'affichage (création de l'onglet, de la fenêtre et de l'affichage du message), tout simplement. Mais je me dis, Si le type reçoit dix messages en même temps, et de façon régulière, JavaScript arrive vraiment à gérer tout ça : réceptionner le message, voir que tout est prêt pour l'affichage, dans le cas contraire créer les éléments, l'afficher, passer au suivant… Bien sûr, dans la pratique, je vois bien qu'il se débrouille tout à fait bien, mais j'ai toujours un doute…

Je code depuis environ dix ans et, je ne sais pas si c'est parce que je ne parviens toujours pas à comprendre à quel point l'exécution d'un code peut être rapide - instantanée -, et donc c'est une certaine forme de fascination qui indirectement ne me permet pas d'imaginer, ou bien si au contraire ce doute relève d'un manque d'expérience de ma part, d'un certain manque de maturité en matière de programmation…

Enfin voilà, dîtes moi si ça vous arrive vous aussi de douter alors que le travail à effectuer par un code donné est tout à fait banal.

Je code depuis environ dix ans et, je ne sais pas si c'est parce que je ne parviens toujours pas à comprendre à quel point l'exécution d'un code peut être rapide - instantanée -

Peut-être ! Moi avant de faire effectuer certains calculs par ma machine je ne me doutais pas qu'elle était si rapide.

Je me rappelle avoir été bluffé quand j'avais fait le premier exo du projet Euler : je m'attendais à ce que ce soit beaucoup plus long. Et aujourd'hui encore sur certains programmes il m'arrive d'être surpris.

Bien sûr, dans la pratique, je vois bien qu'il se débrouille tout à fait bien, mais j'ai toujours un doute…

Pour ma part, je demande à ma machine la chose suivante en ce moment : j'ai 10 000 objets, qui interagissent en moyenne avec trois à six autres. Une interaction consiste à un calcul de distance entre deux sphères, et si elles sont en contact, à plusieurs calculs de type racine carrée et multiplication. Ensuite, on fait la mise à jour du système suite aux interaction.

Ça, ça représente un pas (les 3 à 6 interactions pour chacune des 10 000 particules). Ma machine réalise le calcul de 1 000 pas par seconde. Et c'est une machine de bureau standard (certes, récente). Alors 10 messages en même temps, c'est de la rigolade.

Je suis plutôt estomaqué qu'on arrive à faire ralentir fortement une machine moderne avec des choses basiques (coucou MathJax). La puissance de calcul dont on dispose aujourd'hui est démentielle.

Et insuffisante, puisque je veux faire quelques millions de pas, ce qui prend donc au moins une heure. Et encore, je ne prends que 10 000 objets, je pourrai facilement en prendre 10 fois plus.

Salut,

Oui, très souvent et c'est d'ailleurs une des raisons qui me pousse à programmer en C. Non pas parce que je déconsidère ceux qui créent et mettent en oeuvre ces langages, mais tout simplement parce que l'idée même d'un gaspillage de ressources résultant d'une abstraction ou d'une automatisation (par exemple un système de ramasse-miette) m'est insupportable.

Bien entendu, il sera hypocrite de ma part de dire que cela n'existe pas en C, notamment lors d'utilisation de bibliothèques, mais ce coût reste inférieur à ce qui peut être vu dans d'autres langages.

Maintenant, je rejoins l'avis d'Algue-Rythme : on est parfois surpris des performances de script ou de programmes qu'on pensait condamner à voir s'exécuter pendant qu'on sirote un thé.

Je code depuis environ dix ans et, je ne sais pas si c'est parce que je ne parviens toujours pas à comprendre à quel point l'exécution d'un code peut être rapide - instantanée -, et donc c'est une certaine forme de fascination qui indirectement ne me permet pas d'imaginer, ou bien si au contraire ce doute relève d'un manque d'expérience de ma part, d'un certain manque de maturité en matière de programmation…

Enfin voilà, dîtes moi si ça vous arrive vous aussi de douter alors que le travail à effectuer par un code donné est tout à fait banal.

Oui, de la même façon il m'arrive d'avoir peur qu'un truc ne tienne pas en performances alors qu'au premier test il apparaît comme évident que ça ne sera jamais ce code le goulot d'étranglement. Cela dit, c'est une impression qui se dissipe rapidement quand on profile régulièrement son code.

PS : Et je précise que ça ne m'arrive pas qu'en Python, mais quel que soit le langage.

J'avais réalisé un algorithme en PHP de proposition automatique de recherche pour un moteur de recherche qui consistait en gros à ça : - récupération d'une table MySQL de 500 000 mots - calcul de la distance de levenshtein entre les 500 000 mots et le mot tapé - récupération des 10 distances les plus proches

Ce n'était pas du tout optimal, cependant j'ai été surpris, je pouvais faire plus d'une centaine de suggestions par secondes, avec un vps lambda !

En fait le post de Taurre me fait gamberger depuis hier soir.

Pour moi ça dépend nécessairement de ce qu'il y a à développer. Typiquement si je dois faire un micro-service quelconque, style une API qui tape dans une ou deux bases de données pour cracher du json, ça me semble de la folie de me lancer là dedans en C : c'est tellement haut niveau que le gain de performances et de contrôle est dérisoire devant la complexité à tout recoder.

Je partirais sans hésiter sur Python+asyncio+uvloop pour avoir un code fonctionnel dans la journée. Ou en Go en mettant un peu plus de temps, pour satisfaire les pythonphobes, et si jamais il y a dès le départ un gros besoin de scalabilité.

Pour préciser un peu ma pensée, je considère les scripts Python, Ruby ou Perl de la même manière que des scripts shell, awk ou sed : c'est chouette pour avoir un truc fonctionnel rapidement, les performances sont souvent au rendez-vous sauf cas particulier (comprendre : les performances sont acceptables), mais à mes yeux cela devrait être des solutions temporaires qui précèdent la réalisation d'un programme compilé.

Après, dans mon cas, le langage compilé sera le C, pour les motifs que j'ai cités précédemment. Je sais en écrivant ceci que les poils de pas mal de monde doivent se hérisser en se demandant comment je peux défendre l'utilisation d'un langage aussi ancien et austère au vu de tout ce qui existe aujourd'hui, mais c'est ainsi, je n'en ai trouvé aucun autre qui me convienne parfaitement.

mais à mes yeux cela devrait être des solutions temporaires qui précèdent la réalisation d'un programme compilé.

Quand on fait de la modélisation, des résolutions de systèmes, de l'intégration d'équa diff, avec quelques pré-traitements simples sur les données, ET que le programme n'est destiné à tourner qu'une seule fois (parce qu'on veut juste un résultat) ça me semble tout aussi idiot de faire du bas-niveau.

Après ce n'est peut-être pas les mêmes problématiques auxquelles tu es confronté. Si tu souhaites livrer un logiciel ou créer un outil que tu utilises souvent, ça peut éventuellement avoir du sens de l'écrire en C (ou en C++). Pour un usage de type "super calculatrice universelle de la mort qui tue" Python est idéal.

En effet, mais le cas que tu décris est justement une utilisation temporaire puisque cela ne sert qu'une fois. Dans une telle situation, je suis entièrement d'accord avec toi.

Pour préciser un peu ma pensée, je considère les scripts Python, Ruby ou Perl de la même manière que des scripts shell, awk ou sed : c'est chouette pour avoir un truc fonctionnel rapidement, les performances sont souvent au rendez-vous sauf cas particulier (comprendre : les performances sont acceptables), mais à mes yeux cela devrait être des solutions temporaires qui précèdent la réalisation d'un programme compilé.

Si on suppose que les softs ont une durée de vie illimitée et sont tous développés dans un cycle "Waterfall" (ou en V), oui. Mais (dieu merci ?) c'est aujourd'hui de moins en moins le cas.

Edit : ce que je sous-entends par là c'est que cela fait maintenant un bon moment que les projets de développements sont menés de façon itérative, et que l'approche (micro-)services a pris le dessus. Dans ces conditions, la durée de vie d'un morceau code est indéterminée : un service va souvent être codé d'une façon à une itération donnée (pour livrer le plus de valeur ajoutée possible le plus tôt possible) quitte à être récrit presque entièrement quelques semaines ou mois plus tard lorsque l'équipe aura pris note des limites de son approche dans la réalité, et il y a encore des chances que ça bouge après ça.

Dans ces conditions, pour être efficace, tu ne peux plus raisonner en te disant "je code un prototype puis je le mets au propre définitivement en prod". Chaque mise en production est le prototype potentiel d'une suivante, parce que l'accent est mis sur les fonctionnalités du code. C'est là que le choix de technos malléables et haut niveau est légitime : quitte à casser ton code pour le refaire plus tard, autant que cela ne coûte pas cher.

Bien sûr, de temps en temps on constate aussi que certaines parties du code n'ont plus bougé (ou juste pour du bugfix) depuis une période très longue, et à ce moment là commence à se poser la question de figer ce code dans un langage comme C ou C++, mais cette tâche a un coût (loin d'être négligeable), alors qu'elle n'apporte aucune nouvelle fonctionnalité, donc pour l'entreprendre il faut justifier sa valeur ajoutée. Classiquement (c'est pas le seul cas mais celui que j'ai le plus souvent rencontré), cette valeur ajoutée peut être "si je fige ce module bas niveau qui est appelé des millions de fois par seconde, j'atteindrai très facilement mon objectif de performances". Mais ce fameux objectif de performances il faut encore qu'il existe dans le projet avec une priorité suffisante, ce qui peut parfaitement ne jamais être le cas : le projet peut être tué avant, tout simplement parce que ton équipe ou ta société definit une nouvelle mission ou un nouveau projet qui sera alors beaucoup plus intéressant pour elle, pour des raisons mercantiles évidentes dans l'industrie, ou pour rattraper les mutations du paysage technologique dans l'open source…

Si on tient compte de ces réalités, tout figer en C (ou C++) devient une notion idéaliste : elle est légitime, parfaitement défendable et ça peut être un idéal vers lequel on peut tendre sereinement, mais il faut être conscient que le but absolu n'est pas de l'atteindre. Le but est d'abord de faire des programmes utiles qui résolvent des problèmes pour leurs utilisateurs, et parfois de gagner de l'argent avec : tout l'art de mener un projet technique est de savoir placer judicieusement le curseur entre ces intérêts, d'autant plus lorsqu'ils sont contradictoires.

Merci d'avoir précisé ta pensée lors de l'édition, j'allais justement te le demander.

Pour te répondre, je n'avais pas vraiment dans l'idée que le logiciel produit le serait complètement sous forme de script puis sous forme de C (ou plutôt, si, mais je ne visais que le cas de scripts amateurs). Logiquement, si c'est le C qui est employé pour la réalisation du projet, il devrait être majoritairement utilisé dès le début. Maintenant, si certaines tâches s'avèrent trop longues ou trop complexes au vu des délais, certains modules pourraient être rédigés à l'aide d'un autre langage le temps de son écriture ultérieure en C, ce qui peut attendre une ou plusieurs itérations.

Le soucis que ce n'est pas du tout cet objectif qui est poursuivi actuellement. Le C n'est plus vu aujourd'hui que comme une forme d'Assembleur abstrait tout juste bon à soulager l'un ou l'autre goulot d'étranglement. Dans le fond, on utilise le C dans les autres langages comme on utilise l'Assembleur en C… c'est-à-dire comme un outil d'appoint. La différence, c'est que les pertes en ressources occasionées ne suivent pas la même échelle (loi de Wirth quand tu nous tiens)…

C'est ce que je dis, en fait : les équipes de développement ont souvent d'autres objectifs contradictoires et ne peuvent pas se permettre raisonner d'un point de vue purement technique.

Après encore une fois ça dépend énormément du projet. Et il faut aussi voir que les ressources matérielles ont tendance à être de plus en plus abstraites aujourd'hui : c'est l'ère du cloud, tu as une nouvelle machine à ta dispo en quelques minutes avec une bête requête HTTP…

Ouais, je ne suis vraiment pas né à la bonne ère.

Ça donne lieu à des problèmes très intéressants, y compris en termes de bas niveau et de perfs, hein.

Notamment on voit l'émergence de systèmes d'exploitation et de stockage distribués, donc d'architectures matérielles adaptées (en étant plus légères), dans le seul but de répondre à un axiome central : "le matériel, ça casse, mais mon logiciel n'a pas le droit de s'arrêter de fonctionner pour autant".

En termes de système et de perfs, tu as énormément de choses passionnantes qui sont réalisées autour de la containerisation, justement pour permettre de provisionner une machine le plus rapidement possible, en consommant le moins possible de calculs et d'IO (parce que les deux te sont facturés à la minute), donc en dimensionnant les machines les plus petites possibles. C'est pourquoi on en arrive à des trucs comme Docker qui explosent en popularité.

Par contre on arrive aussi dans une situation où les programmes deviennent de moins en moins gourmands en CPU et de plus en plus en termes d'IO, donc le fait de gérer soi-même ses ressources et maximiser l'efficacité des calculs n'est plus vraiment important pour eux. Par contre le fait de pouvoir les écrire facilement, de gérer la concurrence proprement, donc en exploitant au mieux le système sous-jacent, reste tout à fait d'actualité. Ce n'est donc pas la mort du bas-niveau, loin de là : c'est juste que la révolution de la gestion d'infrastructure n'en est encore qu'à ses premiers pas.

T'en fais donc pas pour le besoin d'optimisation. Il est éternel.

Nodejs fonctionne vraiment bien, il ne faut pas écouter les ragots sur le JavaScript.

Et je pense qu'être surpris par un langage c'est une très bonne chose car le contraire est possible.

Nodejs fonctionne vraiment bien, il ne faut pas écouter les ragots sur le JavaScript.

Et je pense qu'être surpris par un langage c'est une très bonne chose car le contraire est possible.

Personne ne dit le contraire. Mais il reste aussi 5 à 10 fois moins performant que d'autres technos (Go, ou encore asyncio couplé à la boucle uvloop… Boucle qui vient elle-même de NodeJS).

Ça reste une technologie parfaitement défendable, notamment parce qu'elle est malléable et maîtrisée par de nombreux ingénieurs juniors, ce qui en fait un choix tout à fait légitime pour les startups type SaaS.

Et personne ne doute entre le choix d'utilisation d'une base de données de type SQL et NoSQL en amont d'un projet ?

Avec quelle version de NodeJS pour ce genre d'estimation est-elle basée ?

Hmm, juste 2 à 10 fois en fait : https://magic.io/blog/uvloop-blazing-fast-python-networking/

Le bench date du mois de mai, et repose uniquement sur une boucle minimaliste (type echo-server), pour ne comparer que la boucle brute de serveurs asynchrones. J'en déduis naturellement que l'écart se creuse dans le cas d'applications réelles qui multiplient les requêtes par client servi. De même, Go est ici mesuré sur un seul fil d'exécution, pour rester fairplay (si on le laisse paralléliser il ne joue plus du tout dans la même cour).

Pour ce qui est de SQL vs. NoSQL, pas vraiment. Pour moi ça dépend du type de requêtes que l'on veut faire sur les données. Typiquement, NoSQL pour des requêtes sur des indexes simples et clairement identifiés, et dès que ça commence à sentir la jointure, SQL.

Pour ne pas trop dériver en discussions sur node, même si j'en parlerais volontiers, voici mon avis pour le post d'aslo :

La plupart du temps, les performances ne comptent pas. Les ordinateurs sont très rapides. Des performances moyennes suffisent. Donc des langages ou frameworks aux performances moyennes suffisent.

L'écrasante majorité du temps, quand un projet software échoue, c'est pas à cause des performances ou des technos choisies. Optimiser pour le confort du développeur est à mon sens nettement plus important qu'optimiser pour les performances dans l'écrasante majorité des cas. Les serveurs coûtent tellement moins cher que les développeurs…

Quand t'es Twitter, tu peux lancer ton truc en RoR et constater que tu tiendras pas des centaines de millions d'utilisateurs avec. Mais c'est un cas isolé. Quand t'es GitHub, RoR est good enough.

A part ça, je pense que comparer les performances des langages est souvent pas très intéressant ou très utile. Comparer dans des cas d'usages très précis en revanche a plus de sens.

Je dois traiter des millions de websockets, quelle techno ? Je dois faire des calculs sur de grosses matrices ? Je dois traiter des teras de données ? Je dois faire du networking très lourd ? Etc. Et tout ça suivant d'autres contraintes évidemment. Par exemple, traiter des websockets sur des centaines de cores répartis sur des dizaines de machines ne se fait pas avec les mêmes technologies que si on n'a qu'un seul core. La network stack d'une montre connectée ne sera pas la même que celle d'un switch.

Comparer les perfs des langages dans l'absolu, non. Ça ne sert à rien à part faire du kikimeter. Comparer la façon dont plusieurs technos se comportent dans une situation "haut niveau" précise, en revanche (c'est le cas de mon précédent post, qui affiche clairement la couleur sur le comportement de la boucle de base d'un serveur pour 2 protocoles donnés) n'est pas déconnant. Reste à interpréter les benches derrière.

J'ai combien de coeurs ? Combien de RAM ? Comment j'envisage de passer à l'échelle ? Est-il envisageable de multiprocesser ou bien les fils d'exécution ont-ils besoin de partager des données en RAM ? Si je multiprocesse, est-ce que les ressources partagées le sont sur un réseau ? Donc plusieurs instances peuvent tourner sur plusieurs serveurs différents ? Est-ce que l'une de ces technos propose des bibliothèques qui vont notoirement me faire gagner du temps ? Etc.