On 11/21/11 12:21, Norm Jacobs wrote:
Your changes seem ok to me, though I have a couple of questions.
1. I thought that I read somewhere, either in the bug report or an
email thread, that simply building with gcc gave us an additional,
non-trivial performance improvement. If that is the case, should we
be considering using gcc instead of Studio here?
I was never able to build Python 2.6 successfully with gcc; just Python
2.7. If I recall correctly, I encountered some linking errors with
isfinite, isinf. Wasn't familiar with that particular failure case and
couldn't find how to fix it, so didn't pursue that for Python 2.6.
I also thought the preference was to stick with the CBE compiler,
especially given that later versions of gcc result in lackluster SPARC
performance for builds.
As for simply recompiling with gcc instead, to be fair, simply upgrading
our CBE compiler to Studio 12.3 would give us a nice boost as well
although not quite as great as simply using gcc.
The largest boost definitely comes from a profile-guided build whether
using gcc or Studio.
For grins I went back and rebuilt Python 2.7 with gcc using a
profile-guided build and then compared that to my build. According to
pybench, a gcc profile-guided build of Python 2.7 32-bit is about 2.8%
faster, and for Python 2.7 64-bit 4.3% faster than a Studio equivalent
build. Given the small difference, I thought it was better to stick
with Studio, especially since I believe compiling with Studio 12.3
actually eliminates that difference.
2. Did you go back and build any packages from Userland or other
consolidations with your changed packages installed? I ask because
compiler and linker flag changes can end up squirreled away and show
up later when you build modules with your bits. This was a problem
in the past in cases where the module builds with gcc and Studio
options from the Python build leaked into the flags.
I have, although there appears to be a pre-existing issue there already
unrelated to my changes. Notably, config/Makefile in /usr/lib/python2.6
has -KPIC in CCSHARED, which isn't valid for gcc. It ends up working
anyway because the pycc script adds -fPIC -DPIC, but you do get
unrecognised option warnings from gcc.
As far as I can tell, this doesn't cause any regressions in this area.
I'm able to compile python C modules when CC is set to gcc, etc.
-Shawn
_______________________________________________
userland-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/userland-discuss
