neat-ai-core

NEAT-AI-core est le cœur natif Rust partagé de NEAT-AI, une implémentation de NEAT (NeuroEvolution of Augmenting Topologies), l'algorithme qui fait évoluer à la fois les poids et la topologie d'un réseau neuronal. Le dépôt est un espace de travail Cargo dont le membre, la crate neat-core, contient la bibliothèque de calcul partagée ainsi que ses tests. Ce que fournit la crate. Le scoring, la perte et les noyaux SIMD utilisés pour traiter de nombreux enregistrements via un seul individu évolué, que le projet appelle une créature. La compilation par défaut et la compilation wasm32 empruntent un chemin monothread ; l'activation de la fonctionnalité Cargo parallel ajoute un scoring d'enregistrements parallèle basé sur rayon pour les cibles natives. Les chemins de scoring séquentiels et parallèles pilotent tous deux une passe avant via un chemin SIMD par lots de 8 enregistrements, suivi d'un groupe de 4 enregistrements et d'une queue scalaire. Le README indique que sur la topologie de production commitée, les noyaux sécurisés entraînent un coût de pré-passe mesurable, c'est pourquoi les consommateurs disposant de leur propre validation au chargement sont orientés vers les versions non vérifiées (unchecked), et que la voie native surpasse la voie wasm32 par cœur. API de Scoring. L'entrée et la sortie utilisent une disposition plate et contiguë : l'enregistrement i lit inputs[i * stride .. i * stride + stride] et ses sorties atterrissent dans out[i * num_outputs .. (i + 1) * num_outputs]. Les anciens wrappers de vecteurs par enregistrement ont d'abord été dépréciés puis supprimés, les appelants doivent donc regrouper les enregistrements dans un seul tampon et appeler les points d'entrée plats ; un stride nul ou un tampon qui n'est pas un nombre entier d'enregistrements provoque un panic plutôt qu'un mauvais découpage silencieux. Les réseaux compilés sont en lecture seule après construction. Les champs sont privés et exposés via des accesseurs par emprunt uniquement, et un constructeur from_parts construit un réseau à partir de neurones et de synapses en mémoire, appliquant la même validation que le constructeur basé sur le tampon et rejetant une portée de synapse qui dépasse la table. Le README note qu'il s'agit d'un changement majeur pour les consommateurs en aval. Flags de fonctionnalités. parallel est désactivé par défaut, donc les builds par défaut et wasm32 n'incluent aucun symbole rayon ; checked-gather4 est également désactivé par défaut et rétablit l'indexation avec vérification des limites dans l'assistant gather4 wasm32. Chaque noyau du module SIMD est livré sous forme de fonction sécurisée qui valide sa portée et provoque un panic si le contrat n'est pas respecté, ainsi qu'un jumeau non vérifié dont le contrat de sécurité est l'invariant d'index au chargement. WebAssembly. Chaque push publie deux bundles : un build wasm64 Memory64 que les nouvelles révisions épinglent, et un build wasm32 inchangé conservé comme fenêtre de retour arrière, chacun avec son propre fichier checksum et SBOM, soumis à des vérifications de bundle et de parité d'architecture avant la publication. Build et qualité. Le développement suit le développement piloté par les tests ; la passerelle de qualité locale exécute le formatage, clippy, les tests, la documentation, les vérifications de licence et de sécurité, ainsi que la suite de tests shell bats, et la CI est exercée sur les pull requests et par dispatch manuel. Le manifeste racine définit les profils dev et release pour tout l'espace de travail (infos de debug line-tables-only pour des reconstructions dev rapides ; opt-level 3 avec LTO fat et une seule unité de codegen pour la release), tandis que target-cpu=native est délibérément laissé aux consommateurs binaires en aval plutôt que d'être épinglé ici.