C only versions of the aligned allocator? #2

Activity

1. hmaarrfk commented on Nov 29, 2022

   

   hmaarrfk

   on Nov 29, 2022

   Author

   More actions

   I think I also feel like the examples you provided in the tests are really solid! Maybe you could include those in the distribution?
2. eliaskoromilas commented on Nov 29, 2022

   

   eliaskoromilas

   on Nov 29, 2022

   Contributor

   More actions

   The examples you have are really powerful. I just wish they didn't require acquiring the GIL to use ;).

   I agree, for example debug_allocator really comes in handy when I optimize NumPy code (helps me spot unnecessary memory allocations and copies). These examples are there for demonstration purposes, mostly. For production, I also use the part of the API that avoids Python callbacks.

   Would you accept PRs here for predefined allactors, or do you consider this "out of scope" for this project?

   I think it would make more sense to have a dedicated project (e.g. numpy-allocators) to host various NumPy Allocator implementations, and definitely accept PRs from the community.

   I think I also feel like the examples you provided in the tests are really solid! Maybe you could include those in the distribution?

   We could include them in the binary distributions, but I'm more in favor of an optimized NumPy Allocator Collection project with support for every platform. The current aligned_allocator uses GNU memalign which is not available in MacOS and Windows, in a dedicated project we would make sure that everything works as expected on every supported platform.

   Let's keep this issue open to track these actions.
3. hmaarrfk commented on Nov 30, 2022

   

   hmaarrfk

   on Nov 30, 2022

   Author

   More actions

   I understand your desire to keep this focused on making it easy to create these kinds of python objects.

   I do worry about the suggested name for the new library:

   import numpy_allocator
   import numpy_allocators
   

   is really easy to get confused with.
4. eliaskoromilas commented on Nov 30, 2022

   

   eliaskoromilas

   on Nov 30, 2022

   Contributor

   More actions

   This new project (regardless of it's name) may still use the numpy_allocator namespace, e.g.:

   from numpy_allocator.collection import page_aligned_allocator

   I understand your desire to keep this focused on making it easy to create these kinds of python objects.

   My concern is that users will end up with unnecessary code/dependencies.

   I had this idea to implement NumPy Allocators for several custom "malloc" implementations, e.g. mi_allocator after mimalloc, tc_allocator after tcmalloc, je_allocator after jemalloc, etc. and my plan was to publish them as separate projects that depend on this one. I think this is the best approach if you want to keep everyone happy.
5. hmaarrfk commented on Nov 30, 2022

   

   hmaarrfk

   on Nov 30, 2022

   Last edited by hmaarrfk

   Author

   More actions

   Dependency management is a real concern.

   This new project (regardless of it's name) may still use the numpy_allocator namespace, e.g.:

   Ah i see. Yeah, i've never packaged things that way before. I think it is possible with

   so maybe the packages become something like

   • numpy-allocator-mimalloc
   • numpy-allocator-tcmalloc
   • numpy-allocator-page-aligned

   etc.

   I guess i'll have to look into it. My general feeling is that your context managers are tremendously useful to debug and to prototype things with! Thank you for that!

   👍React with 👍1Reacted by Elias Koromilas