RSPchecksum Files

# rspchecksum-linux (v1.2.0)

## ?? Resumo
Este repositório apresenta as implementações oficiais dos algoritmos de checksum **RSP32, DS32 e DS64**, desenvolvidos e consolidados desde 2011 no projeto **rspchecksum** hospedado no SourceForge. O código-fonte nativo e otimizado para o ecossistema Linux encontra-se no diretório `files_linux`.

---

## ??? Notas de Engenharia e Arquitetura

### 1. Decisão Estratégica: Abandono do `io_uring`
Após testes rigorosos de estresse em hardware de desenvolvimento (PC doméstico/WSL 2), a implementação experimental de I/O assíncrono via `io_uring` proposta por agentes automatizados foi **desativada e removida**. 
* **Motivo:** O *overhead* de sincronização de filas (*Submission/Completion Queues*), disputas de threads do Kernel e trocas de contexto (*context switching*) causaram uma degradação intermitente de performance de **até 20x** em hardwares convencionais.
* **Solução:** O projeto mantém o foco exclusivo em I/O síncrono POSIX puro com gerenciamento de buffer via `glibc`, garantindo linearidade, estabilidade e previsibilidade.

### 2. Refatoração Crítica do Algoritmo DS32 Original
O motor do `ds32` foi atualizado para eliminar comportamentos indefinidos (*Undefined Behavior*) e otimizar a portabilidade cruzada entre o ambiente clássico do Windows e o Linux moderno:
* **Remoção de Efeitos Colaterais:** A inicialização da semente matemática (`0x63817989`) foi movida estritamente para **fora** da função. Isso eliminou um desvio condicional (`if`) redundante executado bilhões de vezes e blindou o algoritmo contra o "Bug do Zero Acidental", onde um hash intermediário legítimo igual a `0` resetava erroneamente o cálculo em processamentos por blocos (*streaming*).
* **Segurança de Alinhamento e Strict Aliasing (Endereço vs. Tamanho):** 
  O algoritmo foi desenhado sob duas premissas físicas de memória:
  1. *O Tamanho (`len`):* Pode assumir qualquer valor (par, ímpar ou fracionado). A lógica de cauda (`remaining_bytes`) gerencia e limpa com segurança restos de 1 a 3 bytes via buffer temporário estável. Tamanhos múltiplos de 4 oferecem ganho passivo de velocidade por pularem o desvio condicional da cauda.
  2. *O Endereço do Ponteiro (`buf`):* Para performance máxima da CPU, o buffer deve iniciar em um endereço alinhado na RAM (múltiplo de 4 bytes) para evitar cruzamento de linhas de cache.
  
  Substituiu-se o *cast* direto de ponteiros `(const uint32_t *)buf` por cópias de tamanho fixo via `memcpy`. Em compiladores modernos (GCC/Clang com `-O3`), o `memcpy` estático é fagocitado pelo otimizador e convertido em instruções nativas de registradores (`MOV/ADD`). Caso o ponteiro de entrada venha desalinhado por um fluxo externo, o compilador emite instruções seguras de leitura desalinhada (`MOVDQU`), impedindo um **Crash instantâneo (Alignment Fault)** no Linux e mantendo o binário estável.
* **Isolamento de Endianness:** Implementação de diretivas de pré-processador para arquiteturas de hardware (`__BYTE_ORDER__`). O código executa somas puras e diretas na velocidade máxima do silício em máquinas *Little Endian* (Intel/AMD), mas mantém a portabilidade determinística caso seja compilado em servidores *Big Endian*.

### 2.1. Introdução do Algoritmo DS64

Importante: O tamanho do buffer tem que ser sempre multiplo de 8

O **DS64** foi integrado como evolução natural do DS32, trazendo suporte nativo a registradores de 64 bits e maior robustez em cenários de dados extensos:
* **Compatibilidade:** Mantém a mesma lógica fundamental do DS32, garantindo hashes determinísticos e consistentes.
* **Performance:** Em testes sem otimização (`-O0`), o DS64 demonstrou até **100% de ganho de velocidade** em relação ao DS32. Com otimização (`-O3`), ambos atingem tempos equivalentes (~0.148s), provando estabilidade e ausência de regressão.
* **Hash Diferenciado:** O DS64 gera assinaturas distintas (ex.: `28091d2447539101`), confirmando operação em 64 bits sem perda de integridade.
* **Aplicações Futuras:** Ideal para cenários que exigem manipulação de grandes blocos de dados, alinhamento de memória em 64 bits e potencial integração com instruções vetoriais (SIMD/AVX).

### 3. Análise de Pipeline e Restrições do Algoritmo RSP32

Se o tamanho dos dados for multiplo de 256 e os dados forem o mesmo caracter seja ele qual seja o reultado sempre será o seed, ok, só fiquei sabendo disso hoje graças ao Copilot, se pra você isso é um problema então não use este checksum.

### 4. Resultados de Benchmark (Massa de Dados Aleatórios: ~15 GB na RAM)
Testes controlados utilizando dados puramente caóticos/aleatórios revelaram a eficiência da simplicidade matemática linear do `ds32` e `ds64` contra as outras soluções sob estresse severo:
* **[DS32 Otimizado]:** **0.155 segundos**  
* **[DS64 Otimizado]:** **0.148 segundos** (mesmo desempenho do DS32, mas com hash 64 bits distinto)  
* **[CRC32 Hardware SSE4.2]:** **3.040 segundos**  
* **[Adler32 Software]:** **7.470 segundos**  
* **[RSP32 Serial]:** **10.427 segundos**

---

## ?? Changelog

### - 2026-05-21 (v1.2.0)
#### Alterado
* **`ds32`:** Refatorada a assinatura da função para receber a semente externamente.
* **`ds64`:** Adicionado oficialmente ao projeto, com documentação de benchmarks e comportamento em 64 bits.
* **`rsp32`:** Integrada a assinatura da função com `restrict`.
* **Documentação:** Expandido o `README.md` para incluir o DS64 e seus resultados comparativos.

#### Removido
* **I/O:** Removida por completo a camada experimental do `io_uring`.

---

## ??? Roadmap

- [x] Benchmarks comparativos analíticos (Adler32 vs. CRC32 vs. DS32 vs. DS64 vs. RSP32)
- [ ] Configuração do Makefile automatizado
- [ ] Suporte oficial a Linux (`.so` com `-fPIC`)
- [ ] Multithread otimizado até 128 threads
- [ ] Escalar para até 512 threads
- [ ] Integração com instruções SHA aceleradas em hardware
- [ ] Documentação expandida com exemplos em CMake e POSIX