barmic 🦦 a écrit 5782 commentaires

Haiku dispose d’une implémentation d’un client HTTP, mais celle-ci est complexe à utiliser et peu performante.

Je ne comprends pas bien. Les OS exposent une API de socket plutôt qu'un protocole applicatif (il y a des fonctionnalité de plus haut niveau proposé comme la résolution de nom, mais c'est plus qu'un protocole). Là il est question d'API du noyau, d'une bibliothèque inclue de base, d'un utilitaire type curl ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je croyais que tu soutenais que c'était impossible de comparer des langages informatiques au niveau efficacité. Je sais que c'est complexe, mais pas impossible.

Désolé je n'ai pas était très clair et même certains raccourcis font penser ça. Non c'est "juste" que le bench devrait être là pour appuyer une hypothèse ou être expliqué par une hypothèse.

C'est véritablement compliqué de faire un bench et l'auteur de celui-ci a fait un travail (tester plusieurs compilateurs, donner une description de la machine sur le quel il a fait son test, donner les sources du test,…) mais ce n'est pas plus que de l'amusement perso (ce qui est très bien !).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je ne sais pas ce qu'il en est d'Apple, mais je trouve Google pas mal. Ils "auditent" ton téléphone pour te dire s'il n'a pas de verrouillage par exemple.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Donc à partir d'un point précis, tu pense que l'on peut faire une déduction sur des langages ? S'il n'y a pas d'hypothèses posée avant, alors ton hypothèse c'est le test. En quoi ce test là plutôt qu'un autre ? Quels sont ses propriétés ? Pourquoi choisir ses paramètres (surtout quand on ne les fais pas varier) ?

Donc on prend 2 bout de code, dont rien indique l'effort qui a était fait pour qu'ils soient pertinents. On les a lancé et on a ni hypothèses initiales qui cherchée à être vérifiée, ni conclusion qui tentent d'expliquer les résultats.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

il est contre les 'reproducible builds' car ça se contourne

Je suis pas vraiment d'accord avec :

Q. A reproducible build is a good quality build. Whether there are security benefits or not, I just want people to do it.

Whether reproducible builds are better quality or not is a matter of opinion, and we shouldn’t be trying to force our opinions on others by claiming it’s for security.

Un code déterministe est une qualité objective. On peut choisir que ce n'est pas la qualité la plus importante pour nous, mais c'est une qualité objective.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

ne surtout pas devoir recompiler chaque programme

Pourquoi ? Parce que la machine de build est sous l'eau ? Ça je peux le comprendre mais par principe, sur changement d'une dépendance faire du rebuild n'est pas une mauvaise chose au contraire. Ils n'ont d'ailleurs pas le choix avec les programme go.

Je comprends mieux la volonté de partager et c'est un choix, tu as le même avec toute dépendance quelque soit la techno¹, est-ce que tu préfère optimiser pour chaque cas ou utiliser une solution réutilisable mais moins optimale.

Mais en soit rebuilder les logiciels c'est tout de même pour ça qu'ils utilisent du logiciel libre et tu as des distributions qui font ce choix. On pense bien sûr à gentoo, mais elle n'est pas seule. Et tu peux très bien demander à ta gentoo de compiler en statique il me semble.

C'est une décision qui a des impacts on est d'accord, mais une décision et pas une obligation.²

Mais au final le jdk est probablement plus à comparer aux runtimes de flatpak, c'est quelque chose qui arrive batteries inclues (qu'il ne faut pas comparer avec juste la libstdc++ ou gtk) et sa taille n'est plus si grande.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Oui à savoir aussi pour ceux qui cherchent la perf que graalvm n'est pas forcément plus performant. Il démarre plus et à une empreinte mémoire plus faible, mais sur des charges qui créent/détruisent un certain nombre d'objets, le fait que le gc va se débrouiller pour compacter la mémoire peut devenir vraiment utile.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

graalvm c'est vraiment particulier. C'est presque un fork de java qui ne peux compiler qu'un sous-ensemble du langage.

Par contre en standard, depuis java9 tu as la modularisation du jdk avec jlink tu peux créer un jdk sans les parties qui ne t'intéressent pas et c'est une étape que tu ne fais qu'une fois et si d'aventure tu change les module du jdk dont tu as besoin, mais ça ne devrait pas arriver tous les 4 matins.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C'est l’intérêt du benchmark game que chaque fan boy puisse développer pour son propre langage préféré.

Il faut que le bench soit vraiment établi pour ça mais bon…

