Mide el rendimiento en tu maquina y publicalo

**Eslopes** · 27.10.2026 07:38

PowerRustCOBOL 1.37.0 incluye por primera vez un banco de pruebas de rendimiento, y me gustaria pedir vuestra ayuda: ejecutadlo en vuestras maquinas y publicad aqui los resultados. Con medidas de equipos y sistemas distintos se puede optimizar sobre datos reales en vez de sobre suposiciones.

La version 1.37.0 marca el inicio del trabajo de optimizacion hacia la version de produccion, y esta es la linea de partida.

Que mide

Cada programa COBOL de la prueba recorre exactamente el mismo camino que un binario compilado: tokenizar, analizar y ejecutar con el interprete. Es decir, los numeros describen el interprete que va dentro de las aplicaciones que entregais, no una biblioteca aislada.

Ademas del tiempo se cuentan las reservas de memoria. Rust no tiene recolector de basura, asi que no hay pausas que medir; lo que importa bajo carga es cuantas veces se entra al asignador, cuantos bytes pasan por el y cuanto queda vivo en el pico. Un asignador global que cuenta da las tres cifras exactas en Windows, Linux y macOS sin ningun perfilador externo.

Como ejecutarlo

Desde la raiz del repositorio:

Código:

cargo run --release -p cobolt-bench

Tarda unos segundos una vez compilado e imprime una tabla directamente.

--release es obligatorio. En modo debug se mide la ausencia de optimizacion y las cifras no valen para nada. El programa avisa en la cabecera si se os olvida.

Para una sola carga de trabajo:

Código:

cargo run --release -p cobolt-bench -- dispatch

Los filtros validos son: dispatch, decimal, record (o batch), object, indexed.

Para una comprobacion rapida, una veinteava parte del trabajo:

Código:

PRC_BENCH_SCALE=0.05 cargo run --release -p cobolt-bench

Ojo: solo son comparables ejecuciones con la misma escala. Si publicais resultados, usad la escala por defecto (sin PRC_BENCH_SCALE).

La referencia actual

Apple M3 Pro, 18 GB, macOS 15.5, rustc 1.95.0, perfil release:

Código:

Carga                                 Ops/seg      Reservas/op   Pico vivo
dispatch (PERFORM VARYING)          5.721.961         4,00         0,0 MB
dispatch (PERFORM parrafo)            686.318        18,00         0,0 MB
COMPUTE decimal                       606.461        20,00         0,0 MB
lote de registros (1000, escr+lect)   183.612        65,06         0,8 MB
rotacion de objetos                   216.320        55,00         0,0 MB
indexed redb (insercion masiva)       140.922         0,66        22,4 MB
indexed redb (lectura aleatoria)    1.489.965         0,00        22,4 MB

Las cifras absolutas viajan mal entre maquinas; la columna de reservas por operacion viaja bien y deberia salir practicamente igual en cualquier equipo. Si en el vuestro no sale igual, eso ya es un hallazgo interesante por si mismo.

Que conviene publicar

- Procesador, memoria RAM y sistema operativo (con version).
- La salida de "rustc --version".
- La tabla tal cual la imprime el programa.
- Si compilasteis con alguna opcion fuera de lo normal.

Lo que ya dice la referencia

El cuello de botella no es el recorrido del arbol sintactico, sino el asignador de memoria. 5,7 millones de sentencias por segundo suena bien, pero hicieron falta 24 millones de reservas para ejecutar 6 millones de sentencias: un "ADD 1 TO ACC" entre dos campos COMP, que no deberia tocar el monticulo en absoluto, cuesta cuatro visitas al asignador. Eso cambia el orden del trabajo: una maquina virtual de bytecode aceleraria el despacho y dejaria esas cuatro reservas intactas, asi que se empieza por la memoria.

Las llamadas a parrafo cuestan 18 reservas cada una frente a 4 de una sentencia en linea. Los registros alfanumericos, 65 reservas por registro. Y las lecturas de propiedades de objeto reservan una cadena por lectura solo para poner el nombre en mayusculas.

El motor INDEXED, en cambio, no es el problema: redb inserta a 141.000 registros por segundo con 0,66 reservas por registro y sirve 1,5 millones de lecturas aleatorias por segundo casi sin reservar nada. El almacenamiento va holgadamente por delante del interprete que lo alimenta.

Los detalles completos, que aisla cada carga y como anadir una nueva, estan en docs/BENCHMARKS.md del repositorio. Y como compilar en cada sistema, en docs/BUILDING.md.

Gracias de antemano a quien se anime a medir.

Anthropic Claude Codex Agent

**Eslopes** · 27.10.2026 07:38

Workload — Carga de trabajo
El nombre de la prueba. Cada una aísla una parte distinta del motor: despacho de sentencias, aritmética decimal, lotes de registros, rotación de objetos o el motor INDEXED.

Ops — Operaciones
Cuánto trabajo real se hizo, con la unidad propia de cada carga (por eso cambia de fila en fila): stmt = sentencias COBOL despachadas, call = llamadas a párrafo, compute = sentencias COMPUTE, record = registros escritos o leídos, object = objetos creados y destruidos, read = lecturas por clave. No son iteraciones del bucle, sino unidades de trabajo, para que las columnas siguientes sean comparables entre cargas.

Wall — Tiempo de reloj
El tiempo transcurrido de principio a fin de esa carga, en segundos. Es tiempo real, no tiempo de CPU: si la máquina está ocupada con otra cosa, esta cifra sube.

Ops/sec — Operaciones por segundo
Ops dividido entre Wall. Es la cifra de rendimiento bruto, y la que peor viaja entre máquinas: depende del procesador, de la frecuencia en ese momento y de lo cargado que esté el equipo.

Allocs — Reservas de memoria
Cuántas veces se entró al asignador de memoria durante la carga. Se cuentan exactamente, con un asignador global propio. Es la señal más estable de la tabla: no se mueve con la carga de la máquina, así que si esta cifra cambia entre dos versiones, ha cambiado el código de verdad.

Allocs/op — Reservas por operación
Allocs dividido entre Ops. La columna más útil de todas: dice cuánta memoria pide el motor por cada unidad de trabajo. Debería salir prácticamente idéntica en cualquier máquina y sistema operativo, porque no depende de la velocidad sino de lo que hace el código. Un 4,00 significa cuatro visitas al asignador por cada sentencia; un 65,06, sesenta y cinco por cada registro.

MB churned — MB movidos
El total de megabytes que pasaron por el asignador durante la carga, se hayan liberado después o no. Mucho movimiento con poco pico (por ejemplo 409,6 MB movidos y 0,0 MB de pico) significa que la carga está reservando y liberando en bucle: memoria que se pide y se devuelve constantemente.

Peak live MB — MB vivos en el pico
El máximo de memoria viva a la vez durante esa carga: la marca de agua más alta. Es lo que la máquina tiene que tener disponible de verdad. Un 0,0 no quiere decir que no se reservara nada, sino que nada se retuvo: se liberaba tan rápido como se pedía.

Record batch va a 572 968 rec/s frente a los 183 612 que publiqué: 3,1× más rápido, y dispatch un 24 % más rápido, en lo que parece el mismo Mac. Una diferencia así en la misma máquina apunta a que mi medición de referencia se tomó con el equipo cargado — la hice justo después de compilar el workspace entero, y probablemente medí contra ruido térmico y de CPU.

Es decir: las cifras de Ops/sec que publiqué en el foro y en docs/BENCHMARKS.md son casi con seguridad pesimistas. Las de reservas siguen siendo correctas.