Amaury Forgeot d'Arc wrote:
> Guido van Rossum:
>> I just changed PEP 3137 to rename the mutable bytes type 'bytearray'
>> instead of 'buffer', and implemented this change in the py3k branch.
>>
>> A lot of code in the Py3k branch still returns PyBytes instances
>> (i.e., bytearray) where it should
Christian Heimes wrote:
> A lot of functions in Python 3.x have blocks like
>
> if (PyString_Check(sub_obj)) {
> sub = PyString_AS_STRING(sub_obj);
> sub_len = PyString_GET_SIZE(sub_obj);
> }
> else if (PyObject_AsCharBuffer(sub_obj, &sub, &su
This morning I've fixed the PGO builds of PCbuild9 and compared a PGO
build with a vanilla build. The PGO builds is about 10% faster. I've
used a PyBench and an unit test run as profiling data.
Christian
---
PYBENCH 2.0 (
Amaury Forgeot d'Arc wrote:
> Could this code replace the current PyString_AsStringAndSize, instead
> of creating a new function?
I guess it could. But it's a naming question. The method is more general
and takes more than just instances of PyString and its subclasses.
Therefor I think it should b
Martin v. Löwis wrote:
> I would be opposed unless a complete automation of that is possible and
> can be contributed. For AMD64, I see little hope for that, as I build
> the releases in a cross-compilation environment, so I can't run them
> on the build machine.
Done ;)
I've modified the PGO buil
Christian Heimes schrieb:
> Martin v. Löwis wrote:
>> I would be opposed unless a complete automation of that is possible and
>> can be contributed. For AMD64, I see little hope for that, as I build
>> the releases in a cross-compilation environment, so I can't run them
>> on the build machine.
>
Boris Borcic wrote:
> FWIW back in march Giovanni Bajo said on mingw-users that GCC-4.x optimized
> his
> code base better than MSVC; that was in
>
> http://article.gmane.org/gmane.comp.gnu.mingw.user/21964/
>
> Now there has been an official "technology preview" release of MingW
> gcc-4.2.1
Gregory P. Smith wrote:
> I would not hold up a compiler decision based on the mingw project.
> Always use the latest MS compiler released at the time for a x.0 build
> of any python. Doing otherwise costs the world a fortune in lost
> performance (higher power consumption via lower efficiency
Martin v. Löwis wrote:
> So what's the build process? Is it
>
> 1. start a VS build environment shell
> 2. cd to PCbuild9
> 3. run "build_pgo"
>
> Any additional steps? Should I pass arguments? Can you kindly document
> it in readme.txt?
Yes, you can either use the build_pgo.bat in the PCbuild9
> I've modified the PGO builds and the build_pgo batch file I copied from
> the PCbuild8 directory. For AMD64 builds we either have to buy you an
> AMD64 processor or somebody else has to run the PGI and PGO builds.
So what's the build process? Is it
1. start a VS build environment shell
2. cd to
> Job for the win64 buildbot, maybe?
Is it possible to share the profile data across machines?
I would certainly want to build and test the releases on
my own machines, rather than having to rely on a buildbot.
I then rather do a multi-reboot thing where I build the AMD64
profiling binaries, reboo
> A word of warning. The PGInstrument builds are *very* slow compared to
> normal builds. The bench mark and test suite need about *TEN* times the
> time to run.
That's also an issue - releases typically occur under time pressure,
trying to get everything done in a single day. If I prepare the
ins
Martin v. Löwis wrote:
> That's also an issue - releases typically occur under time pressure,
> trying to get everything done in a single day. If I prepare the
> instrument build in advance, how long can I continue to use the data
> before they get outdated?
Good point! I've chosen PGUpdate over P
On 21/11/2007, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 21/11/2007, Christian Heimes <[EMAIL PROTECTED]> wrote:
> > Paul Moore wrote:
> > > Cool. I'm downloading now, and will report back.
> >
> > How is it going? Does the PCbuild9 directory work with the final version
> > of VS C++ Express?
>
>
Paul Moore wrote:
> Python itself seems to build with no problems at all (there was a
> mention of "Solution folders" not being supported in Express Edition,
> but that doesn't seem to stop anything I need to do to build.
>
> Most of the extensions built fine, and the test suite went through
> wit
Amaury Forgeot d'Arc wrote:
> Now, is it really necessary to install perl in order to compile python?
> I managed to avoid it until today :-(
*snip*
I've modified the build_ssl.py script and added pre-generated makefiles
and assembly files to openssl today. From now on you can build Python
w/o Per
16 matches
Mail list logo
