Julien Jorge a écrit 590 commentaires

Le projet me plaît bien mais je n'ai pas encore pu générer ma galerie. Pourtant j'ai essayé !

J'ai installé la 5.3.10 via le paquet Debian. Premier souci, mineur, en éditant /etc/myphotoshare/myphotoshare.conf pour indiquer le chemin vers ma galerie. Le fichier commence avec ce commentaire :

 Do not modify this file:
 # * copy it to any location on your disk (e.g. /etc/myphotoshare) and rename it removing the trailing .defaults"
 # * then, in _your_ copy:
 # * - […]

Du coup j'ai copié le fichier comme indiqué, mais en fait il ne fallait pas. Je suppose que ce commentaire concerne le fichier de l'archive source, auquel cas il faudrait l'enlever du paquet Debian.

Deuxième souci, myphotoshare_scanner plante ligne 1058. En effet, lowercase_stopwords est un dict et ne peut donc pas être soustrait à un set. Tu vas me dire, ce genre d'erreur de typage, relevée le plus tardivement possible, en prod sur le poste du client, c'est tout l'intérêt des langages interprétés ; mais tu digresse là :)

Je corrige le script et relance la commande sur ma bibliothèque. 13 000 fichiers dont un millier de vidéos. C'est plutôt long (je le lance sur un eeepc, un double cœurs à 1,66 GHz avec 1 Go de RAM et un disque SSD). Ça plante au bout de 21 heures car une des images est tronquée. Je relance, et j'ai l'impression que le script reprend de zéro :/

Si je peux me permettre quelques suggestions d'amélioration, ce serait pratique si le script était plus résistant aux erreurs et s'il pouvait être interrompu et reprendre là où il s'est arrêté. Si en plus le site pouvait se mettre à jour au fur et à mesure du scan, ça serait top.

J'espère que le second scan sera bon car le projet a l'air vraiment super :)

Thread Reader App peut-etre ? Le premier fil et le second.

Apparemment il faut le mentionner dans une réponse pour l'utiliser :/

La détection de pattern se fait bien après avoir parsé le code C++, au niveau d'un langage intermédiaire. Chez LLVM par exemple ça se fait au niveau de l'IR, mais aussi lors du codegen, i.e. la partie qui tiens compte de l'architecture cible. Je ne suis pas sûr qu'on parle encore d'AST à ce niveau là.

La machine est celle-ci, encore plus vieille que je ne le pensais !

Donc niveau RAM on a de la DDR3L SDRAM à 1600 MHz, mais je n'ai aucune idée du débit correspondant.

Je tiens aussi à signaler que strictement parlant, la vectorisation SSE proposée ici est illégale. Le problème est que les données sont lues par blocs de 4 int (donc 16 octets). En pratique, cela signifie que la boucle vectorisée peut lire 1, 2 ou 3 int supplémentaire. Cela pourrait causer un dépassement de tableau et donc un 'segfault'. Un bon compilateur ne fera pas cela.

Remarque: Le fait que les indices lus soient tous inférieurs à n n'a pas d'importance car, du point de vue du compilateur, l'argument n n'indique pas la taille du taille du tableau. Par exemple, si l'utilisateur est certain que son tableau contient au moins une fois la valeur, il pourrait décider d'utiliser n=INT_MAX.

Très intéressante observation :) En fait, par le standard C++, un appel à std::find() doit forcément passer deux itérateurs sur le même conteneur (car comparer deux itérateurs qui ne pointent pas sur la même séquence est undefined behavior). Du coup le compilateur pourrait se permettre d'utiliser la vectorisation pour l'implémenter, mais pas pour une boucle ad-hoc de l'utilisateur qui, elle, peut effectivement être appelée avec n'importe quoi.

Après il pourrait aussi prendre cela dans l'autre sens : considérer que la boucle lit potentiellement n éléments à partir de v, et si elle lisait une zone non autorisée le programme serait invalide, donc les n éléments sont forcément valides (i.e. n est bien inférieur ou égal à la taille allouée pour v).

