Thanks all for the review & comments. On Mon, Jun 2, 2025 at 4:44 PM Miguel Ojeda <miguel.ojeda.sando...@gmail.com> wrote: > > On Mon, Jun 2, 2025 at 4:32 PM Yury Norov <yury.no...@gmail.com> wrote: > > > > > +const BITMAP_LEN: usize = 4096 * 8 * 10; > > > +// Reciprocal of the fraction of bits that are set in sparse bitmap. > > > +const SPARSENESS: usize = 500; > > > > Is there any simple mechanism to keep C and rust sizes synced? (If no, > > not a big deal to redefine them.) > > One may pick them from C (possibly with a `RUST_HELPER_*` if needed). > If they are non-trivial macros, then using an `enum` instead of a > `#define` on the C side is also an alternative.
I'd prefer not to move these to a header file and define RUST_HELPER and such. I'd prefer if test & benchmark code was somewhat contained (although I agree it would be nice to keep the two definitions in sync). > > What is the name policy for rust? Maybe a more human-readable name > > would work better here? > > Up to the maintainers, and generally the same as for C. In the global > Rust samples and things like that we have `rust` in the name since > they are Rust samples after all, but there is no need to say `rust` or > `module` in actual modules etc. unless there is a reason for it. > > I hope that helps! I renamed the module struct to `Benchmark` now and made the "name" the same as the file name. So the _rust suffix is there because the rust file really corresponds to the C file. In this particular case, I think it does help to see how it relates to the C file. Cheers, - Burak
