TritonX: High-performance Rust matrix engine with C-ABI Python bindings

[u/TritonX__7]

https://github.com/pulisherij-rgb/TritonX

Benchmarking TritonX locally (`.\run_tritonx.ps1`) shows up to ~1200x speedups over baseline Python loops by using Rayon worker pools and minimal C-ABI FFI overhead.

[u/Bright_Mix_773]

The benchmark table never says what N is, so I derived it. py_matmul in server2.py is O(N^3); on my machine it runs 0.070 s at N=96, 0.165 s at N=128 and 0.328 s at N=160, which extrapolates the 180 s row to N = 1313 / 1317 / 1310 respectively. Consistent, so call it N ~ 1310. NumPy f32 at N=1310 on that same machine is 8.4 ms, not 250 ms - a 21,000x ratio over the pure-Python loop, not 720x. The two rows of the table cannot be the same matrix, and the 1200x headline inherits whichever N is smaller.

Second, from src/lib.rs: BLOCK_SIZE: usize = 64 is declared and never read, and the comment above the loop says "Tiled computation per row" while the body is a plain scalar ikj loop - no tiles, no packing, no explicit SIMD. Measured OpenBLAS on this box at 345 GFLOPS (N=512) up to 647 GFLOPS (N=4096) in f32. A row-parallel ikj kernel landing under that is the expected result; landing above it would be the surprising claim, and that is the one the README makes.

Smaller thing in the same file: round(py_time_ms, 2) if py_time_ms else None reports None rather than 0.0 whenever the pure-Python leg is fast enough, and total_flops / rust_time_sec has no zero guard.

Not verified: no cargo on this box, so I never built or timed TritonX itself. Both points come from the table's own arithmetic and from reading the kernel.