Enj0lras a écrit 250 commentaires

Je sais bien, je parlais d'un hcangement radical…

Dans ce que je trouve bizarre, il y a aussi CLOCK_MONOTONIC qui n'est pas monotone. Ou ctime qui est changé à chaque fois que tu écris dans le fichier (POSIX n'est pas ultra clair sur ce point mais bon).

… histoire qu'on parle enfin d'autre chose.

ça fait sens si ta fonction de comparaison est linéairement plus couteuse que parcourir a liste. Par exemple, une liste de chaine très longues. Mais bon à ce niveau autant utiliser un arbre.

Je ne vois pas ou tu tu veux en venir.Evidemment que des tableaux auront un meilleur comportement vis à vis du cache, et que niveau perf, c'est bien, mais je ne vois pas en quoi ça contredit le fait d'avoir une api générique du moment qu'elle n'a pas de cout pour quand tu veux utiiser un tableau. C'est assez pratique pour les gens qui utilisent d'autres structures de données que d'avoir la même api pour tout, ça rend les choses plus simples à mémoriser.

Tu as l'air de penser qu'il n'existe que 2 types de structure de donnée. Quid des arbre ? Des priority queue ou des ring_buffer ?

Absolument. Mais pas des iterateurs. rechercher un élement = pas un truc sur lequel tu fais une boucle.

On utilise la méthode

fn binary_search_by(self, f : F) -> Result<usize, usize> where F: FnMut(&<Self as SliceExt>::Item)
de la bibliothèque standard sur un tableau.

Le seul moyen pour avoir un bound-checking raisonnable est que les tableaux fassent partie du langage comme en Fortran, C# ou Rust.

Les tableaux ne font pas (plus) vraiment partie du langage en rust, ils sont implémentés dans la stdlib.

L'implémentation des vecteurs est purement dans la stdlib : http://doc.rust-lang.org/src/collections/vec.rs.html#139-143

Les tableaux sont batards, le type est un type du langage, mais quasiment toutes les fonctionnalités sont dans la stdlib :

• les opérations d'indexation sans bound check en --release : http://doc.rust-lang.org/src/core/slice.rs.html#495
• les opérations d'indexation avec bound check en --release : http://doc.rust-lang.org/src/core/slice.rs.html#204
• un itérateur sur un tableau : http://doc.rust-lang.org/src/core/slice.rs.html#739-743

Non, j'ai pas répondu, parce qu'il a raison, en quelque sorte, cast + une comparaison suffit à garrantir le fait qu'une zone mémoire qui n'est pas initialisée n'est pas lue, ça ouvre seulement la porte à plus de bugs logique (genre, si tu passes -1, ça va faire de la merde, mais pas plus que si tu passes 2³⁰ au fond.)

Je sais pas si ça a avoir avec cette discussion, mais :

https://github.com/cgaebel/soa

Je ne dis pas que ce genre d'optimisation n'est pas important, juste qu'en arriver à dire qu'il faut pour les appliquer itérer sur des collections avec des entiers est une mauvaise idée. Utiliser des entiers non signés pour itérer sur une collection est une très mauvaise idée. D'un autre côté, utiliser un entier signé pour indexer un tableau est aussi une mauvaise idée, puisque du coup le bound check devient plus couteux : il faut vérifier les deux bounds !

Pour ce qui est d'un usage performant des itérateurs dans ce cas, en y réfléchissant, je ne vois aucun moyen simple pour éviter N comparaisons (au lieu d'une avec une boucle) pour vérifier qu'aucun itérateur n'est arrivé au bout du vecteur. En effet il faudrait des types dépendants pour exprimer que les vecteurs ont tous la même longueur. La seule solution que je vois à ce problème serait d'écrire une nouvelle structure de donnée, VecN ou pusher un élément le pusherait dans tout les sous vecteurs. Dans tout les cas, cela soulève des questions intéressantes sur un usage optimisé des itérateurs, mais je maintiens qu'utiliser des entiers pour itérer une collection est une mauvaise idée.

