Soit vite ou mal

En 2018, j'ai pratiqué Advent of Code (vous pouvez regarder les streams de mes solutions ici ). Chaque jour en décembre, ils signalent un petit problème, et vous devez écrire un programme qui le résout. Cela prend généralement de quelques minutes à quelques heures et est assez amusant, je vous recommande de l'essayer. Lorsqu'une tâche est terminée, elle est toujours disponible, pas seulement en décembre.



J'ai réalisé qu'il existe deux types de solutions : celles qui peuvent calculer la réponse en quelques millisecondes et celles qui prendront la réponse pendant plusieurs années. Si vous obtenez la deuxième option, vous faites quelque chose de mal. Il ne sert à rien d'attendre, même si, techniquement, cela pourrait aussi être correct.



Une autre observation intéressante est que le matériel que vous utilisez pour lancer n'a pas d'importance. Si la solution est rapide, elle le sera à la fois sur l'ordinateur portable et sur le poste de travail pompé. Bien sûr, cela pourrait être deux ou trois fois plus lent, mais la différence se situera entre 10ms et 30ms. Vous obtiendrez votre réponse de toute façon, donc cela n'a pas vraiment d'importance.



En revanche, si la solution est lente, vous pouvez utiliser n'importe quelle puissance de traitement, et ce ne sera toujours pas suffisant. Cela pourrait réduire la durée d'exécution de trois ans (sur un ordinateur portable) à un an (sur l'ordinateur le plus puissant que je puisse construire). Quelle est la différence? C'est trop long de toute façon.



Passons maintenant au logiciel. Il est facile de qualifier les solutions d'Advent Of Code de mauvaises lorsqu'elles sont lentes, car nous savons qu'une solution rapide doit exister. Avec de vrais problèmes, personne ne le garantit.



Sauf dans certains cas.



Assez souvent, en fait.



En fait, je dirais presque toujours.



Voyons voir. J'ai une bibliothèque appelée Datascript . C'est une structure de données/base de données persistante et il se trouve qu'elle est implémentée pour deux plateformes : JS et JVM. De plus, il est en fait écrit en Clojure et la majeure partie de sa base de code est utilisée par les deux plates-formes. Cela signifie que nous savons que les deux versions font toujours la même chose. Il existe une petite couche qui couvre les détails spécifiques à la plate-forme tels que les types de données et la bibliothèque standard, mais le reste est générique. Ce n'est pas qu'une version est l'originale et que l'autre est un port inefficace. Ils jouent tous les deux au même jeu.



Vous pensez peut-être que s'ils se comportent de la même manière, leurs performances devraient être les mêmes, n'est-ce pas ? Il serait logique de le penser.



Jetons un coup d'œil au temps réel nécessaire pour compiler la base de code et exécuter la suite complète de tests d'intégration. On parle d'une base de code qui compte un peu plus de 9000 LOCs, dont 4000 sont des tests :



Clojure 1.10 sur JVM :

• Temps de démarrage REPL : 1,5 seconde
• Temps de compilation : 6,5 secondes
• Temps de test : 0,45 s

ClojureScript 1.10.439 avec compilation avancée :

• Temps de compilation : 78 secondes
• Durée des tests : 1 seconde

ClojureScript 1.10.439 sans compilation Google Close :

• Temps de compilation : 24 secondes
• Durée des tests : 1,3 seconde

Alors que nous disent ces chiffres ? Fondamentalement, vous pouvez prendre environ 8 secondes, 24 secondes ou 78 secondes pour traiter le même code. Le choix t'appartient. De plus, en exécutant le même programme, vous pouvez obtenir le résultat en une demi-seconde, une seconde ou presque une seconde et demie.



« Mais attendez, Tonsky, ils ne peuvent pas être comparés ! Ce sont deux grandes différences ! Ils sont conçus pour faire des choses complètement différentes ! L'un d'eux fonctionne dans un navigateur !"



Vous pouvez bien sûr obtenir des résultats. Permettez-moi de vous rappeler que nous compilons le même code, conçu pour faire la même chose, utilisant les mêmes algorithmes et fonctionnant sur le même matériel. Le résultat final est le même dans les deux cas : vous obtenez une réponse à votre requête dans le data log en peu de temps ou sur une longue période. Soit vous passez la moitié de votre journée à attendre le compilateur, soit vous la passez à jouer au REPL, à construire quelque chose.



Que font les compilateurs ClojureScript / Google Closure depuis si longtemps ? Ils vous font perdre votre temps, c'est quoi. Bien sûr, personne n'est à blâmer, mais en fin de compte, toute la décision est tout simplement erronée. Nous pouvons faire la même chose beaucoup plus rapidement, nous avons des preuves, nous avons les moyens de le faire, mais il se trouve que ce n'est pas le cas. Mais nous pourrions. Si tu voulais. Cet énorme surcoût que vous payez, vous le payez en vain. Vous n'obtenez rien d'autre de JS que de doubler le temps d'exécution et les temps de construction astronomiques.



La même chose est vraie pour toutes les langues avec des temps de construction terriblement longs. Ce n'est pas qu'ils ne pouvaient pas être plus rapides. Ils choisissent simplement de ne pas le faire. Un programme C++ ou Rust prend-il trop de temps à compiler ? Eh bien, OCaml pourrait probablement compiler un programme équivalent en moins d'une seconde. Et ce sera toujours aussi rapide au niveau de la voiture.



« Wow, wow, ralentissez ! C'est encore plus injuste ! Maintenant, ce ne sont pas seulement deux grandes différences, maintenant c'est comme les brosses à dents et les vaisseaux spatiaux. Vous ignorez complètement ce que chaque langue fournit. Il y a une raison pour laquelle ils passent autant de temps à compiler, tu sais ?"



Je connais. Mais encore, je pense que vous pouvez les comparer. Après tout, ce sont tous des langages à usage général, et en fin de compte, ce qui compte, c'est de savoir si vous avez un programme de travail sous la main et pouvez fournir une réponse dans un délai raisonnable. Peu importe comment le développeur est arrivé là. Vous pouvez vous calmer en pensant que c'est le cas, mais personne ne s'en soucie.



Imaginez : un avion vole de Moscou à Novossibirsk, le cœur de la Sibérie, qui parcourt 2 800 kilomètres en 4 heures. Il y a aussi un train qui parcourt la même distance en trois jours. Il n'y a pas de douche dans le train, de la mauvaise nourriture, des lits sur lesquels on ne peut pas dormir. Et un avion est un avion moderne et confortable. Lequel choisiriez-vous? Le même prix. La seule différence est votre confort et votre temps.







Si nous prenons cela comme une métaphore du développement logiciel, vous seriez surpris que les programmeurs prennent volontiers le train. Ils soutiennent même jusqu'à l'enrouement qu'il existe des raisons irréfutables de choisir un train. Non, cela ne les dérange pas si le compilateur prend le temps de "travailler". Il existe cependant des moyens plus rapides d'arriver à la même destination. Il est facile de se perdre lorsqu'on se dispute sur des détails, mais rappelez-vous : nous nous retrouvons tous au même endroit , quelle que soit la langue que nous parlons.



Navigateurs ? La même histoire. HTML est un moyen plutôt inefficace de positionner les pixels sur l'écran. Un ordinateur capable d'afficher des millions de polygones dans un cadre peut avoir du mal à charger une page Web. Comme pour les solutions Advent of Code, cela ne dépend pas de la puissance de votre ordinateur. Et même un code Web hautement optimisé basé sur Canvas et WebAssembly ( Figma ) fait tourner mes fans de Macbook dans un silence complet lorsque je lance mon propre Sketch.







- *tapotements sur la couverture *Ce PC est capable de faire tourner Crysis 3 en 4K à 144fps.

- Mais peut-il faire tourner Atom ?



Il y a simplement des limites à ce que peut aller cette mauvaise décision. Les éditeurs de texte sur Electron ne peuvent pas redimensionner la fenêtre en temps réel et s'affaisser dans les cadres lorsque vous déplacez simplement le curseur. Slack sur l'iMac Pro sera aussi lent et gourmand en mémoire que sur un Macbook 12 pouces.



L'ensemble de la décision, la "pile Web", est généralement erronée . La même chose pourrait être faite plus rapidement et plus efficacement - il y a tellement de potentiel gaspillé. Il est temps de l'admettre et de recommencer. Il existe des éditeurs de texte rapides et des programmes de communication qui sont facilement disponibles même pour les netbooks les plus faibles.



Je peux continuer encore et encore. Gardez à l'esprit ceci : pensez à ce que vous en retirez. Le problème et les ressources dépensées sont-ils comparables ? Il est facile de trouver des excuses pour expliquer pourquoi les choses sont comme elles sont. Ils sont probablement tous valables, mais ce sont des excuses. Nous savons que des programmes plus rapides sont possibles et que tout le reste va mal.