ragged-buffer VS polars

We are also releasing enn-trainer, a PPO implementation that takes full advantage of the Entity Gym interface. Variable-length observations are efficiently processed using ragged sample buffers and a general ragged batch transformer implementation that can be applied to any Entity Gym environment. With many performance optimizations still missing, enn-trainer can already reach a throughput of 10s of thousands of samples per second per GPU when it is not bottlenecked by stepping the environment. More typically, environments implemented in Python reach thousands of samples per second, but can share a single GPU between multiple concurrent training runs.

One of Rust's many strengths is that it can be seamlessly integrated with Python and speed up critical code sections. I recently wrote a small library with an efficient ragged array datatype, and I figured it would make for a good example of how to set up a Rust Python package with PyO3 and maturin that interoperates with numpy. There are a lot of little details that took me quite a while to figure out:

This is because 0.1 is in actuality the floating point value value 0.1000000000000000055511151231257827021181583404541015625, and thus 1 divided by it is ever so slightly smaller than 10. Nevertheless, fpround(1 / fpround(1 / 10)) = 10 exactly.

I found out about this recently because in Polars I defined a // b for floats to be (a / b).floor(), which does return 10 for this computation. Since Python's correctly-rounded division is rather expensive, I chose to stick to this (more context: https://github.com/pola-rs/polars/issues/14596#issuecomment-...).

https://github.com/pola-rs/polars/releases/tag/py-0.19.0

That turned out to be related to pola-rs/polars#11912, and this linked comment provided a deceptively simple solution - use PARSE_DECLTYPES when creating the connection: