Neil Schemenauer <nas-pyt...@arctrix.com> added the comment:
We now have a concrete use case. ;-) My idea was that we can introduce a new, CPython internal API that aligns on 8-byte boundaries (or takes alignment as a parameter). The API would be a stop-gap measure. We can use the API to reduce the overhead for specific types. E.g. for non-subclasses of float, we know the PyObject structure does not need 16-byte alignment. We don't need a version of "alignof" to know this. Inside floatobject.c, we could call the new objmalloc API that gives new memory with 8-byte alignment. That would save the 33% overhead. E.g. in PyFloat_FromDouble, rather than: PyObject_MALLOC(sizeof(PyFloatObject)) we could call something like: _PyObject_MALLOC_ALIGNED(sizeof(PyFloatObject), 8) This internal API would not be a permanent solution. Having to manually fix each place that PyObjects are allocated and hard-coding the required alignment is not the best solution. We can only fix specific types and extension modules would always get the 16-byte alignment. Still, by tweaking some of the most common types, we avoid much of the overhead for the alignment change, at least for the average Python program. In the long term, we would need a better solution. E.g. an API that can take alignment requirements as a parameter. Or, a solution I like better, have types use PyObject_New(). Then, add an alignment specifier to type object (e.g. tp_align to go along with tp_basicsize). Then there does not have to be a new public API that takes alignment. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue27987> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com