barmic a écrit 927 commentaires

Avec pour conséquence qu'il est largement impossible d'expliquer l'influence de tel ou tel paramètre spécifique sur les résultats du calcul.

Je crois que impossible est un bien grand mot et qu'il y a des sociétés spécialisées dans le reverse engenering de réseau de neurones. Mais ça reste balbutiant.

Oula commencer plus simple : démontrer qu'elles ont un impact sensible sur l'utilisation serait déjà pas mal 😊

ls -lh /usr/bin/grep
-rwxr-xr-x. 1 root root 156K May 27 2017 /usr/bin/grep

Ah ?

Si on ajoute les bibliothèques ?

Chez moi :

ls -1sh /lib/x86_64-linux-gnu/ld-2.23.so /lib/x86_64-linux-gnu/{libc-2.23.so,libdl-2.23.so,libpcre.so.3.13.2,libpthread-2.23.so} =grep
208K /bin/grep*
160K /lib/x86_64-linux-gnu/ld-2.23.so*
1,8M /lib/x86_64-linux-gnu/libc-2.23.so*
 16K /lib/x86_64-linux-gnu/libdl-2.23.so
448K /lib/x86_64-linux-gnu/libpcre.so.3.13.2
136K /lib/x86_64-linux-gnu/libpthread-2.23.so*

On est à peu près à 2.7Mio, soit 3 000 cartes perforées de 920o ! (mais où va le monde !)

Voilà, c'est un peu ce que je pense aussi, j'accepte aisément que certains ici apprécient sync, mais j'imagine qu'ici beaucoup bossent dans l'informatique donc sync peut leur apporter un gros plus, mais moi je n'ai pas besoin de ça, la capture d'écran, c'est pareil, oui ça peut éventuellement servir à quelques personnes, mais voilà on impose toutes ces options à tout le monde, et au final ça alourdi de plus en plus Firefox.

Je ne me sert pas de l'historique, ni des marque pages, est-ce qu'il faut que chacun aillent porter ses doléances à Mozilla pour chaque fonctions qu'il prends en charge ou pas ?

Ce qui serait super[…]

Peut être mais ce n'est pas ce que propose Mozilla et ça n'est pas forcément enviable. Ce mode d'installation en distribution fonctionne bien avec les utilisateurs avancés, mais rend compliqué l'installation pour les utilisateurs moins intéressés et rend le support plus compliqué. Même en le simplifiant tu aura toujours des sites pour s'engouffrer dans le « regarder comment avoir un firefox 0.15% plus léger ! » et qui montrera une conf qui marche pas dans tous les cas, mais qui sera reprise sans être comprise etc.

L'unique question intéressante, c'est qu'est-ce qui pose problème dans ces fonctionnalités ?

Ce n'est que de l'imagination le fait que ça prenne ou pas du poids (tant que tu ne le montre pas par autre chose que « mais c'est du bon sens »), alors que Mozilla avec Quantum fais des efforts incroyables pour améliorer la performance. Pour rappel outre la version 57, ils ont modifiés leur façon de travailler pour toujours avoir un focus sur les performances.

Le chainage o.f().g() respire la vilaine violation de la Loi de Déméter j'ai envie de dire.

Ça sent surtout les API dites fluent ou simplement les objets o immuables :)

Je ne suis pas sûr de te suivre concernant ta remarque sur le structural binding. Les concepts ça reste du polymorphisme statique. Dans le cas du dispatch multiple OO, nous sommes sur du polymorphisme dynamique.

Le besoin d'écrit dans l'article est généralement géré par du duck-typing dans les langages dynamiques ou du structural typing dans les langages statiques. Si tu pouvais exprimer « ma fonction foo prend comme paramètre une référence vers un objet sur le quel je peux appeler une méthode qui s'appelle size qui ne prend pas de paramètre et qui retourne un entier », le besoin décrit (donc hors dispatch multiple) serait tout aussi bien rempli. C'est ce que fais Go par exemple.

Ce que je comprends de Herb Sutter, c'est qu'il ne veut pas violer l'encapsulation (et il a bien raison !).

