Re: [Python-Dev] configure produces a non-working Makefile in some scenarios, due to ASDLGEN
Ned Deily acm.org> writes: > Makefile. You now have the opportunity to override the behavior at > ./configure time by using the PYTHON variable to specify the path to the > Python executable you want to use for the asdl_c.py step, as in: > >./configure ... PYTHON=/usr/bin/python2.7 Aha! Thanks for pointing that out. Regards, Vinay Sajip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] configure produces a non-working Makefile in some scenarios, due to ASDLGEN
Cameron Simpson zip.com.au> writes: > Hoping this is more helpful than I've probably made it sound, Sure. I know my setup was somewhat unusual, which is why I posted here rather than the tracker, but it was a surprise when a long-working configuration suddenly broke because of an unbuilt Python 3.4. Ned's post showed me why. Regards, Vinay Sajip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)
On Sun, Oct 28, 2012 at 3:48 PM, Tim Delaney wrote: > On 28 October 2012 18:22, Stefan Behnel wrote: > >> How much of an >> >>> effect would it have on startup times and these benchmarks if >>> Cython-compiled extensions were used? >>> >> >> Depends on what and how much code you use. If you compile everything into >> one big module that "imports" all of the stdlib when it gets loaded, you'd >> likely loose a lot of time because it would take a while to initialise all >> that useless code on startup. If you keep it separate, it would likely be a >> lot faster because you avoid the interpreter for most of the module startup. >> > > I was specifically thinking in terms of the tests Brett ran (that was the > full set on speed.python.org, wasn't it?), > It's not the full set as not all of them can be run on Python 3, but it is as many as can be run. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)
To see if the bad iterative_count and threaded_count results were consistently bad, I ran the benchmark suite on my MacBook Pro to see how "reliable" the benchmarks were. The output is below. Basically 6 benchmarks (regex_effbot, queens, startup_nosite, iterative_count, threaded_count, and telco) had a variance of more than 15% performance between my 2 computers, although queens, iterative_count, and threaded_count were the only ones that swung between neutral/good to bad depending on the machine (the rest either want from bad to very bad, or very good to more very good). And before Antoine asks, I added a ``sys.modules['markupsafe'] = None` line to the mako_v2 benchmark locally. =) Still need to either explicitly block it or emit a warning in the code in the repo. # Report on Darwin Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64 i386 Total CPU cores: 8 ### 2to3 ### 10.321463 -> 9.525119: 1.08x faster ### call_method ### Min: 0.466812 -> 0.417812: 1.12x faster Avg: 0.483324 -> 0.427158: 1.13x faster Significant (t=28.77) Stddev: 0.01876 -> 0.01483: 1.2644x smaller Timeline: b'http://tinyurl.com/8al5lmm' ### call_method_slots ### Min: 0.484923 -> 0.409452: 1.18x faster Avg: 0.487877 -> 0.413054: 1.18x faster Significant (t=131.11) Stddev: 0.00395 -> 0.00577: 1.4589x larger Timeline: b'http://tinyurl.com/9zhpg6z' ### call_method_unknown ### Min: 0.547050 -> 0.406866: 1.34x faster Avg: 0.550721 -> 0.409359: 1.35x faster Significant (t=328.32) Stddev: 0.00415 -> 0.00325: 1.2795x smaller Timeline: b'http://tinyurl.com/9wxoddz' ### call_simple ### Min: 0.391213 -> 0.332055: 1.18x faster Avg: 0.393563 -> 0.335362: 1.17x faster Significant (t=127.15) Stddev: 0.00363 -> 0.00427: 1.1764x larger Timeline: b'http://tinyurl.com/8mmepzw' ### chameleon ### Min: 0.078505 -> 0.070175: 1.12x faster Avg: 0.083754 -> 0.071500: 1.17x faster Significant (t=2.95) Stddev: 0.05086 -> 0.00119: 42.8425x smaller Timeline: b'http://tinyurl.com/8bz9hpl' ### chaos ### Min: 0.353739 -> 0.423587: 1.20x slower Avg: 0.356297 -> 0.428197: 1.20x slower Significant (t=-108.44) Stddev: 0.00200 -> 0.00424: 2.1147x larger Timeline: b'http://tinyurl.com/98e56le' ### django ### Min: 0.824149 -> 0.862750: 1.05x slower Avg: 0.831614 -> 0.869112: 1.05x slower Significant (t=-21.47) Stddev: 0.01020 -> 0.00697: 1.4634x smaller Timeline: b'http://tinyurl.com/8kz8owv' ### fannkuch ### Min: 1.776913 -> 1.832973: 1.03x slower Avg: 1.793116 -> 1.915348: 1.07x slower Significant (t=-11.57) Stddev: 0.01436 -> 0.07329: 5.1030x larger Timeline: b'http://tinyurl.com/9ptae4z' ### fastpickle ### Min: 0.810968 -> 0.739322: 1.10x faster Avg: 0.818099 -> 0.745148: 1.10x faster Significant (t=58.02) Stddev: 0.00577 -> 0.00677: 1.1731x larger Timeline: b'http://tinyurl.com/8l769dd' ### fastunpickle ### Min: 0.644198 -> 0.659345: 1.02x slower Avg: 0.647976 -> 0.666154: 1.03x slower Significant (t=-18.96) Stddev: 0.00343 -> 0.00584: 1.7020x larger Timeline: b'http://tinyurl.com/93xn7el' ### float ### Min: 0.420888 -> 0.363410: 1.16x faster Avg: 0.432285 -> 0.376179: 1.15x faster Significant (t=38.14) Stddev: 0.00762 -> 0.00708: 1.0766x smaller Timeline: b'http://tinyurl.com/8bjwka9' ### formatted_logging ### Min: 0.325707 -> 0.413196: 1.27x slower Avg: 0.329846 -> 0.418099: 1.27x slower Significant (t=-119.89) Stddev: 0.00397 -> 0.00337: 1.1787x smaller Timeline: b'http://tinyurl.com/8ktbs49' ### genshi ### Min: 0.254604 -> 0.269696: 1.06x slower Avg: 0.258585 -> 0.275615: 1.07x slower Significant (t=-33.39) Stddev: 0.00283 -> 0.00557: 1.9704x larger Timeline: b'http://tinyurl.com/8bqvcwl' ### go ### Min: 0.676453 -> 0.745504: 1.10x slower Avg: 0.681833 -> 0.752170: 1.10x slower Significant (t=-48.67) Stddev: 0.00520 -> 0.00880: 1.6917x larger Timeline: b'http://tinyurl.com/9d6qj3y' ### hexiom2 ### Min: 186.378727 -> 172.939507: 1.08x faster Avg: 186.679821 -> 173.103242: 1.08x faster Significant (t=39.61) Stddev: 0.42581 -> 0.23156: 1.8389x smaller Timeline: b'http://tinyurl.com/9mc3pmg' ### html5lib ### Min: 11.827770 -> 11.239556: 1.05x faster Avg: 11.858253 -> 11.370960: 1.04x faster Significant (t=6.93) Stddev: 0.02825 -> 0.15466: 5.4746x larger Timeline: b'http://tinyurl.com/8vl952y' ### iterative_count ### Min: 0.168182 -> 0.154105: 1.09x faster Avg: 0.169512 -> 0.155952: 1.09x faster Significant (t=50.77) Stddev: 0.00139 -> 0.00128: 1.0899x smaller Timeline: b'http://tinyurl.com/9eymjtf' ### json_dump_v2 ### Min: 3.350528 -> 3.795307: 1.13x slower Avg: 3.369661 -> 3.825400: 1.14x slower Significant (t=-125.93) Stddev: 0.01470 -> 0.02095: 1.4250x larger Timeline: b'http://tinyurl.com/8wyn9qa' ### json_load ### Min: 0.999717 -> 0.607549: 1.65x faster Avg: 1.007319 -> 0.613016: 1.64x faster Significant (t=289.24) Stddev: 0.00673 -> 0.00690: 1.0240x larger Timeline: b'http://tinyurl.com/8qxakdw' ### mako_v2 ### Min: 0.094817 -> 0.279593: 2.95x sl
Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)
On Mon, 29 Oct 2012 09:56:57 -0400 Brett Cannon wrote: > To see if the bad iterative_count and threaded_count results were > consistently bad, I ran the benchmark suite on my MacBook Pro to see how > "reliable" the benchmarks were. The output is below. > > Basically 6 benchmarks (regex_effbot, queens, startup_nosite, > iterative_count, threaded_count, and telco) had a variance of more than 15% > performance between my 2 computers, although queens, iterative_count, and > threaded_count were the only ones that swung between neutral/good to bad > depending on the machine (the rest either want from bad to very bad, or > very good to more very good). This is using different compilers on the 2 computers, right? Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)
On Mon, Oct 29, 2012 at 3:22 PM, Antoine Pitrou wrote: > On Mon, 29 Oct 2012 09:56:57 -0400 > Brett Cannon wrote: > > > To see if the bad iterative_count and threaded_count results were > > consistently bad, I ran the benchmark suite on my MacBook Pro to see how > > "reliable" the benchmarks were. The output is below. > > > > Basically 6 benchmarks (regex_effbot, queens, startup_nosite, > > iterative_count, threaded_count, and telco) had a variance of more than > 15% > > performance between my 2 computers, although queens, iterative_count, and > > threaded_count were the only ones that swung between neutral/good to bad > > depending on the machine (the rest either want from bad to very bad, or > > very good to more very good). > > This is using different compilers on the 2 computers, right? Yes: gcc 4.6.3 on Linux and Clang 3.1 on OS X. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python Bug Day this Saturday announced
Hi everybody, I just sent the announcement for the bug day to python-list (apparently pending approval), core-mentorship and montrealpython. Core developers who plan on being on IRC can add themselves to the list on http://wiki.python.org/moin/PythonBugDay so that people can connect nicknames with people. The list by Petri at http://piratepad.net/pyconfi-sprint-issues can still be updated. Otherwise we’ll fall back to the usual roundup query for easy bugs. Cheers! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
