Journal S'essayer à la production scientifique

Posté par steckdenis (site web personnel) le 30 août 2013 à 20:09. Licence CC By‑SA.

Étiquettes : aucune

août

2013

Bonjour,

Il y a deux ou trois mois, j'avais écrit un journal à propos d'un code source qui tourne plus vite quand je lui rajoute des instructions. Ce journal a donné lieu à plein de discussions très intéressantes sur l'optimisation, et j'y ai découvert comment facilement et efficacement utiliser operf.

Le problème à ce moment-là était que le code en question n'était pas disponible. Je venais en effet de terminer un projet personnel, qui n'était pas encore en état d'être présenté. Il n'y avait pas de documentation, pas d'explications, pas de licence, et très peu de tests.

Au lieu de bâcler la distribution et d'expliquer tant bien que mal le fonctionnement du code (ainsi que ses faiblesses) dans un README, je me suis dit que j'allais m'essayer à l'écriture scientifique. Pourquoi ? Parce que je suis étudiant en sciences informatiques (comme on appelle par chez nous) et que je compte m'orienter vers une carrière de professeur et chercheur (l'avantage est que le libre est très bien représenté et utilisé dans mon université, l'Université Libre de Bruxelles).

J'ai donc pris mon plus beau clavier et j'ai lancé Kile, mon éditeur LaTeX préféré. Je me suis renseigné sur la forme qu'ont habituellement les articles scientifiques, sur la manière dont ils présentent le contenu, et j'ai lu quelques articles (j'en avais déjà lu avant, je trouve que c'est une source d'information assez bien faite, surtout les articles « Untel a publié une thèse impossible à comprendre, donc moi je fais un article qui l'explique clairement »).

Après quelques semaines, voici le résultat. Ce travail n'a pas la prétention d'être de la moindre qualité, et c'est plus un premier essai sur la forme que sur le fond. De même, pour m'imprégner de l'ambiance et pour m'éviter les questions du genre « comment je vais traduire ce jargon en français », j'ai tout écrit en anglais, qui chez moi n'est pas du Shakespeare.

Ce journal a donc deux buts :

Répondre à la curiosité justifiée des personnes ayant commenté mon dernier journal, en mettant à disposition la base de donnée en question;
Demander à ceux qui veulent et à ceux qui savent ce qu'ils pensent de ce premier article. Il doit bien y avoir quelques chercheurs parmi les lecteurs de Linuxfr, ainsi que pas mal de développeurs travaillant dans toute sorte de milieux. Je prends toutes les remarques, qu'elles considèrent le fond, la forme, la manière de rendre l'article plus clair, de mieux le détailler, de le rendre plus pertinent pour un non-chercheur.

La seule chose sur laquelle j'attire votre attention est que mon article ne démontre rien. J'explique comment fonctionne la base de donnée, pourquoi j'ai pensé à faire les choses comme ça, puis je termine par quelques benchmarks (de qualité douteuse, il faut bien l'avouer, je ne suis pas benchmarkeur professionnel). À aucun endroit vous ne trouverez de preuve formelle que mon code marche. D'ailleurs, il marche jusqu'à preuve du contraire, il n'est testé que par les benchmarks et par quelques autres bouts de code qui trainent sur mon ordinateur.

Sur ce, bonne lecture, j'espère qu'elle vous sera agréable.

Les licences : CC-BY-SA 3.0 pour le papier, et GPLv3 pour le code.

# Questions/commentaires après avoir maté l'article 30 secondes

Posté par lasher le 30 août 2013 à 22:21. Évalué à 10.
À chaud, sans avoir pris le temps de lire l'intégralité de ton papier :
- Tu affirmes que ta base de données est lock-free. C'est une affirmation forte. Prouver qu'une structure de données est lock-free est loin d'être une mince affaire. As-tu des preuves (je n'en vois pas réellement dans ton article) ?
- En règle générale, si tu as un algorithme, il est toujours de bon ton d'écrire celui-ci en pseudo-code (ou même en code réel), plutôt que de le décrire par des paragraphes. Les paragraphes permettent de mieux expliquer, mais l'algorithme est la seule chose « formelle » qui puisse être évaluée correctement. Tu as bien des bouts de code, mais ce n'est pas suffisant.
- Par ailleurs, en quoi ta méthode pour détacher/rattacher des éléments est-elle meilleure que celle utilisée par d'autres papiers ?
- Tu prends l'hypothèse que le rapport lecture/écriture varie de 10 à 100 en moyenne. C'est peut-être vrai, mais tu ne justifies pas pourquoi c'est raisonnable.
- J'ai pas compris ton explication pour le stockage persistant. Tu décourages l'utilisation de disques durs. Cela veut-il dire que tu encourages l'utilisation de SSD ? L'a pô compris. Si c'est bien ce que tu dis (utilisez du SSD), il faut reformuler et dire que tu tires avantage de l'accès réellement aléatoire des SSD, et que sur un HDD ça fonctionnera pas mais que ce n'est pas optimisé pour. Quelque chose dans le genre.
- De façon générale, « Technical Properties » tend à induire en erreur je trouve.
- Tu découpes trop de trucs. Si ton article a une vocation scientifique, alors il a aussi une ambition d'être lu par des gens du domaine. Expliquer ce qu'est un nœud de calcul est inutile, surtout que la seule information importante est « mon truc nécessite que tous les processeurs accèdent à une mémoire et un disque partagés ». Pour info, dans un système à mémoire partagée et distribuée, tout est transparent, et le système « en dessous » se charge de tout traduire comme il faut (y compris les opérations atomiques).
- Tu devrais séparer les « caractéristiques » du système de ses buts. Ses buts, ce seront les contributions de ton article. Les caractéristiques sont les moyens par lesquels tu arrives à fournir tes contributions.
Pour reprendre des bouts de ton texte :

The database is to be used when standard in-memory data structures (like hash tables or simple arrays) become unpractical because the data set is too big, but when the performance of in-memory data structures needs to be kept

Ça ressemble fort à une sorte de cache. L'utilisation de SSD pour servir de « cache » ou de « scratch-pad » lors d'un calcul (pour des raisons de tolérance aux pannes, ou bien de gains de performance) est un sujet très populaire depuis un bout de temps.

[…] as none of the algorithms used have a complexity worse than constant-time relative to the number of objects stored in the database.

… Ça veut dire quoi ? Si c'est du temps constant « relatif au nombre d'éléments présents », ça devient une complexité linéaire. Sois clair. Soit tu accèdes à ta structure de données en temps constant, et c'est indépendant des autres données stockées; soit pas, et ton accès est logarithmique (case des arbres binaires de recherche équilibrés et des tables de hachage quand on compte l'amortissement de l'agrandissement de la table au fur et à mesure qu'elle grandit), linéaire (comme lorsque tu cherches un élément dans une liste chaînée), etc.

De plus, parler de « vitesse » plutôt que de complexité est dangereux. Je n'ai pas encore maté tes résultats, mais je peux te faire des algos à la complexité O(1) qui vont fortement faire ramer ton PC (car la constante est très grosse), alors que d'autres, en temps O(n) vont au final être OK.

Je reviendrai sur le reste de ton truc plus tard, mais j'ai pas passé la page 2 à ce stade. :)
# Shakespeare

Posté par pyknite le 30 août 2013 à 23:51. Évalué à 7.
```
 "... j'ai tout écrit en anglais, qui chez moi n'est pas du Shakespeare."
```
J'ai pas tout lu, mais je trouve que des fois, écrire dans une langue que l'on ne maîtrise pas complètement nous force à écrire des phrases beaucoup plus simples et beaucoup plus courtes, ce qui tend, surtout pour ce genre de publications, à faciliter la lecture et/ou la compréhension de certaines parties (voire du tout). Que ce soit pour des anglophones (dans ce cas) ou pour des non-anglophones.
- [^] # Re: Shakespeare
  
  Posté par F(log) le 31 août 2013 à 17:33. Évalué à 3.
  
  +1.
  Quand on est habitue a lire des pages de man en anglais, on a tendance a ecrire clair et concis :D