PS: Dans ton benchmark, toutes les fonctions sont dans le même fichier. Il n'est pas impossible qu'ICC réussisse à optimiser std::find en inlinant systématiquement tout les appels de fonctions (donc potentiellement plus d'info sur n et sur l'alignement des données). Obtiens tu les même perfs quand find_int_cpp() est compilé dans un fichier séparé?

Je viens de séparer les fichiers (c'est poussé dans le dépôt) et les résultats sont les mêmes :)

Sincèrement avoir un code qui recherche une valeur dans un tableau qui contiens une erreur suffisamment non trivial pour ne pas sauter aux yeux, je préfère avoir un code un peu plus lent. Je place la correction du code comme une qualité qui est tout de même devant toutes les autres en terme de qualité logiciel.

Là dessus je te rejoins complètement. Idéalement je préfère que les algos optimisés viennent de bibliothèques bien rodées ou soient directement fournies par le vendeur du compilateur.

Oui j'ai essayé sur des tableaux aléatoirement triés et ça n'avait rien changé. Je ne m'attends pas à ce que ça change quelque chose puisque les valeurs c'est pas l'important (ici) : elles sont toutes distinctes et on cherche la dernière. Je suppose que le prédicteur de branche va vite comprendre que la condition dans la boucle est plutôt jamais vérifiée.

Je me dis aussi qu'il y a une raison pour ne pas dérouler, d'autant plus que la boucle de std::find() est bien déroulée, elle. Peut-être est-ce une politique générale du genre « tu ne me dis pas -funroll-loops alors je ne déroule pas parce que ça ferait grossir le binaire ».

J'en étais convaincu aussi, mais Compiler Explorer confirme que la boucle n'est pas déroulée si je ne mets pas -funroll-loops. Donc il le fait, mais c'est en plus du lot d'optimisations de O3 :)

Effectivement si on utilise la lib standard d'Intel avec GCC on risque d'avoir les même perfs, mais le fond n'est pas là :)

Le message que j'essaye de faire passer est que, à mon avis, nous nous appuyons trop sur une supposée efficacité des compilateurs pour obtenir des binaires efficaces.

Ici aucun des compilateurs n'a été capable de sortir ne serait-ce que quelque chose d'équivalent à un déroulage de boucle pour la fonction initiale (une simple boucle de recherche), et aucun ne sait vectoriser l'algorithme de lui-même. Par conséquent il faut utiliser une bibliothèque dédiée pour avoir l'algo SSE2, mais là ce n'est plus le résultat du travail du compilateur, c'est le travail des développeurs de la bibliothèque.

Je pense qu'il reste un souci avec ton algo car il ne passe pas les tests que j'ai mis dans le benchmark. Je n'ai pas eu le temps d'approfondir mais il y a déjà la condition de la boucle qui ne gère pas les cas n < 8 (il y a underflow et on entre toujours dans la boucle).

Par contre j'ai ajouté -funroll-all-loops et ça fait gagner sur tous les algos, ce qui est déjà pas mal :)

C'est parce que j'écris en phonétique et je tiens à ce que les lecteurs fassent les liaisons…

C'est corrigé, merci :)

Il me semble que par défaut GCC cible la plateforme hôte, comme si on passait -march=native. Chez moi si je mets ça, et même -mtune=native, les résultats ne changement pas. Par contre je ne peux pas utiliser -march=skylake puisque ça ne correspond pas à ma machine. Peut-être que cela active de l'AVX2, qui rendrait l'algo plus rapide que du SSE2 ? Auquel cas je me demande pourquoi il optimise pour AVX2 mais pas SSE2.

Ah je me disais bien qu'il y avait un truc bizarre. C'est corrigé, merci :)

L'œuvre de David Revoy est en CC-by, mais ce qui est vendu est une œuvre dérivée : elle a subi une modification stylistique par un filtre. Comme l'originale n'a pas la clause Share Alike, la dérivée est sous le coup du copyright classique.

Je comprends que cette utilisation de son art lui déplaise, mais malheureusement cela fait partie du jeu du CC-BY.

