neat-ai-core

O NEAT-AI-core é o núcleo nativo compartilhado em Rust do NEAT-AI, uma implementação de NEAT (NeuroEvolution of Augmenting Topologies), o algoritmo que evolui tanto os pesos quanto a topologia de uma rede neural. O repositório é um workspace do Cargo cujo membro, o crate neat-core, contém a biblioteca de computação compartilhada juntamente com seus testes. O que o crate fornece: Pontuação, perda e kernels SIMD usados para processar muitos registros através de um único indivíduo evoluído, que o projeto chama de criatura. A build padrão e a build wasm32 seguem um caminho de thread única; a ativação da feature parallel do Cargo adiciona pontuação de registros com paralelismo de dados baseado em rayon em targets nativos. Tanto os caminhos de pontuação sequenciais quanto paralelos acionam o forward pass através de um caminho SIMD em lotes de 8 registros, seguido por um grupo de 4 registros e uma cauda escalar. O README relata que, na topologia de produção commitada, os kernels seguros carregam um custo de pré-pass mensurável, portanto, consumidores com sua própria validação em tempo de carregamento são direcionados aos gêmeos unchecked, e que a lane nativa supera a lane wasm32 por núcleo. API de Pontuação: A entrada e a saída utilizam um layout plano e contíguo: o registro i lê inputs[i * stride .. i * stride + stride] e suas saídas ficam em out[i * num_outputs .. (i + 1) * num_outputs]. Os wrappers de vetor por registro mais antigos foram primeiro depreciados e depois removidos, portanto, os chamadores devem empacotar registros em um único buffer e chamar os pontos de entrada planos; um stride zero ou um buffer que não seja um número inteiro de registros causa pânico em vez de fatiar incorretamente de forma silenciosa. Redes compiladas são somente leitura após a construção. Os campos são privados e expostos através de acessores apenas de empréstimo (borrow-only), e um construtor from_parts constrói uma rede a partir de neurônios e sinapses em memória, aplicando a mesma validação que o construtor baseado em buffer e rejeitando um span de sinapse que ultrapasse a tabela. O README observa que esta é uma alteração disruptiva (breaking change) para consumidores downstream. Feature flags: parallel está desligado por padrão, portanto, as builds padrão e wasm32 não trazem símbolos do rayon; checked-gather4 também está desligado por padrão e restaura a indexação com verificação de limites no helper gather4 do wasm32. Cada kernel no módulo SIMD é enviado como uma função segura que valida seu span e causa pânico se o contrato não for mantido, além de um gêmeo unchecked cujo contrato de segurança é o invariante de índice em tempo de carregamento. WebAssembly: Cada push publica dois bundles: uma build wasm64 Memory64 que as novas revisões fixam, e uma build wasm32 inalterada mantida como janela de rollback, cada uma com seu próprio sidecar de checksum e SBOM, controladas por verificações de bundle e paridade de arquitetura antes do release. Build e qualidade: O desenvolvimento segue o desenvolvimento orientado a testes (TDD); o gate de qualidade local executa formatação, clippy, testes, docs, verificações de licença e avisos, e a suíte de shell bats, e a CI é exercitada em pull requests e despacho manual. O manifesto raiz define perfis de dev e release para todo o workspace (informações de debug line-tables-only para rebuilds rápidos de dev; opt-level 3 com fat LTO e uma única unidade de codegen para release), enquanto target-cpu=native é deliberadamente deixado para os consumidores binários downstream em vez de ser fixado aqui.