Eslopes
28 de julio de 2026, 00:51
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:
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:
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:
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:
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
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:
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:
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:
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:
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