- [^] # Re: Shakespeare
  
  Posté par arnaudus le 02 septembre 2013 à 09:59. Évalué à 3.
  
  Je dirais même qu'un article scientifique n'a pas à être du Shakepeare : c'est de l'anglais de cuisine qui doit être simple et direct. Les anglophones cultives écrivent parfois de bien mauvais articles, illisibles pour la plupart de leurs pairs. Il faut aussi penser à l'étudiant chinois qui va lire l'article, l'objectif n'est pas d'étaler une (fausse) culture littéraire.
  - [^] # Re: Shakespeare
    
    Posté par lasher le 02 septembre 2013 à 18:04. Évalué à 3.
    
    Bon, ça fait un petit moment maintenant que je rédige et fait la revue d'articles pour mon domaine de recherche. La complexité du sujet lui-même influe sur le temps que je mets à relire un article : une étude sur la performance de deux frameworks pour du parallélisme est en général bien plus facile à lire qu'une nouvelle transformation optimisante, car l'une tient principalement de l'info appliquée, alors que l'autre a tendance à être plus théorique. Et oui du coup, des phrases simples qui vont droit au but aident énormément.
    
    Ceci étant dit, la qualité de l'Anglais fait qu'un article « moyen » peut devenir « acceptable » grâce aux efforts faits pour rendre ce dernier lisible. Un bon Anglais est nécessaire pour des progrès « incrémentaux » : de la recherche qui avance sans être spectaculaire. Mais au contraire, un papier qui propose quelque chose de génial, mais avec un Anglais si pauvre qu'il en devient illisible ne passera pas avec moi. La recherche, c'est aussi une capacité à transmettre les savoirs de façon claire. Un article en Anglais qui est rédigé de façon plus « littéraire » passera ou pas, en fonction de la clarté de ce dernier. Si vous lisez les articles concernant le framework « Galois » (un truc pour faire de la concurrence « transparente » pour que les utilisateurs n'aient pas à penser parallèle), l'Anglais est souvent largement au-dessus du niveau moyen des articles scientifiques qui passent sous mes yeux. Le papier original est à la fois bien écrit, et propose un environnement pour l'écriture de programmes parallèles largement différent des autres (avec des résultats intéressants). Voir par exemple The Tao of Parallelism in Algorithms.
    
    L'opposé n'est généralement pas visible publiquement, puisque l'article est généralement rejeté — sauf pression par un supérieur qui veut que ce papier passe pour des raisons politiques, ce qui n'arrive pas souvent, mais arrive quand même.
    - [^] # Re: Shakespeare
      
      Posté par arnaudus le 02 septembre 2013 à 18:19. Évalué à 2.
      
      Mouais, je n'ai peut-être pas été compris : je ne sous-entendais pas qu'un article en mauvais anglais avait des qualités. La grammaire, la syntaxe et l'orthographe doivent être impeccables pour être intelligibles. Ce que je voulais dire, c'est que le vocabulaire recherché ou les tournures littéraires pouvaient nuire à la lisibilité et la clarté de l'argument scientifique.
      
      En fait, je me suis souvent aperçu que le travail sur la forme du texte (formulations ampoulées, vocabulaire recherché) étaient souvent la manière pour un anglophone de masquer le manque de contenu.
      - [^] # Re: Shakespeare
        
        Posté par lasher le 02 septembre 2013 à 21:08. Évalué à 3.
        
        Par définition, si la formule est ampoulée, elle est n'est pas spécialement utile et devrait sans doute être reformulée, que ce soit pour un article scientifique ou pour une autre forme d'article. La seule raison pour autoriser ce genre de forme est dans une œuvre de fiction, où le narrateur/personnage/etc. s'exprime ainsi (c'est une partie de son caractère).
        
        Après, même en étant « direct », il existe des formes plus ou moins jolies qui passent plus ou moins bien, par exemple :
        
        We conducted our experiments on two platforms: a 4-core Intel Xeon and a 6-core AMD Opteron. The Xeon did [bla bla bla], while the Opteron [bla bla bla].
        
        Une autre façon de dire la même chose :
        
        We conducted our experiments on two platforms: a 4-core Intel Xeon and a 6-core AMD Opteron. The former did [bla bla bla], while the latter [bla bla bla].
        
        L'un est plus idiomatique que l'autre, et du coup plus « facile » à lire. Lorsque ce genre de formulation avec des répétitions est rencontré une fois de temps en temps, on s'en fout. Lorsqu'on le rencontre partout parce que l'auteur ne se préoccupe que de brièveté sans penser un minimum au style, ça devient vite très lourd, et on fatigue.
        
        Est-ce que ce que je voulais dire est plus clair ?
        
        [^] # Re: Shakespeare
        
        Posté par Dr BG le 02 septembre 2013 à 21:35. Évalué à 2.
        
        The former did [bla bla bla], while
        
        Je ne sais plus quelle revue indique, dans ses recommandations aux auteurs, de ne pas utiliser while, mais whereas dans ce genre de cas :-)
        
        [^] # Re: Shakespeare
        
        Posté par lasher le 02 septembre 2013 à 22:51. Évalué à 2.
        
        C'est possible. En pratique, tout dépend du nombre de fois où while et whereas ont déjà été utilisés. ;)
        
        [^] # Re: Shakespeare
        
        Posté par pyknite le 03 septembre 2013 à 12:47. Évalué à 0.
        
        C'est possible. En pratique, tout dépend du nombre de fois où while et whereas ont déjà été utilisés. ;)
        
        Est-ce qu'il faut tenir compte des while du code aussi ? ^{^}