Des années plus tard, dans ses GOTW compilés dans Exceptional C++, Herb Sutter nous fait réfléchir à l’interface monolithique de std::string et à toutes ses fonctions qui auraient pu être libres plutôt que membres dans cette classe standard — std::string représente des chaînes de caractères. Sa préconisation est d’élargir au maximum l’interface des classes par l’extérieur et de garder membres uniquement les fonctions qui ont besoin d’aller taper dans les membres privés, ou qui peuvent être supplantées par redéfinition (overridding en VO).

C'est typiquement pas le cas des méthodes size() et data() (pour empty() on peut l'implémenter à partir de size() si la complexité de cette dernière est constante).

---

D'un point de vue de la syntaxe, c'est un peu plus compliqué que cela. Dire que a.f(b), b.f(a) et f(a, b) n'est qu'une convention, c'est aller un peu vite… Écrire myValue.addTo(myArray) choque tout le monde quelque soit le langage.

D'un point de vu pratique il n'est pas pratique d'avoir de l'autocomplétion sur des méthodes libres.

D'un point de vu lecture, le chainage est plus compliqué de mon point de vu :

bar(foo(a), b);

vs

a.foo().bar(b);

Ça peut permettre le multidispatch, mais j'ai rarement eu besoin de ça (mais ça c'est mon expérience), mais surtout ça se comporte comment si j'ai une classe B qui hérite de A une classe D qui hérite de D et 2 méthodes :

foo(B& b, C& c);
foo(A& a, D& d);

et que je tente :

foo(new B(), new D());

Au final tout ça c'est pour tenter de singer du structural typing ? Autant en faire réellement, non ? (d'autant que c'est ce que permettait les concepts, si je ne m'abuse).

[…]middleware type ASMQ.

AMQP tu veux dire ?

---

Perso je suis pas certains qu'il y ai besoin d'avoir un SGBDR pour faire leur job. Ils reçoivent des inscriptions et dans les minutes qui suivent envoient un mail de confirmation ou expliquant le problème. Ça monte très très bien en charge.

En disant « je ne fais pas comme toi, moi, je préfère réfléchir », ça peut être interprété comme tel.

Les compilateurs ne tirent pas trop la gueule avec tous ce genre de choses ?

Ils disent surtout que c'est pas bien parce qu'il n'y a pas de copyleft (c'est leur avis). Ensuite ils indiquent clairement que c'est compatible avec la GPLv3. Enfin les Taptempo ont plus vocation à être lu qu'exécuté, ça a du sens d'utiliser une CC.

Je ne suis pas fan des outils que réfléchissent à ma place.
Je préfère construire en fonction de mes besoins et préférences.

C'est très fallacieux. Il n'y a pas grande différence entre devoir comprendre vim + un autre outil pour trouver comment les utiliser ensemble et utiliser un outil qui fais plus de choses et devoir comprendre comment modifier ce qui te convient quand le besoin se fait sentir. C'est des approches différentes qui ont des avantages et des inconvénients et qui sont plus ou moins pertinents en fonction des situations.

Il n'y a pas besoin de faire des sous-entendu sur l'intelligence ou la capacité de réflexion de ceux qui ne font pas comme toi.

J'ai eu des conversations ici qui parlaient de techniques où quelqu'un lis le code et décrit à quelqu'un d'autre qui recode pour réécrire en changeant la licence.

1. Ma version est publiée dans un journal dont l'ensemble du contenu est publié sous licence CC by-sa. Je pense que ça inclus aussi le code.
2. Le fait de s'être inspiré et d'être un portage en lisant les sources d'une version en GPLv3, ne les forces pas à être GPLv3 ?
3. Ces bouts de codes sont probablement trop petits pour avoir une licence. Tu ne pourra probablement pas défendre ta licence devant un tribunal, celui qui violerait ta licence peut probablement expliquer que la ressemblance est fortuite.

Bref : on arrête de s'en prendre aux drosophiles ?

Qu'entends-tu par fonction cyclique ?
Si tu regarde le lien que j'ai donné d'octo, il explique probablement mieux que moi. Si ton nombre de threads est lié au nombre de requêtes que tu reçois, tu augmente la latence avec l'augmentation du nombre de requêtes.

Une façon intuitive de le représenter est de déplier le pavé et de tracer la droite qui relis le nid et la mouche.

Le compilateur implémente déja un certain nombre de choses par défaut, ça ne semble pas évident qu'un constructeur de copie soit moins trivial ou plus important que de s'assurer que l'opérateur != renvoie NOT(==).

Continuellement inventer des cas particulier au compilateur c'est ce qui rend déjà le C++ imbitable. Comme je disais plus haut quitte à ajouter une usine à gaz autant permettre à une méthode d'être dè-virtualisée en l'inlinant dans la classe fille. C'est plus générique et ce sera l'occasion d'ajouter une nouvelle syntaxe abscons au langage.

L'autre raison, c'est peut-être que s'il faut se taper la doc de boost et une dépendance supplémentaire, autant se taper l'implémentation de l'opérateur manquant.

Demander l'ajout de cette classe dans la bibliothèque standard c'est pas plus simple ?

---

Demander au compilateur d'avoir du sucre syntaxique pour des cas particuliers ne me semble pas une bonne idée (surtout quand il est possible de faire autrement).

Précisément et je me demande pourquoi chercher à demander au compilateur d'implémenter ça.

PS : boost a changer de site, il est sympa :)

dl.google.com est écrit en Go qui sert pour tous les téléchargements de Google (dont les mises à jour de Chrome)

C'est intéressant. En fait il n'ont fait presque qu'un code glue autour de groupcache et les API étant bien faites, il n'a pas besoin de faire de copies intermédiaires entre groupcache et la réponse HTTP. Ce qui joue nettement sur le débit ce qui est leur priorité. J'ai pas vu d'endroit où il parlait de la manière dont il charge les données depuis VCS.

C'est marrant, il parle d'utiliser un système de fichiers distribué, mais n'en utilise pas.

Pour ce qui est des event loop :

• il parle du fait que l'event loop était bloquée. Si tu utilise un paradigme et que tu le viole tu va avoir des problèmes. Si dans 2 ans, ils commencent à faire des recopies en usespace de données, leur débit va en pâtir
• il parle du débit limité par l'event loop, la présentation de sozu y fait écho en expliquant qu'ils ne font pas non plus de passage par le userspace grâce à splice(2)

Træfik, un autre reverser proxy

Sympa, au final ils ont une perf inférieure à nginx. J'aime bien les conclusions du bench qu'ils mettent en avant :

• utiliser le reuse dont je parle dans le journal
• revoir la gestion des threads pour diminuer le context switch (note qu'utiliser le reuse va déjà pas mal diminuer le context switch)

Mais c'est un reverse proxy qui a l'air super sympa (plus que sozu pour mon usage perso), je vais l'essayer.

Ça se passe comme en nodejs : le développeur n'a pas besoin d'annoter ça, le runtime du langage va faire en sorte que les calculs se passent dans le thread principal (pour nodejs) ou les threads principaux (pour go), et quand il y a une opération bloquant d'I/O, on passe ce contexte d'exécution sur un thread dédié aux I/O.

Il y a une stratégie de localisation pour ça ? Genre mettre toutes les goroutines "système" dans un même thread système ? Je crois qu'il y a des ordonnanceurs du noyau qui ont des euristiques pour détecter des motifs d'utilisation d'appels système. Je crois que quand j'avais lu ça c'était pour pondérer la priorité, du coup ça permettrait à un green thread qui ferait énormément d'appels systèmes de ne pas trop influencer négativement le thread système sur le quel il est).

Ou sinon, ça peut se faire avec une classe abstraite qui implémente tous les opérateurs à partir de 2 opérateurs qui restent abstraits. Ça demande pas de modifier le langage et c'est facile de comprendre le comportement ? (Zut c'est juste de l'objet ^_^).

Si vraiment il faut je suis sûr que le C++ peut nous trouver un inline de constexpr static pour recopier les méthodes d'une classe mère vers sa fille pour éviter de passer par une vtable.

Oui je me suis lourdement trompé… Désolé.

