Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nanobench on baremetal #102

Open
hazelnusse opened this issue Nov 16, 2023 · 0 comments
Open

nanobench on baremetal #102

hazelnusse opened this issue Nov 16, 2023 · 0 comments

Comments

@hazelnusse
Copy link

hazelnusse commented Nov 16, 2023

Hi there, thank you for making this library, it is pretty sweet! I'm looking for a micro-bencmarking library that could be used in a bare metal context as well as in a more "normal" context (x86/x86_64 Linux, Arm64 QNX/Linux). I think nanobench is usable as is in the "normal" context but for baremetal use case, there are some questions I have about the present implementation:

  • we need to avoid use of dynamic memory, would you be open to changes that expose the allocator template parameter for the things nanobench presently uses the default allocator for? i.e., std::string, std::vector, std::unordered_map, std::map? This might not be completely sufficient, for example things like the use of a 2 element std::vector in Rng could be implemented instead with a pair/array/struct (though I did see the comment about potentially needing more than 2 elements to represent the state of the Rng).
  • In our use case, string formatting is extremely slow. It would be nice if the measurements could be separated from the string manipulations, and those separated from reporting via iostream. I haven't fully digested the library implementation yet but it seems at a high level, these are the three fundamental operations that need to be done. Any thoughts on how these could be decoupled and/or customized by the user?
  • In the mustache-like rendering, throw is used. We have to build without exceptions. Would you be open to customization of this mechanism for reporting/handling errors? The use is simple enough we could patch to use assert on our platform but perhaps this would be something you'd be open to handling another way, for example std::optional / std::expected (or similar)?
  • Would it be possible to allow for customization by the user for which clock is used?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant