n_e a écrit 20 commentaires

Je compte qu'il devienne suffisamment fort suffisamment tôt pour ne pas avoir besoin de répertoire d'ouvertures. En plus je trouve intéressant de le laisser lui-même trouver les ouvertures et voir ce qu'il découvre.

Aussi, les compétitions d'ordinateurs ont des ouvertures imposées (parce que les ordis les plus forts font toujours nulle en partant de la position initiale - on fait donc des matchs aller-retour à partir d'une position imposée).

Envisages-tu que ton moteur soit capable de jouer des parties FRC (ou Chess960) voire même DFRC (ou FRD) ?

Oui et non. Non parce que à titre personnel je n'y ai jamais joué et ça ne m'intéresse pas (je trouve déjà les échecs normaux suffisamment difficiles). Oui, au sens que j'y ai pensé et que si je change d'avis ça ne sera pas trop compliqué à changer (du moins pour la partie règles).

Si le filtre doit parcourir la colonne entière, le temps reste linéaire.

La complexité algorithmique reste linéaire. Par contre, et je trouve ça fascinant, c'est que la lecture est tellement rapide (grâce à la localité des données et le filtrage qui est souvent fait avec des instructions SIMD), que bien que la complexité algorithmique soit naze, ça reste rapide.

D'ailleurs les bases de données colonne ne supportent pas (du moins les plus courantes comme clickhouse, duckdb, bigquery, etc.) les index BTree.

Il y a cependant des optimisations, mais qui la plupart du temps n'affectent pas la complexité algorithmique (skip indexes, tri selon la clé primaire, parallélisation).

Je n'ai effectivement pas en tête d'amélioration "utile" datant disons de ces cinq dernières années, par contre si on compare à il y a 20 ans c'est la révolution.

Par exemple en ce moment je suis en train d'apprendre une nouvelle ouverture, et je le fais uniquement avec une base de parties et Stockfish. Il y a 20 ans j'aurais dû acheter un livre, qui n'aurait peut-être pas existé ou traité les lignes qui m'intéressent, et qui aurait été probablement faux.

Quant aux explications des coups joués, effectivement c'est quelque chose qui n'existe pas vraiment (si ce n'est la fonctionnalité de chess.com qui a un gros manque de pertinence), mais il y a pas mal de techniques pour comprendre un coup de l'ordi :

• faire passer le tour plusieurs fois à l'adversaire et regarder comment l'ordi progresse en l'absence de défense

• jouer des coups logiques contre l'ordi et regarder comment il punit

• jouer la même suite de coups après le coup de l'ordi et le coup qui nous semble logique, et comparer

Il faut aussi ne pas hésiter à rejeter un coup de l'ordi s'il ne parait pas approprié (par ex. il propose souvent un mauvais coup positionnel mais qui marche grâce à des complications tactiques incompréhensibles, alors qu'un coup logique est OK)

Tout à fait ! Je ne l'ai pas précisé dans le journal, mais effectivement ça fera partie de la première étape de m'assurer qu'il n'y a pas de bugs dans le générateur de coups.

Stockfish est purement un moteur classique, même s'il utilise aujourd'hui un réseau neuronal pour évaluer les positions : il explore énormément de branches avec un algorithme minimax, et évalue les positions rapidement avec une fonction d'évaluation rapide et rudimentaire (comparé aux descendants d'AlphaZero, pas à deepblue). Les optimisations très pointues pour limiter le nombre de branches explorées et donc augmenter la profondeur sont également typiques des architectures classiques, et on les retrouve que le moteur utilise une évaluation NNUE (par réseau neuronal) ou HCE (écrite à la main).

Je pense que ce qui illustre le mieux la différence entre archi classique et archi "type AlphaZero", est que stockfish explore des millions de noeuds par seconde, alors que le moteur Maia (basé sur LeelaChess0) joue à un niveau correct (jusqu'à 1900 ELO) en utilisant juste la fonction d'évaluation et sans faire de recherche.

c'est comment tu mesuresde façon impartiale que le niveau de jeu a augmenté ou pas par rapport au commit précédent

Effectivement, en faisant jouer l'ordi contre lui-même, idéalement en cadences rapides pour que ça ne prenne pas trop de temps. Et en utilisant un test statistique pertinent pour ne pas valider une modification qui aurait gagné davantage de matchs par hasard (en l'occurence la plupart des outils comme cutechess-cli utilisent SPRT).

Et sur ta machine, quel est le temps CPU en mono-thread des processus Java, wrk avec Java, puis Rust, et enfin wrk avec Rust ?

Selon vmstat, avec varnish je suis à 100%, en rust à 90%, java à 50% (avec 6 cœurs).

wrk utilise entre 0.7 et 1.5 cœurs selon les benchs, et j'ai des trucs divers qui utilise 0.7 cœurs.

Le CPU n'est occupé qu'a 12 %, et wrk prend autant de temps CPU que le processus Java…

Tu as 16 cœurs ?

Tel que je comprends la doc, il n'y a que les handlers de requête qui sont parallélisés. Du coup à partir du moment où tout ce qui n'est pas handler utilise 100% de CPU, ça ne sert à rien d'ajouter davantage de parallélisme.

nginx aussi compile, il utilise LuaJIT :)

Concernant Varnish, ton lien indique :

Note

If you run across tuning advice that suggests running one thread pool for each CPU core, rest assured that this is old advice. Experiments and data from production environments have revealed that as long as you have two thread pools (which is the default), there is nothing to gain by increasing the number of thread pools.

Cela dit c'est complètement possible que j'aie raté des choses.

Vu que dans les programmes déjà existants Java était single-threadé et Rust multi-threadé la question se posait, et j'ai préféré prendre ce qui était le plus performant dans une configuration relativement standard.

Avec node.js en mode cluster on arrive à :

Requests/sec: 140514.83
Transfer/sec: 26.00MB

soit 4.5x la perf. monothreadée, donc un scaling quasi-linéaire (sur les 6 CPUs, 1 CPU était pris par wrk, et 0.7 par d'autres process).

const http = require("node:http");
const { cpus } = require("node:os");
const cluster = require("node:cluster");

const numCPUs = cpus().length;

if (cluster.isPrimary)
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }
else {
  const server = http.createServer((req, res) => {
    if (req.path !== "/") res.writeHead(404);

    res.writeHead(302, {
      location: `https://avatar.spacefox.fr/Renard-${Math.round(
        Math.random() * 10
      )}.png`,
    });

    res.end();
  });

  server.listen(8000);
}

Donc pour l'instant, AMHA, les generics ne servent pas à grand chose si ce n'est composer des interfaces.

Je dirais qu'ils servent surtout à gérer les conteneurs et les fonctions qui opèrent dessus en ignorant le contenu de façon simple, type-safe et sans codegen.

Par exemple, le package sort permet de trier un slice en utilisant la fonction https://pkg.go.dev/sort#Slice qui n'est pas vraiment ergonomique (je dirais même pas sûre).

Avec les génériques on pourrait avoir func Slice[T any](x []T, less func(xi, xj *T) bool) à la place.

Pour prendre un exemple plus compliqué, l'outil dataloaden permet de générer du code pour un pattern "dataloader", ie. permettre d'avoir une fonction fn(T): U dans l'interface publique, et d'avoir le traitement implémenté dans une fonction fn2(T[]): U[], qui est appelée beaucoup moins de fois que fn (et donc optimiser plus facilement le traitement). Aujourd'hui c'est fait avec de la codegen, et ce serait beaucoup plus ergonomique avec des génériques (compilation plus rapide que la codegen, pas besoin de déclarer la liste des variantes à générer, facile d'adapter le code, etc.)

La même chose en Haskell :

import Data.List

msum =
  sum . map sum . map (takeWhile $ (<) 0) . transpose

main = do
  print $ msum [[0, 2, 3],[1, 0, 4],[5, 6, 7]]

De plus, ça force à écrire les fameuses callback dont parle l'auteur, mais avec une variante en utilisant la "arrow syntax" (qui ne propage pas le this dans les callback), qui est courte et élégante.

En quoi utiliser des fonctions avec l'arrow syntax est plus court et élégant que ne pas en utiliser du tout ?

Avec cette syntaxe, une autre chose que j'aime bien: on a pas besoin de déclarer ses variables (const toto) vu qu'on les récupère directement en paramètre des closures et on peut arriver à un stade où on peut considérer que déclarer des variables est une erreur de programmation

Absolument pas. Non seulement c'est possible de ne pas déclarer de variables temporaires avec async/await, mais surtout en déclarer n'est pas une erreur de programmation et rend le code plus clair.

Quand on écrit const xml = await res.text() ou const totozList = obj.totozes.totoz.length ? obj.totozes.totoz : [obj.totozes.totoz], il suffit de lire le nom de la variable pour savoir ce qui est retourné.

on rajoute des embranchements et la complexité cyclomatique et donc on augmente la probabilité d'avoir des bugs (certains analyseurs statiques d'ailleurs mettent ça en valeur).

Je ne vois absolument pas en quoi une structure de type

r1 = f1()
r2 = f2(r1)
r3 = f3(r2)

ajoute quoi que ce soit en complexité par rapport à f3(f2(f1())).

Par ailleurs, avec les promesses, on ne mélange pas les scopes, et donc on ne partage pas les variables: on réduit par la même occasion les chances d'écrasement ou d'utilisation de variable accidentels de par cette isolation

Dans l'exemple, tout est déclaré avec le mot-clé const, rien ne peut être écrasé. Par ailleurs rien n'empêche d'appliquer les bonnes pratiques comme donner des noms clairs aux variables et écrire des fonctions courtes en utilisant async/await.

Si vos données sont sur un SSD au format M.2, cas le plus favorable, vous en avez pour une petite journée (au moins 5h30) de recherche à la bibliothèque (plus de 0.02 ms, soit plus de 20 000 ns… et donc 80 000 instructions2).

Le cas le plus favorable, c'est un SSD NVMe, qui communique directement sur le bus PCI Express. Le format M.2 permet d'utiliser des SSD NVMe mais aussi SATA.

C'est aussi possible d'utiliser des SSD NVMe sans port M.2, qui se branchent sur un connecteur PCI Express classique.

le message d'erreur se trouvera a l'appel de la fonction et non a la définition/implémentation de celle-ci

Effectivement, comme tu ne tapes pas le type de retour, tu n'auras pas de message d'erreur si le type de retour n'est pas celui que tu t'imaginais dans ta tête (tant que tu n'auras pas écrit une autre fonction qui appelle la 1ère).

Cependant ce n'est pas un problème :

• Ce que je fais (et je ne dois pas être le seul), c'est de regarder le type que retourne la fonction dans l'éditeur, et modifier la fonction jusqu'à ce qu'elle retourne le type voulu. Ou alors ne pas la modifier et garder le type retourné (ça arrive très souvent que le type "naturel" soit mieux que ce que je pensais vouloir à l'origine)
• Quand tu écris une autre fonction qui appelle la première, peu importe que le message d'erreur apparaisse au niveau de la fonction appelée ou appelante : tu dois de toute façon décider si le mieux est de modifier la fonction appelée ou appelante (par exemple dans l'exemple du journal, si tu préfères que la fonction getTemp retourne un nombre ou si tu vas te débrouiller avec la chaine retournée).

il est très simple d'écrire une signature de fonction aussi générique soit-elle. Au lieu d'utiliser Int ou String, tu utilises a par exemple

Ce n'est pas parce que c'est simple à écrire que c'est simple à remarquer (il y a par exemple le cas fréquent d'une fonction sur les chaînes de caractères qui s'appliquent souvent aussi à des tableaux, mais il y a énormément de cas moins évidents).

Haskell est un des langages avec la meilleure inférence de types, c'est dommage de faire le boulot du compilateur à la main et en moins bien.

Il se trouve qu'en Haskell ou en Elm (les deux langages en FP que j'ai pu pratiquer jusqu'à présent), on écrit tout de même les signatures des fonctions et donc les types des arguments

En Haskell (je ne connais pas Elm) ce n'est pas nécessaire. Tu as d'ailleurs intérêt à ne pas le faire car cela te permet de te rendre compte que ta fonction est plus générique que ce que tu pensais en l'écrivant.

principalement parce que le code est destiné à être lu par des êtres humains, qui n'ont pas toujours le temps ou l'envie d'analyser le corps d'une fonction pour inférer eux-même les types "manuellement".

Elle est affichée au survol dans ton éditeur ou avec les commandes :info ou :type dans ghci.

Cependant, ça serait mieux si ton exemple de code contenait le fichier entier, c'est à dire avec les import qui vont bien!

Tu as raison, ça aurait en plus permis de voir que je ne cache pas de boilerplate ou de complexité en ne mettant qu'un bout de fichier.

Et avec io.type, je vois que du coup tu ne prends pas le temps de définir une interface pour la structure de données attendue, c'est volontaire ?

Oui, c'est volontaire, le type se définit "tout seul" vu la façon dont io-ts est lui-même déclaré.

C'est possible de définir une interface sans tout retaper en faisant comme ça :

interface IReleve extends t.TypeOf<typeof Releve> {}

Et évidemment si tu utilises VSCode ou autres tu vois tout le détail des types.

C'est quand même mieux de faire une requête simple (ta requête deux posts plus haut est déjà plus longue que celle avec ON CONFLICT) que plusieurs, non ?

Pour le point 2), pour éviter les phantom reads il faut utiliser le niveau d'isolation serializable, niveau où les requêtes peuvent échouer. Ça complique encore plus la chose (alors que l'upsert est atomique).