add PyMemRawAllocator - #6279
Conversation
| // CPython documents this alignment as `ALIGNOF_MAX_ALIGN_T` | ||
| // (8 on Windows; autoconf-derived on Unix, not guaranteed >8 on every target/libc). | ||
| const MAX_ALIGN: usize = 8; |
There was a problem hiding this comment.
I think this worth double-checking
@anuraaga's implementation included the following:
/// Alignment the raw allocator provides on its own (that of `max_align_t`).
const RAW_ALIGN: usize = if size_of::<usize>() >= 8 { 16 } else { 8 };There was a problem hiding this comment.
418a0a9bacce8fe2ccc5fabd1be1ef077dcff7df last commit for 3.15 branch
802a2c8b7a91d700c8bf342a27cd096ac444af41 last commit for 3.14 branch
3.15
Windows:
-
MS_WIN64- ALIGNOF_MAX_ALIGN_T 8 -
MS_WIN32- ALIGNOF_MAX_ALIGN_T 8
Unix
cpython/pyconfig.h.in- Filled in by autoconf
MacOS
-
Intel (
__i386__/__x86_64__) - ALIGNOF_MAX_ALIGN_T 16 -
non-Intel (including Apple Silicon
arm64) - ALIGNOF_MAX_ALIGN_T 8
Fallback
// Make sure we have maximum alignment, even if the current compiler
// does not support max_align_t. Note that:
// - Autoconf reports alignment of unknown types to 0.
// - 'long double' has maximum alignment on *most* platforms,
// looks like the best we can do for pre-C11 compilers.
// - The value is tested, see test_alignof_max_align_t
#if !defined(ALIGNOF_MAX_ALIGN_T) || ALIGNOF_MAX_ALIGN_T == 0
# undef ALIGNOF_MAX_ALIGN_T
# define ALIGNOF_MAX_ALIGN_T _Alignof(long double)
#endif3.14
Windows:
-
MS_WIN64- ALIGNOF_MAX_ALIGN_T 8 -
MS_WIN32- ALIGNOF_MAX_ALIGN_T 8
Unix
cpython/pyconfig.h.in- Filled in by autoconf
MacOS
-
Intel (
__i386__/__x86_64__) - ALIGNOF_MAX_ALIGN_T 16 -
non-Intel (including Apple Silicon
arm64) - ALIGNOF_MAX_ALIGN_T 8
Fallback
// Make sure we have maximum alignment, even if the current compiler
// does not support max_align_t. Note that:
// - Autoconf reports alignment of unknown types to 0.
// - 'long double' has maximum alignment on *most* platforms,
// looks like the best we can do for pre-C11 compilers.
// - The value is tested, see test_alignof_max_align_t
#if !defined(ALIGNOF_MAX_ALIGN_T) || ALIGNOF_MAX_ALIGN_T == 0
# undef ALIGNOF_MAX_ALIGN_T
# define ALIGNOF_MAX_ALIGN_T _Alignof(long double)
#endif
|
I don't think this needs to be gated behind a feature. Typically we only use features if we can gate some compile time cost behind it, like a dependency or proc macros. |
| extern_libpython! { | ||
| #[cfg_attr(PyPy, link_name = "PyPyMem_RawMalloc")] | ||
| pub fn PyMem_RawMalloc(size: size_t) -> *mut c_void; | ||
| #[cfg_attr(PyPy, link_name = "PyPyMem_RawCalloc")] | ||
| pub fn PyMem_RawCalloc(nelem: size_t, elsize: size_t) -> *mut c_void; | ||
| #[cfg_attr(PyPy, link_name = "PyPyMem_RawRealloc")] | ||
| pub fn PyMem_RawRealloc(ptr: *mut c_void, new_size: size_t) -> *mut c_void; | ||
| #[cfg_attr(PyPy, link_name = "PyPyMem_RawFree")] | ||
| pub fn PyMem_RawFree(ptr: *mut c_void); | ||
|
|
||
| // skipped _PyMem_GetCurrentAllocatorName | ||
| // skipped _PyMem_RawStrdup | ||
| // skipped _PyMem_Strdup | ||
| // skipped _PyMem_RawWcsdup | ||
| } | ||
|
|
There was a problem hiding this comment.
| // skipped PyMem_Del | ||
| // skipped PyMem_DEL | ||
|
|
||
| #[cfg_attr(PyPy, link_name = "PyPyMem_RawMalloc")] |
There was a problem hiding this comment.
Merging this PR will degrade performance by 10.24%
|
| Mode | Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|---|
| ❌ | Simulation | bench_fast |
6.1 µs | 6.8 µs | -10.24% |
Tip
Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.
Comparing chirizxc:pymem-raw-alloc (5068b35) with main (92e47e1)
2 participants
Closes #6268
Based on https://github.com/bufbuild/protobuf-py/pull/46/changes#diff-d860a3c1b220287bc41b2a02c7830aab1867404d09509c63d4c7cf07bab2f7a5 (@anuraaga)