# Se situer dans le contexte et dans le domaine

Posté par jben le 31 août 2013 à 01:26. Évalué à 4.
Alors mon expérience de l'écriture de papiers (qui n'est pas très grande) et de lecture de papiers (qui est plus grande), m'amène à te suggerer quelques petites choses. Attention, mon domaine c'est des maths appliquées (la statistique pour être précis) à la biologie, donc ce que je dis peut être faux dans ton domaine.
- Il faut étoffer ton introduction, tu dois te situer dans le contexte. Moi qui ne connait pas grand chose à la problèmatique, je dois pouvoir vaguement situer ton travail par rapport à l'existant. C'est ce qui souvent nommé state of the art. Il faut décrire l'existant, avec des citations pour les détails, sans toutefoix tomber dans l'extrème inverse de certains biologistes qui remontent jusqu'à Darwin avec deux cent vingt mille citations.
- Il faut décrire ce que tu apporte après avoir situé ton travail dans le contexte.
- Abandonne le deux colonnes, c'est ignoble. Profite en pour réguire le nombre de signe par page (taille++ et interlignage++). La majorité des journaux ont des style tassés en deux colonnes, ils ont des style spécifiques avec plus ou moins de lisiblilité, mais quand tu écris sans soumettre autant faire un article lisible. D'ailleurs si tu va fouiller sur arxiv, tu verras plein de truc du genre, puisque le style des revues n'est pas utilisé.
- Dépose le sur une plateforme genre arxiv. Il pourra être lu et cité.
Il y a encore plein de choses à améliorer, mais pour un premier essai, c'est une très bonne réussite. J'aurai aimé faire un premier essai de cette qualité, je suis jaloux.
- [^] # Re: Se situer dans le contexte et dans le domaine
  
  Posté par Spyhawk le 31 août 2013 à 10:22. Évalué à 5. Dernière modification le 31 août 2013 à 10:23.
  
  Abandonne le deux colonnes, c'est ignoble.
  
  Je ne suis pas d'accord. La grande majorité des publications scientifiques sont en 2 colonnes pour faciliter la lecture, par contre elles sont plus denses (police plus petite, marge plus étroite). Il existe des paquets LaTeX de mise en forme prédéfini qui aident à ne se concentrer que sur le fond, qui fait cruellement défaut ici.
  - [^] # Re: Se situer dans le contexte et dans le domaine
    
    Posté par baron le 31 août 2013 à 10:43. Évalué à 2.
    
    Je ne sais pas dans les autres disciplines, mais c'est clair qu'en maths, c'est très rare (de l'ordre de 2 ou 3 sur 3000 ou 4000).
    
    Deux colonnes ça passe pour des trucs où il n'y a pas trop de formule. Mais d'une manière générale, j'aime pas trop.
  - [^] # Re: Se situer dans le contexte et dans le domaine
    
    Posté par Aldoo le 31 août 2013 à 13:00. Évalué à 3.
    
    Tout LNCS (l'essentiel des publis en informatique) est en 1 colonne.
    L'autre gros morceau (IEEE) est en deux colonnes.
    
    Donc ça dépend vraiment d'où on publie.
    - [^] # Re: Se situer dans le contexte et dans le domaine
      
      Posté par X345 le 31 août 2013 à 13:59. Évalué à 6.
      
      ACM et USENIX c'est des petits trucs ?
      Et honnêtement on s'en fout un peu de savoir si le deux colonnes c'est joli ou pas. Ce qui est importe, c'est ce qui est écrit dans le papier. Après on respecte les règles de la conf/du journal et basta. Ici comme y'en a pas, je vois pas le besoin qu'il y a d'aller finasser là dessus étant donné que l'auteur lui-même a indiqué que son papier était plutôt à l'état de brouillon.
    - [^] # Re: Se situer dans le contexte et dans le domaine
      
      Posté par Maxime (site web personnel) le 01 septembre 2013 à 09:14. Évalué à 4.
      
      Tu ne peux pas dire que LNCS représente l'essentiel des publis en informatique sans donner de référence… L'écrasante majorité des papiers que je lis sont des papiers de conf en 2 colonnes et avec une majorité d'IEEE.
      - [^] # Commentaire supprimé
        
        Posté par Anonyme le 01 septembre 2013 à 10:21. Évalué à 2.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: Se situer dans le contexte et dans le domaine
        
        Posté par Aldoo le 03 septembre 2013 à 17:31. Évalué à 3. Dernière modification le 03 septembre 2013 à 17:33.
        
        J'aurais me douter que ça allait se crisper un débat stérile :). J'imagine bien que selon les domaines les proportions changent (dans le mien, l'omniprésence de LNCS est écrasante).
        
        Peu importe, l'essentiel de mon message, c'était qu'il existait plusieurs styles et que de toute façon il était imposé par l'endroit où on souhaitait publier.
# Forme

Posté par neil le 31 août 2013 à 07:54. Évalué à 9.

est plus un premier essai sur la forme que sur le fond

Clairement, la forme est telle qu’elle laisse complètement transparaître le fait que le fond est vide.

Déjà le document est ridiculement court, alors que les colonnes sont réduites, les marges énormes, le titre prend un tiers de page, il y a très peu de mots par ligne, la majorité des pages est remplie de sous-titres, la quantité d’information transmise dans les figures est quasi-nulle, du code source inutile prend énormément de place, la police est énorme, il y a une table des matières (pour 10 page ?!), les références n’ont aucune valeur scientifique, il n’y a aucune référence valide, aucune équation, aucune démonstration, aucune comparaison à l’existant. Rien que par la forme, on croit que ce document a été généré automatiquement par un programme. Ne suit pas les conseils de benj, et ne met en aucun cas ce document qui n’a rien de scientifique sur Arxiv.

Pour écrire un article il faut avoir une histoire à raconter. Dire : « voilà, jusqu’à ce jour on pensait que le monde était comme-ci, ou bien comme-ça, enfin on était pas trop sûr, ou alors on croyait ou on n’avait pas encore trouvé une solution pour faire telle chose de telle façon. Or dans cet article, je montre que ce qu’on pensait est faux, ou j’apporte une nouvelle technique bien plus performante pour faire telle chose ». Si tu n’as pas d’histoire ou si tu n’as pas une quantité de données pour l’étayer, ça va directement transparaître dans ce que tu écris ou dans tes figures. Il n’est pas possible d’avoir une forme cohérente sans un fond conséquent.
- [^] # Re: Forme
  
  Posté par jben le 31 août 2013 à 14:12. Évalué à 4.
  
  Je ne suis pas vraiment d'accord avec toi, (après je ne connais pas le domaine, moi je ne lit pas des publis d'info).
  
  les colonnes sont réduites, les marges énormes, le titre prend un tiers de page, il y a très peu de mots par ligne, la majorité des pages est remplie de sous-titres […] la police est énorme,
  
  Attend, tu es en train de dire que ce qu'il a fait n'est pas assez dense, au sens typographique j'entends ? Faut arreter de faire des documents les plus illisibles possibles, en disant c'est de la science. Je ne sais pas dans quel domaine tu travaille, mais pour moi si tu veux être lisible il faut que ça ne soit pas trop dense. (Mon avis est peut-être biaisé par la proportion de formule par rapport au texte qui est plus importante dans les publis que je lis).
  
  Ne suit pas les conseils […]
  
  Tu as lu ce que j'ai écrit avant ? Pour moi il faut satisfaire les points précedents avant d'envisager celui là. Et vu le tas de documents présent sur Arxiv, ce n'est pas ça qui fera descendre la qualité globale du machin. Je pense qu'il est dommage de travailler pour ne rien en faire, et justement il me semble une bonne alternative d'avoir comme objectif de le déposer sur Arxiv, qui est un intermédiaire entre ne rien en faire et le soumettre à un journal. Après je suis d'accord avec toi, il y a du boulot, mais c'est aussi ce que j'ai noté. Après il faut admettre que pour un premier essai il y a, à mon avis des félicitations à donner.
  
  Je ne sais pas si toi tu a réussi à écrire un bon papier du premier coup, mais moi j'en étais loin. Si il s'oriente vers une carrière scientifique, alors ça serait bien de ne pas déjà commencer à le dégouter avec les combats vicieux et de dénigrements entre chercheurs.
  - [^] # Re: Forme
    
    Posté par GuiBrother le 01 septembre 2013 à 12:18. Évalué à 8. Dernière modification le 01 septembre 2013 à 12:19.
    
    Au fait, pourquoi chercher à copier la forme d'un article scientifique ? Pour publier plus tard dans des revues scientifiques, je pense que ça ne t'apportera pas grand chose car chaque revue impose son formatage et ses contraintes.
    Si tu vises plutôt un public de non chercheurs évite aussi ce format qui fera fuir la majorité des gens.
    
    Il y a de très bonne choses dans le formalisme des articles scientifiques : les nombreuses références qui permettent de vraiment comprendre en profondeur le problème; une remise en contexte qui (normalement) permet de mieux comprendre l'intérêt de l'étude. Mais aussi pas mal de défauts …
    - la mise en contexte est parfois très longue et apporte peu alors que les algo ou modèles numériques complexes sont balancés en 3 lignes comme si c'était évident.
    - si on ne maîtrise pas le domaine, il faut compter au moins une semaine d'étude bibliographique car les éléments indispensables à la bonne compréhension sont dispersés dans toutes les références citées.
    - si on ne travaille pas dans un labo de recherche ou société qui paie les abonnements scientifiques, compter entre 100€ et 3000€ de votre poche pour pouvoir accéder aux références.
    - on a bien toutes les équations utilisés mais jamais de lien vers des codes sources, des jeux de données réels ou même des cas test. C'est donc très difficile de vérifier et de s'approprier (dans le sens de comprendre) ce qui est écrit sans consacrer des semaines de travail.
    - la mise en page n'est pas spécialement lisible due en bonne partie aux contraintes de taille des articles
    
    Bref, c'est un format qui fonctionne peut-être bien quand on est chercheur dans le domaine mais n'est, à mon avis, pas du tout adapté à la diffusion à un public extérieur (non chercheur, non spécialiste du domaine, non affilié à un labo, …). Les thèses, les revues, les rapports scientifiques sont bien plus accessibles.
# Lock-free: Encore beaucoup à apprendre.

Posté par Gof (site web personnel) le 31 août 2013 à 12:07. Évalué à 10.
Quand tu as des futex_wait ou des pthread_mutex ta structure de donnée n'est pas lock-free
Lock-free veux dire sans aucun lock.

Aussi, il y a des erreurs:
```
while ( _a c ce ss _en ab led && * ptr < generation ) {
    _waiting = 1;
    // [ici]
    futex_wait (& _waiting , 1);
}
_waiting = 0;
```
Et
```
// Wake other threads waiting for us
if ( _waiting )
    futex_wake (( void *)& _waiting );
```
Ce n'est pas comme ça que les futex fonctionnent, il faut mettre à jour la valeur de _waiting.
Par exemple, il y a une race condition si le code de réveil est exécuter là ou il y a le ici.
Lis ce document si ce n'est déjà fait: http://www.akkadia.org/drepper/futex.pdf

Quand tu fait un ftruncate pour agrandir ton fichier, tu dois refaire unmmap pour que les nouvelles pages
soit prises en compte. Bonne chance pour faire ça de façon lockfree.

Je vois aussi que tu utilise le mot clé volatile de temps en temps. Volatile ne doit pas être
utiliser pour la communication entre threads.

Enfin tu dis que tu utilise C++03, mais C++03 ne permet pas de faire de la programmation multi-thread.
En effet: le standard ne mentionne pas les thread et la concurrence.
Ce n'est que à partir de C++11 qui introduit un modèle de mémoire qui fonctionne avec des thread.
Et donc tu peux utiliser std::mutex et std::atomique, ça rends le code plus lisible et portable.
- [^] # Re: Lock-free: Encore beaucoup à apprendre.
  
  Posté par Gui13 (site web personnel) le 01 septembre 2013 à 20:02. Évalué à 2.
  
  J'en profite pour linker un petit article intéressant sur une lock-free hashtable, que j'avais lu avec beaucoup d'intérêt:
  
  http://preshing.com/20130605/the-worlds-simplest-lock-free-hash-table
  - [^] # Re: Lock-free: Encore beaucoup à apprendre.
    
    Posté par steckdenis (site web personnel) le 01 septembre 2013 à 20:23. Évalué à 1.
    
    J'ai lu cet article (comme tout le reste du contenu de preshing.com, captivant), et je trouve juste dommage qu'il saute le chapitre « agrandissement de la table quand elle devient trop petite ». C'est justement ça qui m'aurait intéressé car cela pose plein de problèmes si on veut garder ça lock-free. D'ailleurs, une grande majorité de mon petit papier explique comment j'ai résolu le problème, et je pense que c'est d'ailleurs le seul point un peu nouveau que je présente.
    
    En tous cas, ce site est vraiment bien fait et vulgarise très très bien des concepts compliqués. Pour les amateurs, l'article sur comment trier je ne sais plus quelle quantité de données en n'utilisant qu'un seul méga-octet de RAM est très intéressant aussi.
# Un conseil

Posté par François (site web personnel) le 31 août 2013 à 14:00. Évalué à 10.

D'expérience passé et présente, j'ai un conseil à te donner : si tu es dans une université qui t'intéresse, il doit bien y avoir des enseignants/chercheurs à qui je te conseil fortement de proposer la lecture de ton manuscrit, en allant les voir plus ou moins directement, et en leur parlant des tes projets d'avenir. Ils risquent de prêter l'oreille, plus que tu n'imagines.

Ceci dit il liront ton manuscrit, mais en diagonale sans doute. Malgré tout, leurs commentaires seront sans doute de grande valeur vu que c'est leur métier.
# Étoffer le contenu de l'article

Posté par steckdenis (site web personnel) le 31 août 2013 à 15:31. Évalué à 4.

Bonjour,

Merci à tous ceux qui ont commenté mon article. Ce sont des remarques pertinentes qui pointent toutes vers un travail de meilleur qualité. Voici quelques remarques et quelques réponses (je répond en un bloc car plusieurs personnes disent parfois la même chose).

Tout d'abord, comme beaucoup l'ont fait remarquer, cet article n'a pas du tout la qualité d'une production scientifique professionnelle, rigoureuse et documentée. J'en suis conscient et c'est pour ça qu'au lieu d'essayer « d'imiter » un article professionnel, j'ai joué la carte de la vulgarisation. Les schémas peuvent donc sembler bêtes (bien sûr qu'un expert du domaine comprend le principe de ce que j'explique avant même d'avoir vu le schéma ou lu l'explication), et j'explique les algorithmes à un niveau qui s'adresse plutôt au lecteur du code qui aimerait comprendre ce qui se passe. Je m'adresse dans cet article aux personnes qui m'ont posé des questions sur mon précédent journal.

Le point sur les sources et la recherche est très pertinent. Je me suis rendu compte lors de l'écriture de l'article que je n'avais que très peu de références (et aucune valable). Cela vient de la manière dont j'ai développé la base de donnée. J'avais des besoins très particuliers (explicités dans l'introduction), et j'avais besoin d'une base de donnée correspondant très exactement à ces points. J'ai cherché, assez longuement (tant du côté des bases SQL classiques que du très intéressant Kyoto Cabinet ou DBM), et je n'ai rien trouvé. J'ai peut-être mal cherché, et si quelqu'un trouve une pièce de logiciel qui fait exactement ce que mon papier décrit, mais en prouvé, je serais vraiment ravi de l'apprendre. En attendant, j'étais devant une page blanche avec seulement quelques articles sur la programmation lock-less et les tables de hachage pour m'aider dans mon développement. Ces articles sont cités.

Pour la forme, j'ai lu des thèses très variées. Ma préférée est une très longue et captivante thèse richement illustrée du Dr Tarazona. Une autre thèse, très longue mais difficilement lisible parle d'un algorithme de différenciation de fichiers par Colin Percival (FreeBSD, bsdiff, et d'autres). Ces deux thèses sont de très haute qualité mais m'ont fait me dire que je préfère les papiers moins rigoureux mais plus facilement lisibles. Je n'avais pas envie de me perdre en pseudocode et en formules qui auraient de toute manière été fausses. Pour l'histoire, la thèse de Colin Percival a été « traduite » par Lothar May dans sa thèse de Master.

Le fait que je m'adressais à un public de « curieux » pas spécialement spécialisés, ainsi que mes non-compétences en informatique formelle, m'ont fait m'orienter vers un article pas très détaillé et surtout le plus court possible. Pendant toute la rédaction, j'ai effacé des paragraphes qui me semblaient superflus, j'ai simplifié les idées, j'ai réorganisé l'article plusieurs fois pour ne développer de manière profonde que ce qui en vaut la peine, et surtout après avoir présenté brièvement les algorithmes.

Pour le reste, je prends note de toutes les remarques. J'ai essayé de contacter des gens de mon université il y a quelques mois mais ils n'ont pas répondu, je réessayerai pour avoir plus d'avis et pour pouvoir m'améliorer.
- [^] # Re: Étoffer le contenu de l'article
  
  Posté par Thomas Douillard le 01 septembre 2013 à 15:55. Évalué à 4.
  
  Je suis un peu dubitatif sur ta démarche, tu expliques que tu veux faire un article simili scientifique dans le sens académique du terme en en empruntant les codes, puis tu expliques qu'en fait tu voulais plutôt partir dans une démarche de vulgarisation. Du coup tu te ramasses un peu sur le public qui attend un article scientifique tout en ayant des retours plutôt positifs de ceux qui ne connaissent pas grand chose du sujet, ce qui fait dire que tu est plutôt OK sur la démarche de vulgarisation mais pas du tout au niveau d'un article scientifique ou technique, en ayant des retours plutôt sur la forme que sur le fond du travail, là ou visiblement ça en nécessiterait le plus. C'est un peu batard, tu mets un peu la charrue avant les boeufs, comme dit plus haut il vaut mieux bétonner le fond avant de prétendre écrire un article scientifique … ou alors tu veux écrire de la vulgarisation, mais du coup le cadre de l'article scientifique est pas très adapté, et il faut plutôt sacrifier du niveau de détails que de l'exactitude, c'est plus du tout le même exercice. Ou alors tu veux une critique de ton travail, et là il faut demander une critique de ton travail et essayer de l'exposer un peu plus clairement.
  - [^] # Re: Étoffer le contenu de l'article
    
    Posté par ckyl le 01 septembre 2013 à 16:47. Évalué à 10.
    
    Du coup tu te ramasses un peu sur le public qui attend un article scientifique tout en ayant des retours plutôt positifs de ceux qui ne connaissent pas grand chose du sujet, ce qui fait dire que tu est plutôt OK sur la démarche de vulgarisation mais pas du tout au niveau d'un article scientifique ou technique
    
    Bha non ca veut juste dire que ceux qui ne connaissent pas grand chose ne voient pas le vide du truc. Si les mecs qui connaissent le domaine sont pas convaincu c'est pas que t'es en train de vulgariser mais de raconter des conneries.
    
    Vulgariser c'est avoir parfaitement compris ce dont on parle et avoir la capacité d'en expliquer très subtilement les grandes lignes pour en mettre les idées à la porté de non spécialistes. Ce n'est pas masquer un amas d'approximations ou de faiblesses en s'adressant à des personnes non capable de déceler la faiblesse du truc.
    
    Si on compare à un bon article dans un magazine de vulgarisation dont la démarche est similaire, tu vois rapidement l'escroquerie du truc. Phk sait de quoi il parle et à réussi à isoler l'idée qu'il veut faire passer. C'est très efficace, on voit parfaitement qu'il n'est pas en train d'essayer de noyer le poisson en parlant de tout et rien et qu'il a quelque chose à dire. Au passage y'a plein de bons trucs sur ACM Queue.
    - [^] # Re: Étoffer le contenu de l'article
      
      Posté par Thomas Douillard le 01 septembre 2013 à 16:52. Évalué à 2.
      
      Exact, j'aurai plutôt du dire que c'est OK question compréhensibilité (d'ailleurs je me contredis un peu plus loin en disant qu'il faut de l'exactitude dans la vulgarisation :) )

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.