Julien Jorge a écrit 527 commentaires

C'est corrigé :)

Je reçois aussi des tracts d'agents immobiliers malgré le stop pub. Du coup je les garde dans un tiroir en me disant que le jour où j'aurai quelque chose à acheter ou à vendre ils seront bien les derniers que j'irai voir.

De la diffamation, ça me semble un peu fort. C'est lourd, oui, agressif, sans aucun doute. Je ne pense pas pour autant qu'il faille intervenir (faites comme si je n'étais pas là).

Puisque la discussion devient agressive et n'ira nulle part, je t'invite plutôt à ignorer ton interlocuteur en n'alimentant pas la discussion. Ce n'est pas parce qu'on laisse le dernier mot à quelqu'un qu'on lui donne raison.

Sur les 642 journaux de 2020 (il m'en manque un par rapport à la dépêche :/), 48 ont une note négative ou nulle (7,5 %).

Sur les 518 journaux de 2021, seulement 35 ont une note négative ou nulle (6,7 %).

LinuxFr.org ne se meurt toujours pas et semble même se bonifier avec le temps :)

On peut voir en 2020 une légère baisse de qualité en mars et avril, qui heureusement ne s'est pas maintenue par la suite.

P.S : Benoît, si tu te demandes qui est l'idiot qui requête littéralement journaux?page=$i c'était moi…

La base du film n'est pas les réactions face au Covid, il s'agit plutôt d'une caricature du comportement des trumpistes face au réchauffement climatique.

Le géocroiseur est une menace de destruction de la vie sur Terre qui se rapproche inévitablement. C'est le réchauffement climatique.

La prédidente est Trump. Ses partisans ont des casquette avec un slogan idiot et sont encouragés à ignorer le problème, en regardant de l'autre côté.

Tous les gens au pouvoir n'y sont que pour avoir le pouvoir. Ils n'ont aucune volonté d'agir pour le peuple qui les a élu. Chacune de leurs actions n'est motivé que par leur intérêt personnel.

Les scientifiques sont rabaissés. Les médias diffusent du sensationnel sans faire de vague. La résolution du problème est mise entre les mains d'entreprises de technologie pendant que les scientifiques et le processus scientifique, en particulier la revue par les pairs, sont mis à la poubelle.

Le film est pas mal et critique sérieusement sous couvert de légèreté et d'humour. Heureusement que ce n'est qu'une fiction.

J'interviens en tant que modérateur, puisque nous sommes sollicités, mais je trouve que xcomcmdr gère très bien les commentaires de cette dépêche.

On a donc une dépêche :
- sur un sujet technique,
- en rapport avec le libre,
- qui est une traduction sous licence libre (merci à l'auteur du post original),
- et réalisée par un contributeur de longue date.

Je ne vois pas pourquoi nous l'aurions refusée. Parce qu'il s'agit de Microsoft ? Heureusement la question du libre dépasse le créateur du logiciel, du coup tant que le sujet rentre dans les cases, ça passe. Le site LinuxFr.org n'a pas de vocation militante.

J'ai fait le tour de tes contributions et je ne peux que t'encourager à participer plus, notamment aux dépêches et aux journaux, afin de mieux te familiariser avec les thèmes du site. Un peu comme l'auteur de cette dépêche par exemple ;)

Malheureusement si j'en suis à devoir récupérer la sauvegarde S3 c'est que plus rien ne va, donc si c'est deux semaines ça sera deux semaines :/

Pour les tests, comme tu le conseilles, je travaille avec un petit dossier. Il faut juste que je me motive à faire le test, de préférence avant que les problèmes n'arrivent…

J'utilise pdfjam pour cela, c'est en ligne de commande et cela fonctionne bien.

Merci pour ce chouette journal.

J'ai eu des mauvaises surprises de sauvegarde aussi, et depuis j'ai mis quelques tests un peu plus sérieux sur mon script. Je ne veux pas tester la vraie sauvegarde parce qu'elle fait plusieurs Go et est sur S3 mais j'ai quelques scripts qui font une sauvegarde bidon et vérifient la liste des fichiers stockés à distance.

N'étant pas un pro je fais juste une sauvegarde locale sur un disque externe, chiffré, et une sauvegarde chiffrée à distance. Ça me fait trois versions des données, ce qui me semble pas mal. Ça fait aussi un moment que je me dis qu'il faut que je fasse un script de restauration et aussi que je devrais garder quelques anciennes sauvegardes (la veille, une semaine et un mois) au cas où je me ferai cryptolocker. Ton journal est un bon rappel :)

Avoir des entrées de suivi c'est bien.
Avoir des PR c'est encore mieux.
Avoir des retours sur les PR ce serait encore, encore, mieux :)

Perso j'ai deux PR en cours et zéro retours, du coup j'ai du mal à me motiver à en faire d'autres. D'autant plus qu'à chaque fois je me prends la tête à faire un environnement de test, avec des utilisateurs, des posts, etc. :/

Page 12 :

Les inclusions de fichiers d'en-tête système sont effectuées avant les inclusions de fichiers d'en-tête utilisateur

J'aurais bien aimé une explication sur ce point car d'expérience c'est plutôt une source de galères. On se retrouve à masquer dans le .c les manques du .h, et à chaque fois qu'on inclut le .h il faut deviner ce qu'il manque.

Typiquement leur exemple impose d'inclure stdint.h avant chaque inclusion de header.h, alors que header.h devrait être auto-suffisant.

Bonjour, bonjour,

Comme vous l'avez remarqué un usager du site a entrepris de le quitter tout en informant tout le monde via un journal.

Nombreux sont ceux qui sont venus s'adresser à l'auteur via un commentaire. Je crains qui cela soit inutile, puisqu'il est parti. On ne peut pas être parti et être présent, il ne verra donc pas les commentaires.

Si vous souhaitez continuer de discuter vaccin & Covid, je me permets de rappeler le souhait de l'auteur dans ce journal :

J'aimerais, si possible, que ce journal ne finisse pas en polémique qui affronte les uns et les autres et qu'il reste, tout au plus, une invitation à la réflexion.

N'hésitez pas, non plus, à faire un petit tour des discussions précédentes afin de vous assurer que ce que vous souhaitez ajouter n'a pas déjà été dit, ou que ce soit au moins constructif.

À défaut, ne vous sentez pas obligés d'intervenir dans ce journal, gardez votre énergie pour les suivants :)

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 :)