Deux choses m'ont fait tilter :

Only one thing is not OK: it infringes my moral right.
[…]
Even if I can proove the DreamCats or any NFT infringes my Moral Right. Even if in theory laws is "with me".

Je doute qu'il y ait une notion de droit moral dans tout ça, et du coup je ne vois pas comment la loi pourrait être de son côté.

I just don't want my name to be associated with a fraction of the NFT empire.

Ça c'est facile, il suffit de faire du CC-0 /s :)

Malheureusement l'utilisateur ne peut pas relancer le serveur :)

(D'ailleurs, je viens de voir un problème dans le journal, est-ce que l'équipe de modération veut-bien changer, dans les références, le lien derrière « Le code d’exemple de départ » par https://gitlab.freedesktop.org/libevdev/libevdev/blob/master/tools/libevdev-events.c s'il vous plait ?)

C'est fait :)

Nous avions eu un problème de limaces et d'escargots aussi, qui nous mangeaient nos pieds de courgettes. Nous nous en étions sortis en mettant une petite barrière : quatre petits piquets autour desquels je tendais un plastique fin genre bâche à serre. Ça faisait un obstacle de 30 cm sur lequel ils n'arrivaient pas à grimper.

Il me semble qu'au pied de la bâche j'avais en plus fait deux tours d'un filet pour fraisier, filet replié sur lui même. Pareil, c'était pour les gêner.

Après ça les pieds étaient tranquilles. Évidemment ça n'est jouable que s'il n'y a pas beaucoup de plants. Ça scale pas.

En fait les coccinelles ne manquent pas, du moment qu'on ne les dérange pas elles prolifèrent bien. Le soucis est plutôt du côté des fourmis qui les dérangent.

Dans l'idée de la permaculture il faudrait donc que j'introduise des prédateurs aux fourmis ou des plantes qui les éloignent. Alors à part mettre un fourmilier dans mon jardin je ne vois pas. T'aurais pas une idée ? Il y a peut-être la réponse dans la deuxième moitié de ton livre :)

Après, le problème d'introduire des espèces non présentes initialement est qu'il y a un risque de prolifération comme les lapins en Australie.

Ah je n'ai pas pensé à ça. Si ça se trouve il suffit effectivement de leur donner ce qu'elles veulent ! J'ouvre un ticket pour le sprint 2022.

J'ai fait un petit journal mensuel de 4-6 pages en 2020 avec Scribus, ça se passait plutôt bien et le PDF était nickel. Il y a cependant pas mal de friction, de souvenir :

• ça rame pas mal ;
• c'est l'enfer d'y éditer de longs textes (gros ralentissements, style qui saute, déplacement du curseur hasardeux), du coup j'écris dans des .txt et je copie-colle ensuite ;
• certains alignements de blocs se faisaient avec 1 mm. de décalage ;
• changer une couleur nommée est laborieux (pas moyen de copier-coller une couleur HTML par exemple).

Ce sont de petites choses et on arrive à faire malgré ça mais ça serait mieux sans.

J'ai quelques doutes sur l'intérêt de passer une heuristique « si tous les caractères ont la même taille, alors on va dire que c'est une police à chasse fixe ». Ça permet bien de corriger le souci d'un PDF mal généré mais en même temps ça masque le souci, qui a donc peu de chances d'être remonté aux développeurs de l'outil en question. Y-a-t-il un autre intérêt en dehors de compenser pour un flag incorrect ?

Au passage, il me semble qu'il est possible d'embarquer les polices dans le PDF. Perso je préfère ça, justement pour éviter les surprises en changeant d'appareil.

C'est fait :)

Fait gaffe, t'as pas de return TRUE à la fin de AddSysROMObjects() :P

Et je soupçonne que Group devrait être écrit ’group’ :)

Depuis le temps que c'est ainsi, as-tu une idée de la raison pour laquelle ce n'est fait directement par le fichier upstream ?

Pourquoi pas leur remonter tes modifs ? J'imagine que s'il y a des problèmes flagrants ils te seraient alors rapportés par les devs, non ?