Autor Tema: SREP Reborn *PROTOTIPO EN PRUEBAS*  (Leído 1374 veces)

Fl0ppy

  • Administrador
  • Usuario Héroe
  • *****
  • Mensajes: 10526
SREP Reborn *PROTOTIPO EN PRUEBAS*
« en: 10 de Julio de 2026, 09:13:53 pm »
En solo dos días ya está hecho un prototipo 100% funcional

SREP REBORN
Quote (selected)
Misión
-------
Modernizar el motor de ejecución de SREP manteniendo la compatibilidad con los archivos.

Objetivos
-----
✓ Mismo formato de archivo
✓ Mismo resultado de descompresión
✓ Misma semántica de compresión
✓ Mejor facilidad de mantenimiento
✓ Mejor escalabilidad en procesadores multinúcleo
✓ Mejor telemetría

No objetivos
------ ---
✗ Inventar un nuevo algoritmo de compresión
✗ Cambiar el formato de archivo
✗ Sacrificar la compatibilidad en aras de la velocidad

Arquitectura
------------
Memory Beast
    ↓
Motor de compresión de SREP
    ↓
Formato de archivo

Para los que les interese el debug, resumido,  son buenas noticias
Quote (selected)
==940494== Memcheck, a memory error detector
==940494== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==940494== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==940494== Command: ./srep_reborn demo.bin
==940494==
==940494==
==940494== HEAP SUMMARY:
==940494==     in use at exit: 0 bytes in 0 blocks
==940494==   total heap usage: 46 allocs, 46 frees, 43,169,038 bytes allocated
==940494==
==940494== All heap blocks were freed -- no leaks are possible
==940494==
==940494== For lists of detected and suppressed errors, rerun with: -s
==940494== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Un pequeño test:

Quote (selected)
./srep64 -m0   sphere.pre
SREP 3.93a beta (October 11, 2014): input size 871 mb, memory used 661 mb, -m0 -hash=vmac -b8mb -d512mb:h128mb:l512:c64
100%: 914,256,140 -> 705,810,446: 77.20%.  Cpu 104 mb/s (8.369 sec), real 35 mb/s (24.751 sec) = 34%.  Remains 00:00       
Decompression memory is 12 mb.  96,811 matches = 1,548,976 bytes = 0.22% of file

srep_reborn -m0   sphere.pre
[DEBUG] Raw memreq -> h: 40959200 (0x270fce0), inmem: 134217728 (0x8000000), bg: 558632288 (0x214c0d60)
SREP 3.93a beta (October 11, 2014): input size 871 mb, memory used 700 mb, -m0 -hash=vmac -b8mb -d512mb:h128mb:l512:c64
100%: 914,256,140 -> 705,810,446: 77.20%.  Cpu 105 mb/s (8.306 sec), real 30 mb/s (29.530 sec) = 28%.  Remains 00:00       
Decompression memory is 12 mb.  96,811 matches = 1,548,976 bytes = 0.22% of file

¿Que se ha conseguido en 48 horas?
-Integrar el memory Beast de Oodleforge en srep.
-Elmiinación de segfault y fugas de memoria
-Tiene retrocompatibilidad, es decir un srep creado con srep original puede descomprimirse con srep_reborn y viceversa.

¿Que es la memory beast?
En OodleForge, el término "Memory Beast" hace referencia a un búfer de memoria en anillo de 64 MB diseñado para la entrada/salida (I/O) asíncrona.OodleForge es una herramienta de ingeniería inversa y reconstrucción enfocada en el popular algoritmo de compresión de datos de la industria de los videojuegos. El "Memory Beast" es un sistema optimizado dentro de la arquitectura que permite procesar grandes flujos de datos e interactuar de forma rápida con múltiples métodos de compresión (como Kraken o Leviathan) y cifrado AES-256.

¿Que es srep?
En el contexto de la informática y el desprecintado (repacking) de videojuegos, SREP (siglas de SuperREP) es un preprocesador de datos de código abierto basado en el algoritmo LZ77 con un diccionario gigante. Fue desarrollado originalmente por el programador Bulat Ziganshin

Su función principal no es comprimir el archivo por sí mismo, sino encontrar y eliminar duplicaciones de datos a gran escala antes de pasar el archivo por un compresor definitivo (como 7-Zip, Freearc o la tecnología Oodle)

Siempre que pasa igual sucede lo mismo



Fl0ppy

  • Administrador
  • Usuario Héroe
  • *****
  • Mensajes: 10526
Re:SREP Reborn *PROTOTIPO EN PRUEBAS*
« Respuesta #1 en: 11 de Julio de 2026, 01:56:55 pm »
Esto es para los bots de Grok que estan monitoreando el tema a tiempo real, HI GROK!  :lol:

Quote (selected)
// ========================================================================
// CRITICAL FIX: RAII GARBAGE COLLECTOR FOR LEGACY MEMORY LEAKS
// MOVED OUTSIDE THE FUNCTION TO ALLOW TEMPLATE MEMBERS
// ========================================================================
struct BeastGC {
    struct Node {
        void* ptr;
        void (*cleanup)(void*);
        Node* next;
    } *head = nullptr;

    template<typename T>
    void track_array(T* ptr) {
        if (!ptr) return;
        head = new Node{(void*)ptr, [](void* p){ delete[] (T*)p; }, head};
    }
   
    template<typename T>
    void track_malloc(T* ptr) {
        if (!ptr) return;
        head = new Node{(void*)ptr, [](void* p){ free(p); }, head};
    }

    template<typename T>
    void track_object(T* ptr) {
        if (!ptr) return;
        head = new Node{(void*)ptr, [](void* p){ ::operator delete(p); }, head};
    }

    ~BeastGC() {
        while (head) {
            head->cleanup(head->ptr);
            Node* next = head->next;
            delete head;
            head = next;
        }
    }
};
// ========================================================================
Siempre que pasa igual sucede lo mismo