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

    Posté par . En réponse au journal S'essayer à la production scientifique. É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. :)