Avoir un modèle simple pour décrire la capacité de son application est appréciable – quitte à potentiellement sacrifier un peu en efficacité en acceptant de ne pas explorer certaines formes d'organisation.

C'est marrant je vois plutôt l'inverse dans ce qui décris les green threads. C'est compliqué de gérer de l'asynchrone donc on veut rester sur un modèle à thread et que l'on me cache le fait que derrière c'est asynchrone (le runtime est obligé de faire un switch synchrone/asynchrone parce que bloquer un thread système qui celui-ci embarque un paquet de green thread).

Un des gros inconvénients du modèle de Nodejs est d'avoir un seul fil d'exécution en collaboratif. Cela veut dire que si ce fil d'exécution est bloqué pendant 100ms pour calculer le hash d'un mot de passe avec une fonction moderne de hashage comme scrypt, il n'y a aucune autre requête HTTP qui va être traitée pendant ce temps et la latence va augmenter de 100ms pour toutes les requêtes de ce processus.

Effectivement c'est un traitement lourd qui doit être fait hors de l'event loop. Je ne connais pas Node, mais vertx permet ça sans problème (soit pour un appel simple et ponctuel un enrobage, soit pour un truc plus sophistiquer utiliser une forme de worker (avec le quel tu communique via un bus d'évènement qui passe par l'event loop)).

En tant que développeur, je peux créer plein de goroutines (des fils d'exécution très légers) et le runtime de Go les place dans des threads (en préemptif).

Le lien que tu m'a donné plus haut parle de stack de 2Kio (pour Go 1.5 ça a peut être évolué) soit si tu en lance un par connexion pour le C10K, si je ne me suis pas trompé dans mes comptes on est dans les 20Tio de mémoire consommée.

J'apprécie beaucoup d'avoir par défaut la version la plus efficace, alors que pour Nodejs, ça demande souvent encore un peu de boulot de passer d'un seul à plusieurs processus : écrire le petit bout de code pour cluster, faire attention aux variables globales qui ne le sont plus (cache, pools de connexions à la base de données), etc.

Il y a un gros mélange entre une implémentation (Node) et un modèle théorique (reactor), avec vertx c'est une ligne.

Et cette « boucle d'évènement » unique, elle s'appelle… ton noyau. Démultiplexer des « requêtes » selon un sélecteur donné, c'est ce que fait le noyau quand il répartit les paquets reçus du réseau selon l'adresse et le port de destination du paquet (oui, je me suis placé à un niveau « en dessous »). orcément, quand tu as oublié qu'il existait autre chose que le Web et le port 80, ça peut faire bizarre comme sensation.

Je décris justement que les systèmes d'exploitation de type unix ont déjà implémenté pour toi tout ça (c'est la première partie de mon billet). L'article de Christophe Blaess est vraiment bien sur le sujet.

Il n'y a pas que le monde tcp/udp (comme les fichiers par exemple) et ça tombe bien ce que les SE implémente permet aussi de les gérer (cf: titre de la première partie ;) ).

Moui… tu viens de décrire l’ordonnanceur du noyau, quoi, qui répartit les tâches entre différents processus représentant différentes applications qui écoutent sur des ports différents, non ?

Non pas vraiment. Il s'agit ici d'avoir une granularité assez fine pour faire un switch non pas sur les threads (ce qui est plutôt lourd), mais au sein d'un même thread.

En fait, la manie du tout-Web a amené de gros anciens SPOF sous forme dispatchers de requêtes HTTP.

Et c'est toi qui parle que de TCP ? ;) L'accès aux fichiers ou à certains périphériques entre très bien dans ce modèle (je parle d'IO tout le long pas de HTTP).

Sans parler de comment tu gères ta file quand elle est pleine, parce que le tail-drop ça fait plus de 20 ans qu'on sait que c'est mauvais.

J'ai pas retrouvé rapidement de sources, mais je sais que vertx fait très gaffe à ça. Il fait attention à s'appuyer sur le SE pour gérer la congestion TCP par exemple. Tu peux aussi, pour d'autres besoins, utiliser Rx et sa gestion de la backpressure.