Message215344
Just as an experiment (using the 3.4 branch and the Xcode 5.1 clang), the list of unique symbols not found during the test dlopen in setup.py when using -flto:
_PyArg_ParseTuple
_PyArg_ParseTupleAndKeywords
_PyBaseObject_Type
_PyBool_Type
_PyByteArray_Type
_PyBytes_Type
_PyCFunction_Type
_PyExc_AssertionError
_PyExc_BufferError
_PyExc_EOFError
_PyExc_IndexError
_PyExc_IOError
_PyExc_KeyError
_PyExc_LookupError
_PyExc_MemoryError
_PyExc_NotImplementedError
_PyExc_OSError
_PyExc_OverflowError
_PyExc_RuntimeError
_PyExc_TypeError
_PyExc_ValueError
_PyModule_Create2
__Py_NoneStruct
Anyone see a pattern there?
Do we know if anyone has tried to use LTO with a Python build previously? I've never tried it myself and there certainly could be ld and/or dyld differences on OS X. Also, some thought would need to go into and tests developed to see what the performance trade-offs are. For example, I could imagine that LTO might be have more impact if the standard library extension modules were statically linked, e.g. via Modules/Setup*. And there are at least three separate current build configurations to consider on OS X: unshared, --enable-shared, --enable-framework. One would need to look at things like what effect these all have on memory and shared memory footprints as well as cpu resources and real time, with and without LTO and/or other optimizations. It certainly would be an interesting project for someone with the interest and time.
Potentially supporting LTO seems to me to be more of a feature than a bug so I think should be considered a 3.5 issue, at least initially. |
|
Date |
User |
Action |
Args |
2014-04-01 22:33:52 | ned.deily | set | recipients:
+ ned.deily, brett.cannon, ronaldoussoren, vstinner, koobs, Sjlver |
2014-04-01 22:33:52 | ned.deily | set | messageid: <1396391632.16.0.846087381392.issue21122@psf.upfronthosting.co.za> |
2014-04-01 22:33:52 | ned.deily | link | issue21122 messages |
2014-04-01 22:33:51 | ned.deily | create | |
|