PS : je voudrais ajouter qu'en outre, utiliser un entier est (peut être, je ne suis pas assez expert pour savoir ce que llvm est capable ou n'est pas capable d'optimiser dans ce cas) moins performant, pour une raison simple. Rust ajoute du bound check au runtime, pour vérifier que l'opérateur d'indexation array[i] n'indexe pas une zone mémoire non initialisée. Si llvm n'est pas suffisament intelligent, il est probable que ton code d'exemple utilise deux branches : une lors de la boucle (ou de l'iterateur) pour vérifier que l'appel à .next() n'a pas dépassé la fin du tableau. Et une nouvelle quand tu vas appeler l'indexation [] pour vérifier à nouveau ce prédicat. Encore une fois, llvm est peut être en mesure d'optimiser ça mais je n'y mettrais pas ma main à couper. Les optimisations valides en C++ ne le sont pas forcément en rust.

Par contre l'itérateur Zip est peut être un peu moins peformant parce qu'il n'est pas au courant que les deux vecteurs ont exactement la même taille. Cela dit, il est probablement possible d'exprimer cela avec un peu d'imagination.

Pour ce qui est de messages condescendants, je trouve que tu es assez expert. Tu parles d'optimisation qui devrait avoir un impact sur l'API, je trouve que c'est une assez mauvaise idée. Ce que j'essaye de dire, c'est que le problème que tu soulèves est inapplicable à rust, parce que 'l'index' du tableau n'est pas censé (et ne devrait jamais) être utilisé pour itérer sur le tableau lui même.

Je ne vois pas en quoi ton exemple (qui est d'ailleurs relativement courant) implique l'impossibilité d'utiliser un iterateur. Un iterateur est implémenté (et optimisé) exactement comme ta boucle en utilisant un pointeur au lieu d'un entier, le compilateur étant capable d'optimiser correctement l'arithémtique sur les pointeurs.

Rust fournit l'itérateur Zip pour gérer exactement ce cas : http://doc.rust-lang.org/std/iter/struct.Zip.html . Je ne vois vraiment pas, cache ou pas cache, en quoi un itérateur serait moins performant qu'une boucle avec un entier.

Je crois que le vrai problème dans ton histoire c'est que tu confonds indexer et iterer. Quand tu en arrives à utiliser un iterateur manuel pour itérer un tableau il y a un soucis.

La grande difficulté vient du système de propriété/emprunt et de la délégation récursive de la mutabilité. Comprendre les règles qu'appplique le système de type est assez hardu au premier abord, d'autant plus qu'il n'y a quasiment aucune documentation qui les explique formellement.

Quand tu codes, il t'arrive souvent de t'ennerver parce que tu as l'impression que le code devrait être valide alors que le compilateur ne l'accepte pas (il a souvent raison parce qu'il applique des règles plus généraes et même si ton code est correct dans ce cas particulier, le compilateur n'est pas à même de le comprendre). Il est aussi souvent assez rageant aussi d'être limité par le fait que la propriété fonctionne par environnement lexical, ce qui t'amène souvent à devoir ré-écrire ton code pour qu'il soit accepté d'une manière que tu trouves moins lisible. (par exemple, sortir le code d'un bloc et le mettre "plus haut" dans l'abre des environnement lexicaux)

Cela dit, quand tu commences à maitriser les règles du typeur, tu peux écrire du code qui type correctement et qui reste élégant. La difficulté est d'en arriver à ce point de maitrise du langage. Maintenant si tu veux des exemples de code il va falloir que j'y réfléchisse un peu :).

u64 n'est pas l'entier de taille naturel utilisé par la plupart des langages en 64bits. Par exemple un int est 32 bits en C sur 64bits. C'est bien l'idée. uint n'a pas pour vocation à être un entier quelconque et par défaut. u32 est par défaut. Il faut voir u32 comme int et u64 comme long, et uint comme size_t. Usize a vocation à representer n'importe quelle intervalle addressable par la plateforme courante. Son utilité est donc par exemple pour indexer un tableau, ou donner la taille d'une collection en mémoire en garrantissant qu'il n'y aura pas d'overflow. Il est donc naturel de l'appeler "taille". Exactement comme size_t.

Je ne sais pas quel est le point de vue des autres rustacean, mais je trouve personnellement que rust est le langage qui m'a donné/me donne le plus de mal à apprendre.

Beaucoup plus compliqué que des langages fonctionnels comme ocaml ou que C, et même plus compliqué à comprendre que des langages à types dépendants. Cela dit, je pense que ça en vaut quand même la peine.

Il y a des initiatives en ce sens. Par exemple, les paquets haskell sous freebsd sont automatiquement générés depuis l'équivalent de pip pour haskell :

https://github.com/freebsd-haskell/hsporter

Absolument. Les jails ne sont pas des namespaces. Seule la pile réseau peut être virtualisée.

les jails sont des cgroups.

Le problème c'est que « remarque sensée » c'est profondément sujectif.
Je connais des développeurs si tu leur parles de format binaire pour conserver des logs, ils vont te regarder comme si tu avais proposé de fixer un réacteur à un panier de légumes rempli de carottes et monté sur roulettes que tu placerait devant un âne attelé à ton vélo, pour le faire avancer.

je parle de l'init bsd, tel qu'il était présent aussi sous archlinux. En effet, c'est du shell, mais du shell sous forme clé/valeur. Et si tu génères ça avec des trucs comme ansible, tu as pas besoin de te préoccuper de la syntaxe du shell du moment que c'est bien quoté. Après, c'est moins spécifié que les units systemd, et les variables dépendent souvent du service (par exemple pgsql_user, pgsql_datadir, etc) mais tu peux en général configurer pas mal de chose sans toucher au rc script.

Je suis très loin de penser que systemd devrait être portable mais je ne suis pas d'accord avec ta remarque qui dit que c'est impossible. Ces fonctionnalités ont des équivalents sous d'autres OS, et il serait parfaitement possible d'écrire du code portable avec des implémentations spécifiques pour chaque API. C'est une volonté "politique", pas une volonté technique.

Encore une fois, je ne dis pas que le fait que systemd soit linux only soit un problème, personnellement j'utiliser BSD sur mon laptop et j'en ai strictement rien à faire que systemd ne compile pas sur mon OS. Par contre se cacher derrière des raisons techniques c'est un peu de la mauvaise foi à mon avis.

C'est quand même le taff de /etc/conf.d et/ou de rc.conf ça non ?

je pense que c'est très fortement négligeable. Un processus aussi léger que ça, ça serait 500ko de ram. Dont une bonne partie qui sera partagée entre toutes les instances s'ils sont lancés habilement ou si le système mémoire est habile. C'est à dire, 200ko de ram, à tout casser. Donc 10000 services, ça fait 2Go de ram. C'est à dire une goutte d'eau sur une machine ou tu es en mesure de lancer 10000 services, qui en aura probablement au moins 500Go. Même si tes services consomment en moyenne 10Mo de ram, ce qui est pas beaucoup, tu n'as que 2% d'overhead.

Quant à la table des processus, c'est vraiment le dernier des soucis. Le code a été optimisé pour gérer des grande quantités de processus, c'est capacable de scaler très loin et tu auras d'autres problèmes bien avant ça.