Tu confirmes donc bien que si 2 personnes du même niveau d'expertise […]

Non à l'état de l'art. Sinon tu risque de juste comparer la simplicité des langages.

[…] avec un minimum de complexité, on peut comparer la vitesse du langage

Non, tu compare 2 implémentations données, sur une machine donnée, à un moment donné sur un test donné.

Et attention ! Tu gagne 3.7s, on ne sait pas comment évolue cette valeur par rapport aux paramètres du test.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Quand tu es CPU bound, tu as une part de ta performance qui vient de ton algo (ne pas refaire des calcul n fois comme le décrit freem) et une autre part qui va être très pointue les différentes formes de parallélisation, la manipulation des registres, l'utilisation des extensions que te proposent ou non ton CPU,…

Peut-on imaginer un algo numérique de l'ensemble des algo numériques qui soit 3x plus rapide dans un langage A par rapport à B, mais qui serait 2x plus lent pour tous les autres en moyenne ?

Tu établi comment que tes algos sont au niveau à l'état de l'art ? Que cette implémentation du ray tracing ne tire pas particulièrement parti d'une opti qui est plus anodine généralement ? Même sans pointer une malfaçon, on tombe facilement dans les biais. Rien que l'expertise que tu as ou pas sur un langage et son écosystème peut avoir des conséquences (ne pas utiliser la bonne implémentation de ta structure de données par exemple).

En plus là il n'est pas question de tel rapport de différence. Deux versions de compilateurs donnent plus de différence que ce qu'il y a entre nim et c++.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ne pas dépendre d'un énorme et gigantesque runtime et même d'un petit en fait. Bonnet d'âne: Java. Bon élève: ???

Je me suis toujours dis que le JDK était gros puis, un jour, j'ai installé beam et son écosystème :)

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Si l'algorithme est le même entre 2 logiciels, on peut conclure que pour ce logiciel, le code est plus ou moins compact, rapide, expressif, etc…

Ça c'est pas du bench :) La seconde partie de l'article est intéressante de ce point de vu à ce titre.

Et pour la vitesse ça te dis que cette implémentation de l'algo dans tel langage est plus rapide que l'implémentation de l'autre. Si tu as besoin de cette implémentation de l'algo, ça doit être utile ^^

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Hé hé tu vois je ne l'avais même pas vu… Comme quoi

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ça reste tout à fait minimaliste comme filtrage. En tout cas bien loin de ce qui est proposé plus haut.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ah non ce n'est pas une question de complexité, mais d'information qu'il apporte. Si tu ne peux pas conclure mieux que « ce snippet de code est plus performant actuellement que celui-ci » alors l'effort ne t'apporte rien. Le plus difficile dans un benchmark ce n'est pas d'écrire du code, c'est de faire quelque chose de tes résultats, de pouvoir comprendre la différence et d'où elle vient.

Pour voir quelque chose de bien fait c'est simple, on peut regarder les journaux sur pythran où c'est l'inverse ou tu peut regarder les bench du noyau où les dev prennent le noyau avec et sans leur feature et montrent l'impact du code qu'ils ont produit. C'est à ça que ça sert un bench. Les concours de phallus c'est de l'énergie perdu pour rien.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Quel est l'intérêt ? Un benchmark devrait être là pour répondre à une hypothèse.

La démarche peut être de prendre le même algo est de l'écrire dans les 2 langages. Plus que les langages¹ tu compare les compilateurs. Mais pour que ça ai un intérêt il faut ensuite faire le travail d'analyse des résultats (quels optimisations ont jouées dans un sens comme dans l'autre ?). Sinon ça n'apporte rien et tu ne pourra pas en déduire que l'un est plus performant que l'autre. Juste que dans un contexte donné, il est arrivé que l'un soit plus rapide que l'autre.

C'est pour ça que ce genre de papier ne sont là que pour générer de la visibilité et tenter de créer une hype.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

"T extends {}" est littéralement le code TypeScript à utiliser

C'est probablement moi, j'ai tendance à vocaliser ce que je lis et c'est un mot sur le quel je butte. Je sais que c'est un mot clef du langage, mais ce n'est pas un bout de code que tu as donné ce mot clef est un verbe de ta phrase.

"example" est le nom du paramètre choisi par le développeur initial

D'acc je comprends mieux et je suis tout à fait d'accord.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Après si tu veux une correction un peu plus propre, je pense qu'il faudrait splitter la fonction en 2, l'une qui considère que T extends {} et l'autre qui ne prend pas d'example.

Je suis sincèrement pas contre les anglicismes, mais « étends » et « exemple »¹ sont pas mal dans le contexte :)

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Il arrive aussi que l'amont, sans être hostile, se montre un peu énervant de mollesse : quand en novembre 2017 j'ai vu que le paquet Scilab était abandonné par son DD, j'ai repris le flambeau ; une Debian sans Scilab aurait été un scandale! Il n'empêche que c'est un des paquets sur lequel j'ai le plus de rustines, car malgré mes remontées, l'intégration ne se fait pas… du coup j'ai souvent des coups de déprime à son sujet et je me demande parfois si je ne devrais pas passer la main.

Tu as regardé s'il était inclut dans d'autres distributions et comment est-ce que ça se passe pour eux ? Peut être qu'ils maintiennent eux aussi des patchs ou qu'ils seraient intéressés par les tiens ? J'ai toujours en tête Go-oo qui a était un précurseur à LibO.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je crois pas que ça soit acceptable pour un paquet officiel Debian…

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

On pourrait lui donner une constitution, une hiérarchie de mainteneurs avec un « chef » à leur tête, élu au suffrage universel parmi les développeurs. On pourrait même appeler ça Debian.

Pas vraiment. L'objectif n'a rien à voir. Debian ne filtre pas ses paquets. Si c'est libre et que le paquet est fait correctement, il n'y a pas de raison que les FTP masters ne l'intègrent pas.

Là il est question de garantir certaines propriétés. C'est exactement ce que font apache et eclipse lors de l'incubation. Ils vérifient le fonctionnement des projets (gouvernance, licence, nombre de contributions,…).

Je trouve dommage que ce ne soit pas vers ça que se tourne GNU puisque c'est exactement ce qui est important pour eux et ils pourraient fournir toute une infra FSF (hébergement, support légal,…). Actuellement il y a un répertoire de projets, mais je ne sais pas trop personnellement ce que ça signifie d'être là dedans. C'est dommage pour des gens qui veulent mettre en en avant une certaine idée de ce qu'est un projet libre.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je n'ai pas dis que c'était bien. Je dis que la démarche initiale est mauvaise quelque soit le code que tu met en face. Il n'y a pas besoin d'aller voir le code ni de connaître l'un ou l'autre des langages pour comprendre le manque d'honnêteté.

Un bench sans explication précise de la différence → démarche malhonnête. Il y a bien trop d'articles de ce genre pour s'appesantir. Déjà que ce niveau de gain de performance est ridicule pour la majorité des usage.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ne te fatigue pas. Les bench entre langages n'ont aucun intérêt sauf dans un cas : quand on explique ce que l'on bench. Si le bench était là pour vérifier l'impact d'une ou d'une série d'optimisation de nim, précises et décrites. Alors ça aurait un intérêt. Dans presque tous les autres cas ça n'a pas le moindre intérêt. Là il ne s'agit que de faire un peu de pub à Nim.

En soit pourquoi pas, mais c'est fait sans vraiment de rigueur.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tu commence par un appel à la réputation, tenter d'expliquer ensuite ce qu'est une bonne ou une mauvaise généralisation c'est drôle.

De mon expérience, il est vraiment difficile de généraliser sur les grandes entreprises. Tu as des services où les choses se passent très bien et d'autres ou pas du tout. Je bosse actuellement dans un endroit où cela se passe très bien pour mon équipe alors que le son de cloche est très différent pour l'ensemble du reste. Pour préciser ça se passe bien dans une équipe de 3~4 personnes sur un étage de 30.

Je connais un autre employé amazon (prime à Londres) et ça se passe très bien pour lui.

Ton lien est intéressant pour dire que ça ne se passe pas toujours comme pBpG le vit.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je n'aurais pas lu une partie sur MacOS quoiqu'il arrive et même si elle concernait quelque chose qui m'intéressait je n'aurait probablement pas eu l'idée sans quelqu'un qui mette véritablement le doigt dessus. Comme pleins d'autres choses ça serait bien, mais ça arrivera toujours. Même les documents qui ont des réflecteurs a temps pleins peuvent avoir des fautes. Il faut pas se braquer pour ça.

C'est un choix éditorial de mettre en avant une fonction buguée sur la quelle Mozilla ne communique pas encore. Je ne l'aurait pas remis en cause (c'est à celui qui a initié la dépêche de choisir la direction qu'elle prends). Même si ça ne me paraît pas être une super idée.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll