From fijall at gmail.com Fri Jul 13 04:03:53 2012 From: fijall at gmail.com (Maciej Fijalkowski) Date: Fri, 13 Jul 2012 04:03:53 +0200 Subject: [Speed] more space on speed.python.org Message-ID: Hi who do I contact to beg for more than 20G of space on speed? I'm sure there is more unused, because you simply cannot buy such small drives these days. Cheers, fijal -------------- next part -------------- An HTML attachment was scrubbed... URL: From noah at coderanger.net Fri Jul 13 04:08:12 2012 From: noah at coderanger.net (Noah Kantrowitz) Date: Thu, 12 Jul 2012 19:08:12 -0700 Subject: [Speed] more space on speed.python.org In-Reply-To: References: Message-ID: <9DC1DCBF-E123-42EF-B04D-CA135749F882@coderanger.net> On Jul 12, 2012, at 7:03 PM, Maciej Fijalkowski wrote: > Hi > > who do I contact to beg for more than 20G of space on speed? I'm sure there is more unused, because you simply cannot buy such small drives these days. Hmm, odd, let me take a look. --Noah -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From noah at coderanger.net Fri Jul 13 04:11:08 2012 From: noah at coderanger.net (Noah Kantrowitz) Date: Thu, 12 Jul 2012 19:11:08 -0700 Subject: [Speed] more space on speed.python.org In-Reply-To: <9DC1DCBF-E123-42EF-B04D-CA135749F882@coderanger.net> References: <9DC1DCBF-E123-42EF-B04D-CA135749F882@coderanger.net> Message-ID: <29FCBFE2-EB90-45FC-A48E-189644D99B8F@coderanger.net> On Jul 12, 2012, at 7:08 PM, Noah Kantrowitz wrote: > > On Jul 12, 2012, at 7:03 PM, Maciej Fijalkowski wrote: > >> Hi >> >> who do I contact to beg for more than 20G of space on speed? I'm sure there is more unused, because you simply cannot buy such small drives these days. > > Hmm, odd, let me take a look. Aha, there it is, 1.06TB unallocated in the LVM group. Where do you want me to mount the new partition and how big do you want it? --Noah -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jnoller at gmail.com Fri Jul 13 04:12:13 2012 From: jnoller at gmail.com (Jesse Noller) Date: Thu, 12 Jul 2012 22:12:13 -0400 Subject: [Speed] more space on speed.python.org In-Reply-To: <9DC1DCBF-E123-42EF-B04D-CA135749F882@coderanger.net> References: <9DC1DCBF-E123-42EF-B04D-CA135749F882@coderanger.net> Message-ID: <44D3734B-964B-4C5A-8770-95C96E2CE9B4@gmail.com> There's more than 20gb there. Run df an you can see the partition layout Lance helped us setup On Jul 12, 2012, at 10:08 PM, Noah Kantrowitz wrote: > > On Jul 12, 2012, at 7:03 PM, Maciej Fijalkowski wrote: > >> Hi >> >> who do I contact to beg for more than 20G of space on speed? I'm sure there is more unused, because you simply cannot buy such small drives these days. > > Hmm, odd, let me take a look. > > --Noah > > _______________________________________________ > Speed mailing list > Speed at python.org > http://mail.python.org/mailman/listinfo/speed From fijall at gmail.com Fri Jul 13 10:29:48 2012 From: fijall at gmail.com (Maciej Fijalkowski) Date: Fri, 13 Jul 2012 10:29:48 +0200 Subject: [Speed] more space on speed.python.org In-Reply-To: <44D3734B-964B-4C5A-8770-95C96E2CE9B4@gmail.com> References: <9DC1DCBF-E123-42EF-B04D-CA135749F882@coderanger.net> <44D3734B-964B-4C5A-8770-95C96E2CE9B4@gmail.com> Message-ID: On Fri, Jul 13, 2012 at 4:12 AM, Jesse Noller wrote: > There's more than 20gb there. Run df an you can see the partition layout > Lance helped us setup > > On Jul 12, 2012, at 10:08 PM, Noah Kantrowitz wrote: > > > > > On Jul 12, 2012, at 7:03 PM, Maciej Fijalkowski wrote: > > > >> Hi > >> > >> who do I contact to beg for more than 20G of space on speed? I'm sure > there is more unused, because you simply cannot buy such small drives these > days. > > > > Hmm, odd, let me take a look. > > > > --Noah > > > > _______________________________________________ > > Speed mailing list > > Speed at python.org > > http://mail.python.org/mailman/listinfo/speed > Hi Jesse /dev/sda2 19G 16G 1.8G 90% / none 7.9G 196K 7.9G 1% /dev none 7.9G 0 7.9G 0% /dev/shm none 7.9G 56K 7.9G 1% /var/run none 7.9G 0 7.9G 0% /var/lock /dev/sda1 184M 29M 147M 17% /boot I can be enlighntened on the special (none) stuff, but to me it looks like 19G on / and 184M on /boot Noah - I'm afraid "everywhere" is the answer :( I need more space in /home, /tmp and /usr Cheers, faijl -------------- next part -------------- An HTML attachment was scrubbed... URL: From noah at coderanger.net Fri Jul 13 10:41:30 2012 From: noah at coderanger.net (Noah Kantrowitz) Date: Fri, 13 Jul 2012 01:41:30 -0700 Subject: [Speed] more space on speed.python.org In-Reply-To: References: <9DC1DCBF-E123-42EF-B04D-CA135749F882@coderanger.net> <44D3734B-964B-4C5A-8770-95C96E2CE9B4@gmail.com> Message-ID: <03b40bf6-2a58-43f1-927b-cd8d8c2cc72c@email.android.com> Hmm, that might require some surgery, but I'll see what I can do tomorrow. --Noah Maciej Fijalkowski wrote: On Fri, Jul 13, 2012 at 4:12 AM, Jesse Noller wrote: There's more than 20gb there. Run df an you can see the partition layout Lance helped us setup On Jul 12, 2012, at 10:08 PM, Noah Kantrowitz wrote: > > On Jul 12, 2012, at 7:03 PM, Maciej Fijalkowski wrote: > >> Hi >> >> who do I contact to beg for more than 20G of space on speed? I'm sure there is more unused, because you simply cannot buy such small drives these days. > > Hmm, odd, let me take a look. > > --Noah > > _______________________________________________ > Speed mailing list > Speed at python.org > http://mail.python.org/mailman/listinfo/speed Hi Jesse /dev/sda2 19G 16G 1.8G 90% / none 7.9G 196K 7.9G 1% /dev none 7.9G 0 7.9G 0% /dev/shm none 7.9G 56K 7.9G 1% /var/run none 7.9G 0 7.9G 0% /var/lock /dev/sda1 184M 29M 147M 17% /boot I can be enlighntened on the special (none) stuff, but to me it looks like 19G on / and 184M on /boot Noah - I'm afraid "everywhere" is the answer :( I need more space in /home, /tmp and /usr Cheers, faijl -------------- next part -------------- An HTML attachment was scrubbed... URL: From fijall at gmail.com Fri Jul 13 11:40:57 2012 From: fijall at gmail.com (Maciej Fijalkowski) Date: Fri, 13 Jul 2012 11:40:57 +0200 Subject: [Speed] more space on speed.python.org In-Reply-To: <03b40bf6-2a58-43f1-927b-cd8d8c2cc72c@email.android.com> References: <9DC1DCBF-E123-42EF-B04D-CA135749F882@coderanger.net> <44D3734B-964B-4C5A-8770-95C96E2CE9B4@gmail.com> <03b40bf6-2a58-43f1-927b-cd8d8c2cc72c@email.android.com> Message-ID: On Fri, Jul 13, 2012 at 10:41 AM, Noah Kantrowitz wrote: > ** Hmm, that might require some surgery, but I'll see what I can do > tomorrow. > > --Noah Thanks Noah. I hope you understand why just having a partition /blah won't help :) > > > Maciej Fijalkowski wrote: >> >> On Fri, Jul 13, 2012 at 4:12 AM, Jesse Noller wrote: >> >>> There's more than 20gb there. Run df an you can see the partition layout >>> Lance helped us setup >>> >>> On Jul 12, 2012, at 10:08 PM, Noah Kantrowitz >>> wrote: >>> >>> > >>> > On Jul 12, 2012, at 7:03 PM, Maciej Fijalkowski wrote: >>> > >>> >> Hi >>> >> >>> >> who do I contact to beg for more than 20G of space on speed? I'm sure >>> there is more unused, because you simply cannot buy such small drives these >>> days. >>> > >>> > Hmm, odd, let me take a look. >>> > >>> > --Noah >>> > >>> > _______________________________________________ >>> > Speed mailing list >>> > Speed at python.org >>> > http://mail.python.org/mailman/listinfo/speed >>> >> >> Hi Jesse >> >> /dev/sda2 19G 16G 1.8G 90% / >> none 7.9G 196K 7.9G 1% /dev >> none 7.9G 0 7.9G 0% /dev/shm >> none 7.9G 56K 7.9G 1% /var/run >> none 7.9G 0 7.9G 0% /var/lock >> /dev/sda1 184M 29M 147M 17% /boot >> >> I can be enlighntened on the special (none) stuff, but to me it looks >> like 19G on / and 184M on /boot >> >> Noah - I'm afraid "everywhere" is the answer :( I need more space in >> /home, /tmp and /usr >> >> Cheers, >> faijl >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Mon Jul 23 19:59:52 2012 From: brett at python.org (Brett Cannon) Date: Mon, 23 Jul 2012 13:59:52 -0400 Subject: [Speed] merging PyPy and Python benchmark suite Message-ID: For my keynotes at PyCon Argentina and Brasil I'm going to be talking about Python 3.3 and trying to sell it to Python 2.7 users. That means selling the performance numbers of Python 3.3 as acceptable for Python 2.7 users. Since that means using the benchmark suite I might as well start work on merging https://bitbucket.org/pypy/benchmarks/ and http://hg.python.org/benchmarks so we can host the canonical benchmarks at hg.python.org like we have discussed previously (along with coming up with a way to run the benchmarks against Python 2.7 and 3.3 for comparison and making more tests work in Python 3). So, to start, I want to remove the divergence of the Unladen benchmarks (after that we can look at adding in any tests that are unique to PyPy). Am I right in thinking that all forked tests that came from Unladen ended up in PyPy's own directory under the same name (e.g. bm_mako.py)? From stefan_ml at behnel.de Mon Jul 23 20:33:20 2012 From: stefan_ml at behnel.de (Stefan Behnel) Date: Mon, 23 Jul 2012 20:33:20 +0200 Subject: [Speed] merging PyPy and Python benchmark suite In-Reply-To: References: Message-ID: <500D98F0.4080007@behnel.de> Brett Cannon, 23.07.2012 19:59: > For my keynotes at PyCon Argentina and Brasil I'm going to be talking > about Python 3.3 and trying to sell it to Python 2.7 users. That means > selling the performance numbers of Python 3.3 as acceptable for Python > 2.7 users. Since that means using the benchmark suite I might as well > start work on merging https://bitbucket.org/pypy/benchmarks/ and > http://hg.python.org/benchmarks so we can host the canonical > benchmarks at hg.python.org like we have discussed previously (along > with coming up with a way to run the benchmarks against Python 2.7 and > 3.3 for comparison and making more tests work in Python 3). > > So, to start, I want to remove the divergence of the Unladen > benchmarks (after that we can look at adding in any tests that are > unique to PyPy). Am I right in thinking that all forked tests that > came from Unladen ended up in PyPy's own directory under the same name > (e.g. bm_mako.py)? AFAICT, the only difference is the "ai" benchmark, which is otherwise known as "nqueens". Stefan From solipsis at pitrou.net Mon Jul 23 21:10:54 2012 From: solipsis at pitrou.net (Antoine Pitrou) Date: Mon, 23 Jul 2012 21:10:54 +0200 Subject: [Speed] pathlib benchmark? Message-ID: <20120723211054.1c7e49dd@pitrou.net> Hello, I have a small library named pathlib (*) and I think it may be a good candidate for a small benchmark since: - it doesn't have any dependencies - it doesn't need installing (the module is a single .py file) - it supports Python 2.7 and Python 3.2+ in the same code base I was thinking of a simple benchmark such as listing the entries of a given directory (prepared by the benchmark), or perhaps globbing for a specific file pattern. What do you think? (*) http://pathlib.readthedocs.org/en/latest/ Regards Antoine. -- Software development and contracting: http://pro.pitrou.net From alex.gaynor at gmail.com Mon Jul 23 21:47:27 2012 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Mon, 23 Jul 2012 12:47:27 -0700 Subject: [Speed] pathlib benchmark? In-Reply-To: <20120723211054.1c7e49dd@pitrou.net> References: <20120723211054.1c7e49dd@pitrou.net> Message-ID: On Mon, Jul 23, 2012 at 12:10 PM, Antoine Pitrou wrote: > > Hello, > > I have a small library named pathlib (*) and I think it may be a good > candidate for a small benchmark since: > - it doesn't have any dependencies > - it doesn't need installing (the module is a single .py file) > - it supports Python 2.7 and Python 3.2+ in the same code base > > I was thinking of a simple benchmark such as listing the entries of a > given directory (prepared by the benchmark), or perhaps globbing for a > specific file pattern. > > What do you think? > > (*) http://pathlib.readthedocs.org/en/latest/ > > Regards > > Antoine. > > > -- > Software development and contracting: http://pro.pitrou.net > > > _______________________________________________ > Speed mailing list > Speed at python.org > http://mail.python.org/mailman/listinfo/speed > Sounds like a reasonable idea to me. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Mon Jul 23 21:48:42 2012 From: brett at python.org (Brett Cannon) Date: Mon, 23 Jul 2012 15:48:42 -0400 Subject: [Speed] merging PyPy and Python benchmark suite In-Reply-To: <500D98F0.4080007@behnel.de> References: <500D98F0.4080007@behnel.de> Message-ID: On Mon, Jul 23, 2012 at 2:33 PM, Stefan Behnel wrote: > Brett Cannon, 23.07.2012 19:59: >> For my keynotes at PyCon Argentina and Brasil I'm going to be talking >> about Python 3.3 and trying to sell it to Python 2.7 users. That means >> selling the performance numbers of Python 3.3 as acceptable for Python >> 2.7 users. Since that means using the benchmark suite I might as well >> start work on merging https://bitbucket.org/pypy/benchmarks/ and >> http://hg.python.org/benchmarks so we can host the canonical >> benchmarks at hg.python.org like we have discussed previously (along >> with coming up with a way to run the benchmarks against Python 2.7 and >> 3.3 for comparison and making more tests work in Python 3). >> >> So, to start, I want to remove the divergence of the Unladen >> benchmarks (after that we can look at adding in any tests that are >> unique to PyPy). Am I right in thinking that all forked tests that >> came from Unladen ended up in PyPy's own directory under the same name >> (e.g. bm_mako.py)? > > AFAICT, the only difference is the "ai" benchmark, which is otherwise known > as "nqueens". That can't be true as bm_mako.py itself is different: compare http://hg.python.org/benchmarks/file/5f6b46d86b40/performance/bm_mako.py to https://bitbucket.org/pypy/benchmarks/src/ff7b35837d0f/own/bm_mako.py From brett at python.org Mon Jul 23 21:50:31 2012 From: brett at python.org (Brett Cannon) Date: Mon, 23 Jul 2012 15:50:31 -0400 Subject: [Speed] pathlib benchmark? In-Reply-To: References: <20120723211054.1c7e49dd@pitrou.net> Message-ID: On Mon, Jul 23, 2012 at 3:47 PM, Alex Gaynor wrote: > > > On Mon, Jul 23, 2012 at 12:10 PM, Antoine Pitrou > wrote: >> >> >> Hello, >> >> I have a small library named pathlib (*) and I think it may be a good >> candidate for a small benchmark since: >> - it doesn't have any dependencies >> - it doesn't need installing (the module is a single .py file) >> - it supports Python 2.7 and Python 3.2+ in the same code base >> >> I was thinking of a simple benchmark such as listing the entries of a >> given directory (prepared by the benchmark), or perhaps globbing for a >> specific file pattern. >> >> What do you think? >> >> (*) http://pathlib.readthedocs.org/en/latest/ >> >> Regards >> >> Antoine. >> >> >> -- >> Software development and contracting: http://pro.pitrou.net >> >> >> _______________________________________________ >> Speed mailing list >> Speed at python.org >> http://mail.python.org/mailman/listinfo/speed > > > Sounds like a reasonable idea to me. Same here, especially if it can include Unicode path stuff. From stefan_ml at behnel.de Mon Jul 23 22:09:59 2012 From: stefan_ml at behnel.de (Stefan Behnel) Date: Mon, 23 Jul 2012 22:09:59 +0200 Subject: [Speed] merging PyPy and Python benchmark suite In-Reply-To: References: <500D98F0.4080007@behnel.de> Message-ID: <500DAF97.6080905@behnel.de> Brett Cannon, 23.07.2012 21:48: > On Mon, Jul 23, 2012 at 2:33 PM, Stefan Behnel wrote: >> Brett Cannon, 23.07.2012 19:59: >>> For my keynotes at PyCon Argentina and Brasil I'm going to be talking >>> about Python 3.3 and trying to sell it to Python 2.7 users. That means >>> selling the performance numbers of Python 3.3 as acceptable for Python >>> 2.7 users. Since that means using the benchmark suite I might as well >>> start work on merging https://bitbucket.org/pypy/benchmarks/ and >>> http://hg.python.org/benchmarks so we can host the canonical >>> benchmarks at hg.python.org like we have discussed previously (along >>> with coming up with a way to run the benchmarks against Python 2.7 and >>> 3.3 for comparison and making more tests work in Python 3). >>> >>> So, to start, I want to remove the divergence of the Unladen >>> benchmarks (after that we can look at adding in any tests that are >>> unique to PyPy). Am I right in thinking that all forked tests that >>> came from Unladen ended up in PyPy's own directory under the same name >>> (e.g. bm_mako.py)? >> >> AFAICT, the only difference is the "ai" benchmark, which is otherwise known >> as "nqueens". > > That can't be true as bm_mako.py itself is different: compare > http://hg.python.org/benchmarks/file/5f6b46d86b40/performance/bm_mako.py > to https://bitbucket.org/pypy/benchmarks/src/ff7b35837d0f/own/bm_mako.py I meant "different" as in "differently named". The specific tests have certainly received some (minor) adaptations on both sides, be it for porting them to Py3 or for making them more appropriate for PyPy. Stefan From brett at python.org Mon Jul 23 22:15:43 2012 From: brett at python.org (Brett Cannon) Date: Mon, 23 Jul 2012 16:15:43 -0400 Subject: [Speed] merging PyPy and Python benchmark suite In-Reply-To: <500DAF97.6080905@behnel.de> References: <500D98F0.4080007@behnel.de> <500DAF97.6080905@behnel.de> Message-ID: On Mon, Jul 23, 2012 at 4:09 PM, Stefan Behnel wrote: > Brett Cannon, 23.07.2012 21:48: > > On Mon, Jul 23, 2012 at 2:33 PM, Stefan Behnel wrote: > >> Brett Cannon, 23.07.2012 19:59: > >>> For my keynotes at PyCon Argentina and Brasil I'm going to be talking > >>> about Python 3.3 and trying to sell it to Python 2.7 users. That means > >>> selling the performance numbers of Python 3.3 as acceptable for Python > >>> 2.7 users. Since that means using the benchmark suite I might as well > >>> start work on merging https://bitbucket.org/pypy/benchmarks/ and > >>> http://hg.python.org/benchmarks so we can host the canonical > >>> benchmarks at hg.python.org like we have discussed previously (along > >>> with coming up with a way to run the benchmarks against Python 2.7 and > >>> 3.3 for comparison and making more tests work in Python 3). > >>> > >>> So, to start, I want to remove the divergence of the Unladen > >>> benchmarks (after that we can look at adding in any tests that are > >>> unique to PyPy). Am I right in thinking that all forked tests that > >>> came from Unladen ended up in PyPy's own directory under the same name > >>> (e.g. bm_mako.py)? > >> > >> AFAICT, the only difference is the "ai" benchmark, which is otherwise > known > >> as "nqueens". > > > > That can't be true as bm_mako.py itself is different: compare > > http://hg.python.org/benchmarks/file/5f6b46d86b40/performance/bm_mako.py > > to https://bitbucket.org/pypy/benchmarks/src/ff7b35837d0f/own/bm_mako.py > > I meant "different" as in "differently named". Ah, OK. > The specific tests have > certainly received some (minor) adaptations on both sides, be it for > porting them to Py3 or for making them more appropriate for PyPy. > That's what I'm trying to establish; how much have they diverged and if I'm looking in the proper place. -Brett > > Stefan > > _______________________________________________ > Speed mailing list > Speed at python.org > http://mail.python.org/mailman/listinfo/speed > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan_ml at behnel.de Mon Jul 23 22:21:58 2012 From: stefan_ml at behnel.de (Stefan Behnel) Date: Mon, 23 Jul 2012 22:21:58 +0200 Subject: [Speed] merging PyPy and Python benchmark suite In-Reply-To: References: <500D98F0.4080007@behnel.de> <500DAF97.6080905@behnel.de> Message-ID: <500DB266.5040306@behnel.de> Brett Cannon, 23.07.2012 22:15: > On Mon, Jul 23, 2012 at 4:09 PM, Stefan Behnel wrote: >> The specific tests have >> certainly received some (minor) adaptations on both sides, be it for >> porting them to Py3 or for making them more appropriate for PyPy. > > That's what I'm trying to establish; how much have they diverged and if I'm > looking in the proper place. You should expect that the benchmarked libraries and applications are unchanged, and that only the (similarly named) benchmark scripts were modified. Stefan From arigo at tunes.org Mon Jul 23 22:39:11 2012 From: arigo at tunes.org (Armin Rigo) Date: Mon, 23 Jul 2012 22:39:11 +0200 Subject: [Speed] merging PyPy and Python benchmark suite In-Reply-To: References: <500D98F0.4080007@behnel.de> <500DAF97.6080905@behnel.de> Message-ID: Hi Brett, On Mon, Jul 23, 2012 at 10:15 PM, Brett Cannon wrote: > That's what I'm trying to establish; how much have they diverged and if I'm > looking in the proper place. bm_mako.py is not from Unladen Swallow; that's why it is in pypy/benchmarks/own/. In case of doubts, check it in the history of Hg. The PyPy version was added from virhilo, which seems to be the name of his author, on 2010-12-21, and was not changed at all since then. Hg tells me that there was no change at all in the 'unladen_swallow' subdirectory, apart from 'unladen_swallow/perf.py' and adding some __init__.py somewhere. So at least these benchmarks did not receive any pypy-specific adapatations. If there are divergences, they come from changes done to the unladen-swallow benchmark suite after PyPy copied it on 2010-01-15. A bient?t, Armin. From solipsis at pitrou.net Mon Jul 23 23:24:50 2012 From: solipsis at pitrou.net (Antoine Pitrou) Date: Mon, 23 Jul 2012 23:24:50 +0200 Subject: [Speed] pathlib benchmark? References: <20120723211054.1c7e49dd@pitrou.net> Message-ID: <20120723232450.5e051940@pitrou.net> On Mon, 23 Jul 2012 15:50:31 -0400 Brett Cannon wrote: > > Same here, especially if it can include Unicode path stuff. Ok, done in http://hg.python.org/benchmarks/rev/72516165f6ed. Unicode paths are naturally tested with 3.x, but not with 2.x where bytes are the natural type for file paths. (however, I didn't integrate any non-ASCII paths in the test, if that's what you meant) Regards Antoine. -- Software development and contracting: http://pro.pitrou.net From brett at python.org Mon Jul 23 23:46:29 2012 From: brett at python.org (Brett Cannon) Date: Mon, 23 Jul 2012 17:46:29 -0400 Subject: [Speed] merging PyPy and Python benchmark suite In-Reply-To: References: <500D98F0.4080007@behnel.de> <500DAF97.6080905@behnel.de> Message-ID: On Mon, Jul 23, 2012 at 4:39 PM, Armin Rigo wrote: > Hi Brett, > > On Mon, Jul 23, 2012 at 10:15 PM, Brett Cannon wrote: > > That's what I'm trying to establish; how much have they diverged and if > I'm > > looking in the proper place. > > bm_mako.py is not from Unladen Swallow; that's why it is in > pypy/benchmarks/own/. In case of doubts, check it in the history of > Hg. The PyPy version was added from virhilo, which seems to be the > name of his author, on 2010-12-21, and was not changed at all since > then. > OK. Maciej has always told me that a problem with the Unladen benchmarks was that some of them had artificial loop unrolling, etc., so I had assumed you had simply fixed those instances instead of creating entirely new benchmarks. > > Hg tells me that there was no change at all in the 'unladen_swallow' > subdirectory, apart from 'unladen_swallow/perf.py' and adding some > __init__.py somewhere. So at least these benchmarks did not receive > any pypy-specific adapatations. If there are divergences, they come > from changes done to the unladen-swallow benchmark suite after PyPy > copied it on 2010-01-15. > I know that directory wasn't changed, but I also noticed that some benchmarks had the same name, which is why I thought they were forked versions of the same-named Unladen benchmarks. -Brett > > > A bient?t, > > Armin. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.gaynor at gmail.com Mon Jul 23 23:52:57 2012 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Mon, 23 Jul 2012 14:52:57 -0700 Subject: [Speed] merging PyPy and Python benchmark suite In-Reply-To: References: <500D98F0.4080007@behnel.de> <500DAF97.6080905@behnel.de>

Message-ID: On Mon, Jul 23, 2012 at 2:46 PM, Brett Cannon wrote: > > > On Mon, Jul 23, 2012 at 4:39 PM, Armin Rigo wrote: > >> Hi Brett, >> >> On Mon, Jul 23, 2012 at 10:15 PM, Brett Cannon wrote: >> > That's what I'm trying to establish; how much have they diverged and if >> I'm >> > looking in the proper place. >> >> bm_mako.py is not from Unladen Swallow; that's why it is in >> pypy/benchmarks/own/. In case of doubts, check it in the history of >> Hg. The PyPy version was added from virhilo, which seems to be the >> name of his author, on 2010-12-21, and was not changed at all since >> then. >> > > OK. Maciej has always told me that a problem with the Unladen benchmarks > was that some of them had artificial loop unrolling, etc., so I had assumed > you had simply fixed those instances instead of creating entirely new > benchmarks. > > That was only the super-micro benchmarks like call_bench. We simply did not include them. > >> Hg tells me that there was no change at all in the 'unladen_swallow' >> subdirectory, apart from 'unladen_swallow/perf.py' and adding some >> __init__.py somewhere. So at least these benchmarks did not receive >> any pypy-specific adapatations. If there are divergences, they come >> from changes done to the unladen-swallow benchmark suite after PyPy >> copied it on 2010-01-15. >> > > I know that directory wasn't changed, but I also noticed that some > benchmarks had the same name, which is why I thought they were forked > versions of the same-named Unladen benchmarks. > > -Brett > > >> >> >> A bient?t, >> >> Armin. >> > > > _______________________________________________ > Speed mailing list > Speed at python.org > http://mail.python.org/mailman/listinfo/speed > > Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero -------------- next part -------------- An HTML attachment was scrubbed... URL: From solipsis at pitrou.net Mon Jul 23 23:53:59 2012 From: solipsis at pitrou.net (Antoine Pitrou) Date: Mon, 23 Jul 2012 23:53:59 +0200 Subject: [Speed] merging PyPy and Python benchmark suite References: <500D98F0.4080007@behnel.de> <500DAF97.6080905@behnel.de>

Message-ID: <20120723235359.288993ae@pitrou.net> On Mon, 23 Jul 2012 17:46:29 -0400 Brett Cannon wrote: > > OK. Maciej has always told me that a problem with the Unladen benchmarks > was that some of them had artificial loop unrolling, etc., so I had assumed > you had simply fixed those instances instead of creating entirely new > benchmarks. Is artificial unrolling a real problem or does it simply make maintenance more difficult? Regards Antoine. -- Software development and contracting: http://pro.pitrou.net From alex.gaynor at gmail.com Tue Jul 24 00:04:12 2012 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Mon, 23 Jul 2012 15:04:12 -0700 Subject: [Speed] merging PyPy and Python benchmark suite In-Reply-To: <20120723235359.288993ae@pitrou.net> References: <500D98F0.4080007@behnel.de> <500DAF97.6080905@behnel.de>

<20120723235359.288993ae@pitrou.net> Message-ID: On Mon, Jul 23, 2012 at 2:53 PM, Antoine Pitrou wrote: > On Mon, 23 Jul 2012 17:46:29 -0400 > Brett Cannon wrote: > > > > OK. Maciej has always told me that a problem with the Unladen benchmarks > > was that some of them had artificial loop unrolling, etc., so I had > assumed > > you had simply fixed those instances instead of creating entirely new > > benchmarks. > > Is artificial unrolling a real problem or does it simply make > maintenance more difficult? > > Regards > > Antoine. > > > -- > Software development and contracting: http://pro.pitrou.net > > > _______________________________________________ > Speed mailing list > Speed at python.org > http://mail.python.org/mailman/listinfo/speed > The result is that the test a) is totally unrepresentative of real code, b) used to cause it to totally avoid the PyPy JIT, this is no longer true. http://hg.python.org/benchmarks/file/72516165f6ed/performance/bm_call_simple.pyis an example . Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero -------------- next part -------------- An HTML attachment was scrubbed... URL: From fijall at gmail.com Tue Jul 24 01:34:01 2012 From: fijall at gmail.com (Maciej Fijalkowski) Date: Tue, 24 Jul 2012 01:34:01 +0200 Subject: [Speed] merging PyPy and Python benchmark suite In-Reply-To: References: <500D98F0.4080007@behnel.de> <500DAF97.6080905@behnel.de>

Message-ID: On Mon, Jul 23, 2012 at 11:46 PM, Brett Cannon wrote: > > > On Mon, Jul 23, 2012 at 4:39 PM, Armin Rigo wrote: >> >> Hi Brett, >> >> On Mon, Jul 23, 2012 at 10:15 PM, Brett Cannon wrote: >> > That's what I'm trying to establish; how much have they diverged and if >> > I'm >> > looking in the proper place. >> >> bm_mako.py is not from Unladen Swallow; that's why it is in >> pypy/benchmarks/own/. In case of doubts, check it in the history of >> Hg. The PyPy version was added from virhilo, which seems to be the >> name of his author, on 2010-12-21, and was not changed at all since >> then. > > > OK. Maciej has always told me that a problem with the Unladen benchmarks was > that some of them had artificial loop unrolling, etc., so I had assumed you > had simply fixed those instances instead of creating entirely new > benchmarks. No we did not use those benchmarks. Those were mostly completely artificial microbenchmarks (call, call_method etc.). We decided we're not really that interested in microbenchmarks. > >> >> >> Hg tells me that there was no change at all in the 'unladen_swallow' >> subdirectory, apart from 'unladen_swallow/perf.py' and adding some >> __init__.py somewhere. So at least these benchmarks did not receive >> any pypy-specific adapatations. If there are divergences, they come >> from changes done to the unladen-swallow benchmark suite after PyPy >> copied it on 2010-01-15. > > > I know that directory wasn't changed, but I also noticed that some > benchmarks had the same name, which is why I thought they were forked > versions of the same-named Unladen benchmarks. Not if they're in own/ directory. Cheers, fijal From fijall at gmail.com Tue Jul 24 01:35:45 2012 From: fijall at gmail.com (Maciej Fijalkowski) Date: Tue, 24 Jul 2012 01:35:45 +0200 Subject: [Speed] merging PyPy and Python benchmark suite In-Reply-To: <20120723235359.288993ae@pitrou.net> References: <500D98F0.4080007@behnel.de> <500DAF97.6080905@behnel.de>

<20120723235359.288993ae@pitrou.net> Message-ID: On Mon, Jul 23, 2012 at 11:53 PM, Antoine Pitrou wrote: > On Mon, 23 Jul 2012 17:46:29 -0400 > Brett Cannon wrote: >> >> OK. Maciej has always told me that a problem with the Unladen benchmarks >> was that some of them had artificial loop unrolling, etc., so I had assumed >> you had simply fixed those instances instead of creating entirely new >> benchmarks. > > Is artificial unrolling a real problem or does it simply make > maintenance more difficult? > > Regards > > Antoine. The benchmark alex linked to is completely silly. It ends up having a very weird profile on PyPy - it takes forever to warm up the JIT, but once it's warm, it figures out the code does not actually do anything and removes it almost completely. This is also very sensitive to heuristics taken in the JIT (the warm up time mostly), so we decided it's really so artificial we don't want to be too concerned in PyPy about it. Cheers, fijal From brett at python.org Tue Jul 24 19:10:52 2012 From: brett at python.org (Brett Cannon) Date: Tue, 24 Jul 2012 13:10:52 -0400 Subject: [Speed] merging PyPy and Python benchmark suite In-Reply-To: References: <500D98F0.4080007@behnel.de> <500DAF97.6080905@behnel.de>

Message-ID: On Mon, Jul 23, 2012 at 7:34 PM, Maciej Fijalkowski wrote: > On Mon, Jul 23, 2012 at 11:46 PM, Brett Cannon wrote: > > > > > > On Mon, Jul 23, 2012 at 4:39 PM, Armin Rigo wrote: > >> > >> Hi Brett, > >> > >> On Mon, Jul 23, 2012 at 10:15 PM, Brett Cannon > wrote: > >> > That's what I'm trying to establish; how much have they diverged and > if > >> > I'm > >> > looking in the proper place. > >> > >> bm_mako.py is not from Unladen Swallow; that's why it is in > >> pypy/benchmarks/own/. In case of doubts, check it in the history of > >> Hg. The PyPy version was added from virhilo, which seems to be the > >> name of his author, on 2010-12-21, and was not changed at all since > >> then. > > > > > > OK. Maciej has always told me that a problem with the Unladen benchmarks > was > > that some of them had artificial loop unrolling, etc., so I had assumed > you > > had simply fixed those instances instead of creating entirely new > > benchmarks. > > No we did not use those benchmarks. Those were mostly completely > artificial microbenchmarks (call, call_method etc.). We decided we're > not really that interested in microbenchmarks. > > > > >> > >> > >> Hg tells me that there was no change at all in the 'unladen_swallow' > >> subdirectory, apart from 'unladen_swallow/perf.py' and adding some > >> __init__.py somewhere. So at least these benchmarks did not receive > >> any pypy-specific adapatations. If there are divergences, they come > >> from changes done to the unladen-swallow benchmark suite after PyPy > >> copied it on 2010-01-15. > > > > > > I know that directory wasn't changed, but I also noticed that some > > benchmarks had the same name, which is why I thought they were forked > > versions of the same-named Unladen benchmarks. > > Not if they're in own/ directory. > OK, good to know. I realized I can't copy code wholesale from PyPy's benchmark suite as I don't know the code's history and thus if the contributor signed Python's contributor agreement. Can the people who are familiar with the code help move benchmarks over where the copyright isn't in question? I can at least try to improve the Python 3 situation by doing things like pulling in Vinay's py3k port of Django, etc. to fill in gaps. I will also try to get the benchmarks to work with a Python 2.7 control and a Python 3 "experimental" target for comparing performance since that's what I need (or at least be able to run the benchmarks on their own and writing out the results for later comparison). Anything else that should be worked on? -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.gaynor at gmail.com Tue Jul 24 19:14:28 2012 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Tue, 24 Jul 2012 10:14:28 -0700 Subject: [Speed] merging PyPy and Python benchmark suite In-Reply-To: References: <500D98F0.4080007@behnel.de> <500DAF97.6080905@behnel.de>

Message-ID: On Tue, Jul 24, 2012 at 10:10 AM, Brett Cannon wrote: > > > On Mon, Jul 23, 2012 at 7:34 PM, Maciej Fijalkowski wrote: > >> On Mon, Jul 23, 2012 at 11:46 PM, Brett Cannon wrote: >> > >> > >> > On Mon, Jul 23, 2012 at 4:39 PM, Armin Rigo wrote: >> >> >> >> Hi Brett, >> >> >> >> On Mon, Jul 23, 2012 at 10:15 PM, Brett Cannon >> wrote: >> >> > That's what I'm trying to establish; how much have they diverged and >> if >> >> > I'm >> >> > looking in the proper place. >> >> >> >> bm_mako.py is not from Unladen Swallow; that's why it is in >> >> pypy/benchmarks/own/. In case of doubts, check it in the history of >> >> Hg. The PyPy version was added from virhilo, which seems to be the >> >> name of his author, on 2010-12-21, and was not changed at all since >> >> then. >> > >> > >> > OK. Maciej has always told me that a problem with the Unladen >> benchmarks was >> > that some of them had artificial loop unrolling, etc., so I had assumed >> you >> > had simply fixed those instances instead of creating entirely new >> > benchmarks. >> >> No we did not use those benchmarks. Those were mostly completely >> artificial microbenchmarks (call, call_method etc.). We decided we're >> not really that interested in microbenchmarks. >> >> > >> >> >> >> >> >> Hg tells me that there was no change at all in the 'unladen_swallow' >> >> subdirectory, apart from 'unladen_swallow/perf.py' and adding some >> >> __init__.py somewhere. So at least these benchmarks did not receive >> >> any pypy-specific adapatations. If there are divergences, they come >> >> from changes done to the unladen-swallow benchmark suite after PyPy >> >> copied it on 2010-01-15. >> > >> > >> > I know that directory wasn't changed, but I also noticed that some >> > benchmarks had the same name, which is why I thought they were forked >> > versions of the same-named Unladen benchmarks. >> >> Not if they're in own/ directory. >> > > OK, good to know. I realized I can't copy code wholesale from PyPy's > benchmark suite as I don't know the code's history and thus if the > contributor signed Python's contributor agreement. Can the people who are > familiar with the code help move benchmarks over where the copyright isn't > in question? > > I can at least try to improve the Python 3 situation by doing things like > pulling in Vinay's py3k port of Django, etc. to fill in gaps. I will also > try to get the benchmarks to work with a Python 2.7 control and a Python 3 > "experimental" target for comparing performance since that's what I need > (or at least be able to run the benchmarks on their own and writing out the > results for later comparison). > > Anything else that should be worked on? > > _______________________________________________ > Speed mailing list > Speed at python.org > http://mail.python.org/mailman/listinfo/speed > > The important thing is that once a benchmark is in the repo it can *never* change including all the versions of dependencies, only Python can vary, otherwise you kill the ability to actually do science with the numbers. So, e.g., I wouldn't pull in Vijnay's fork, since that's going to be utterly obsolete in a few weeks probably, I'd wait to have django on py3k for that work to all be merged into django itself. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero -------------- next part -------------- An HTML attachment was scrubbed... URL: From fijall at gmail.com Tue Jul 24 19:29:25 2012 From: fijall at gmail.com (Maciej Fijalkowski) Date: Tue, 24 Jul 2012 19:29:25 +0200 Subject: [Speed] merging PyPy and Python benchmark suite In-Reply-To: References: <500D98F0.4080007@behnel.de> <500DAF97.6080905@behnel.de>

Message-ID: On Tue, Jul 24, 2012 at 7:10 PM, Brett Cannon wrote: > > > On Mon, Jul 23, 2012 at 7:34 PM, Maciej Fijalkowski > wrote: >> >> On Mon, Jul 23, 2012 at 11:46 PM, Brett Cannon wrote: >> > >> > >> > On Mon, Jul 23, 2012 at 4:39 PM, Armin Rigo wrote: >> >> >> >> Hi Brett, >> >> >> >> On Mon, Jul 23, 2012 at 10:15 PM, Brett Cannon >> >> wrote: >> >> > That's what I'm trying to establish; how much have they diverged and >> >> > if >> >> > I'm >> >> > looking in the proper place. >> >> >> >> bm_mako.py is not from Unladen Swallow; that's why it is in >> >> pypy/benchmarks/own/. In case of doubts, check it in the history of >> >> Hg. The PyPy version was added from virhilo, which seems to be the >> >> name of his author, on 2010-12-21, and was not changed at all since >> >> then. >> > >> > >> > OK. Maciej has always told me that a problem with the Unladen benchmarks >> > was >> > that some of them had artificial loop unrolling, etc., so I had assumed >> > you >> > had simply fixed those instances instead of creating entirely new >> > benchmarks. >> >> No we did not use those benchmarks. Those were mostly completely >> artificial microbenchmarks (call, call_method etc.). We decided we're >> not really that interested in microbenchmarks. >> >> > >> >> >> >> >> >> Hg tells me that there was no change at all in the 'unladen_swallow' >> >> subdirectory, apart from 'unladen_swallow/perf.py' and adding some >> >> __init__.py somewhere. So at least these benchmarks did not receive >> >> any pypy-specific adapatations. If there are divergences, they come >> >> from changes done to the unladen-swallow benchmark suite after PyPy >> >> copied it on 2010-01-15. >> > >> > >> > I know that directory wasn't changed, but I also noticed that some >> > benchmarks had the same name, which is why I thought they were forked >> > versions of the same-named Unladen benchmarks. >> >> Not if they're in own/ directory. > > > OK, good to know. I realized I can't copy code wholesale from PyPy's > benchmark suite as I don't know the code's history and thus if the > contributor signed Python's contributor agreement. Can the people who are > familiar with the code help move benchmarks over where the copyright isn't > in question? > Can we find a home for benchmarks where we don't need everyone to sign the copyright agreement? Cheers, fijal From alex.gaynor at gmail.com Tue Jul 24 19:35:37 2012 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Tue, 24 Jul 2012 10:35:37 -0700 Subject: [Speed] merging PyPy and Python benchmark suite In-Reply-To: References: <500D98F0.4080007@behnel.de> <500DAF97.6080905@behnel.de>

Message-ID: On Tue, Jul 24, 2012 at 10:29 AM, Maciej Fijalkowski wrote: > On Tue, Jul 24, 2012 at 7:10 PM, Brett Cannon wrote: > > > > > > On Mon, Jul 23, 2012 at 7:34 PM, Maciej Fijalkowski > > wrote: > >> > >> On Mon, Jul 23, 2012 at 11:46 PM, Brett Cannon > wrote: > >> > > >> > > >> > On Mon, Jul 23, 2012 at 4:39 PM, Armin Rigo wrote: > >> >> > >> >> Hi Brett, > >> >> > >> >> On Mon, Jul 23, 2012 at 10:15 PM, Brett Cannon > >> >> wrote: > >> >> > That's what I'm trying to establish; how much have they diverged > and > >> >> > if > >> >> > I'm > >> >> > looking in the proper place. > >> >> > >> >> bm_mako.py is not from Unladen Swallow; that's why it is in > >> >> pypy/benchmarks/own/. In case of doubts, check it in the history of > >> >> Hg. The PyPy version was added from virhilo, which seems to be the > >> >> name of his author, on 2010-12-21, and was not changed at all since > >> >> then. > >> > > >> > > >> > OK. Maciej has always told me that a problem with the Unladen > benchmarks > >> > was > >> > that some of them had artificial loop unrolling, etc., so I had > assumed > >> > you > >> > had simply fixed those instances instead of creating entirely new > >> > benchmarks. > >> > >> No we did not use those benchmarks. Those were mostly completely > >> artificial microbenchmarks (call, call_method etc.). We decided we're > >> not really that interested in microbenchmarks. > >> > >> > > >> >> > >> >> > >> >> Hg tells me that there was no change at all in the 'unladen_swallow' > >> >> subdirectory, apart from 'unladen_swallow/perf.py' and adding some > >> >> __init__.py somewhere. So at least these benchmarks did not receive > >> >> any pypy-specific adapatations. If there are divergences, they come > >> >> from changes done to the unladen-swallow benchmark suite after PyPy > >> >> copied it on 2010-01-15. > >> > > >> > > >> > I know that directory wasn't changed, but I also noticed that some > >> > benchmarks had the same name, which is why I thought they were forked > >> > versions of the same-named Unladen benchmarks. > >> > >> Not if they're in own/ directory. > > > > > > OK, good to know. I realized I can't copy code wholesale from PyPy's > > benchmark suite as I don't know the code's history and thus if the > > contributor signed Python's contributor agreement. Can the people who are > > familiar with the code help move benchmarks over where the copyright > isn't > > in question? > > > > Can we find a home for benchmarks where we don't need everyone to sign > the copyright agreement? > > Cheers, > fijal > _______________________________________________ > Speed mailing list > Speed at python.org > http://mail.python.org/mailman/listinfo/speed > It seems totally reasonable for them to be official and be under the PSF license, and have copyright agreements signed. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero -------------- next part -------------- An HTML attachment was scrubbed... URL: From solipsis at pitrou.net Tue Jul 24 19:33:34 2012 From: solipsis at pitrou.net (Antoine Pitrou) Date: Tue, 24 Jul 2012 19:33:34 +0200 Subject: [Speed] merging PyPy and Python benchmark suite References: <500D98F0.4080007@behnel.de> <500DAF97.6080905@behnel.de>

Message-ID: <20120724193334.0832f95f@pitrou.net> On Tue, 24 Jul 2012 13:10:52 -0400 Brett Cannon wrote: > > OK, good to know. I realized I can't copy code wholesale from PyPy's > benchmark suite as I don't know the code's history and thus if the > contributor signed Python's contributor agreement. Why is that? The benchmark suite isn't included in CPython. As a matter of fact, the current benchmark suite contains code that certainly has not been contributed under the PSF CA (e.g. mako). Regards Antoine. -- Software development and contracting: http://pro.pitrou.net From fijall at gmail.com Tue Jul 24 19:37:34 2012 From: fijall at gmail.com (Maciej Fijalkowski) Date: Tue, 24 Jul 2012 19:37:34 +0200 Subject: [Speed] merging PyPy and Python benchmark suite In-Reply-To: References: <500D98F0.4080007@behnel.de> <500DAF97.6080905@behnel.de>

Message-ID: On Tue, Jul 24, 2012 at 7:35 PM, Alex Gaynor wrote: > > > On Tue, Jul 24, 2012 at 10:29 AM, Maciej Fijalkowski > wrote: >> >> On Tue, Jul 24, 2012 at 7:10 PM, Brett Cannon wrote: >> > >> > >> > On Mon, Jul 23, 2012 at 7:34 PM, Maciej Fijalkowski >> > wrote: >> >> >> >> On Mon, Jul 23, 2012 at 11:46 PM, Brett Cannon >> >> wrote: >> >> > >> >> > >> >> > On Mon, Jul 23, 2012 at 4:39 PM, Armin Rigo wrote: >> >> >> >> >> >> Hi Brett, >> >> >> >> >> >> On Mon, Jul 23, 2012 at 10:15 PM, Brett Cannon >> >> >> wrote: >> >> >> > That's what I'm trying to establish; how much have they diverged >> >> >> > and >> >> >> > if >> >> >> > I'm >> >> >> > looking in the proper place. >> >> >> >> >> >> bm_mako.py is not from Unladen Swallow; that's why it is in >> >> >> pypy/benchmarks/own/. In case of doubts, check it in the history of >> >> >> Hg. The PyPy version was added from virhilo, which seems to be the >> >> >> name of his author, on 2010-12-21, and was not changed at all since >> >> >> then. >> >> > >> >> > >> >> > OK. Maciej has always told me that a problem with the Unladen >> >> > benchmarks >> >> > was >> >> > that some of them had artificial loop unrolling, etc., so I had >> >> > assumed >> >> > you >> >> > had simply fixed those instances instead of creating entirely new >> >> > benchmarks. >> >> >> >> No we did not use those benchmarks. Those were mostly completely >> >> artificial microbenchmarks (call, call_method etc.). We decided we're >> >> not really that interested in microbenchmarks. >> >> >> >> > >> >> >> >> >> >> >> >> >> Hg tells me that there was no change at all in the 'unladen_swallow' >> >> >> subdirectory, apart from 'unladen_swallow/perf.py' and adding some >> >> >> __init__.py somewhere. So at least these benchmarks did not receive >> >> >> any pypy-specific adapatations. If there are divergences, they come >> >> >> from changes done to the unladen-swallow benchmark suite after PyPy >> >> >> copied it on 2010-01-15. >> >> > >> >> > >> >> > I know that directory wasn't changed, but I also noticed that some >> >> > benchmarks had the same name, which is why I thought they were forked >> >> > versions of the same-named Unladen benchmarks. >> >> >> >> Not if they're in own/ directory. >> > >> > >> > OK, good to know. I realized I can't copy code wholesale from PyPy's >> > benchmark suite as I don't know the code's history and thus if the >> > contributor signed Python's contributor agreement. Can the people who >> > are >> > familiar with the code help move benchmarks over where the copyright >> > isn't >> > in question? >> > >> >> Can we find a home for benchmarks where we don't need everyone to sign >> the copyright agreement? >> >> Cheers, >> fijal >> >> _______________________________________________ >> Speed mailing list >> Speed at python.org >> http://mail.python.org/mailman/listinfo/speed > > > It seems totally reasonable for them to be official and be under the PSF > license, and have copyright agreements signed. > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right to > say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > PyPy benchmark suite contains stuff from twisted, sympy, mako, tons of other libraries. I doubt we can get everyone to sign the contributor agreement. From alex.gaynor at gmail.com Tue Jul 24 19:42:15 2012 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Tue, 24 Jul 2012 10:42:15 -0700 Subject: [Speed] merging PyPy and Python benchmark suite In-Reply-To: References: <500D98F0.4080007@behnel.de> <500DAF97.6080905@behnel.de>

Message-ID: On Tue, Jul 24, 2012 at 10:37 AM, Maciej Fijalkowski wrote: > On Tue, Jul 24, 2012 at 7:35 PM, Alex Gaynor > wrote: > > > > > > On Tue, Jul 24, 2012 at 10:29 AM, Maciej Fijalkowski > > wrote: > >> > >> On Tue, Jul 24, 2012 at 7:10 PM, Brett Cannon wrote: > >> > > >> > > >> > On Mon, Jul 23, 2012 at 7:34 PM, Maciej Fijalkowski > > >> > wrote: > >> >> > >> >> On Mon, Jul 23, 2012 at 11:46 PM, Brett Cannon > >> >> wrote: > >> >> > > >> >> > > >> >> > On Mon, Jul 23, 2012 at 4:39 PM, Armin Rigo > wrote: > >> >> >> > >> >> >> Hi Brett, > >> >> >> > >> >> >> On Mon, Jul 23, 2012 at 10:15 PM, Brett Cannon > >> >> >> wrote: > >> >> >> > That's what I'm trying to establish; how much have they diverged > >> >> >> > and > >> >> >> > if > >> >> >> > I'm > >> >> >> > looking in the proper place. > >> >> >> > >> >> >> bm_mako.py is not from Unladen Swallow; that's why it is in > >> >> >> pypy/benchmarks/own/. In case of doubts, check it in the history > of > >> >> >> Hg. The PyPy version was added from virhilo, which seems to be > the > >> >> >> name of his author, on 2010-12-21, and was not changed at all > since > >> >> >> then. > >> >> > > >> >> > > >> >> > OK. Maciej has always told me that a problem with the Unladen > >> >> > benchmarks > >> >> > was > >> >> > that some of them had artificial loop unrolling, etc., so I had > >> >> > assumed > >> >> > you > >> >> > had simply fixed those instances instead of creating entirely new > >> >> > benchmarks. > >> >> > >> >> No we did not use those benchmarks. Those were mostly completely > >> >> artificial microbenchmarks (call, call_method etc.). We decided we're > >> >> not really that interested in microbenchmarks. > >> >> > >> >> > > >> >> >> > >> >> >> > >> >> >> Hg tells me that there was no change at all in the > 'unladen_swallow' > >> >> >> subdirectory, apart from 'unladen_swallow/perf.py' and adding some > >> >> >> __init__.py somewhere. So at least these benchmarks did not > receive > >> >> >> any pypy-specific adapatations. If there are divergences, they > come > >> >> >> from changes done to the unladen-swallow benchmark suite after > PyPy > >> >> >> copied it on 2010-01-15. > >> >> > > >> >> > > >> >> > I know that directory wasn't changed, but I also noticed that some > >> >> > benchmarks had the same name, which is why I thought they were > forked > >> >> > versions of the same-named Unladen benchmarks. > >> >> > >> >> Not if they're in own/ directory. > >> > > >> > > >> > OK, good to know. I realized I can't copy code wholesale from PyPy's > >> > benchmark suite as I don't know the code's history and thus if the > >> > contributor signed Python's contributor agreement. Can the people who > >> > are > >> > familiar with the code help move benchmarks over where the copyright > >> > isn't > >> > in question? > >> > > >> > >> Can we find a home for benchmarks where we don't need everyone to sign > >> the copyright agreement? > >> > >> Cheers, > >> fijal > >> > >> _______________________________________________ > >> Speed mailing list > >> Speed at python.org > >> http://mail.python.org/mailman/listinfo/speed > > > > > > It seems totally reasonable for them to be official and be under the PSF > > license, and have copyright agreements signed. > > > > Alex > > > > -- > > "I disapprove of what you say, but I will defend to the death your right > to > > say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > > "The people's good is the highest law." -- Cicero > > > > PyPy benchmark suite contains stuff from twisted, sympy, mako, tons of > other libraries. I doubt we can get everyone to sign the contributor > agreement. > You don't need every individual contributor. Each of those projects has a copyright holding entity (the DSF, the TSF, etc.), that entity can give the PSF permission. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero -------------- next part -------------- An HTML attachment was scrubbed... URL: From solipsis at pitrou.net Tue Jul 24 19:52:19 2012 From: solipsis at pitrou.net (Antoine Pitrou) Date: Tue, 24 Jul 2012 19:52:19 +0200 Subject: [Speed] merging PyPy and Python benchmark suite References: <500D98F0.4080007@behnel.de> <500DAF97.6080905@behnel.de>

Message-ID: <20120724195219.231247b3@pitrou.net> On Tue, 24 Jul 2012 10:42:15 -0700 Alex Gaynor wrote: > > > > PyPy benchmark suite contains stuff from twisted, sympy, mako, tons of > > other libraries. I doubt we can get everyone to sign the contributor > > agreement. > > > > You don't need every individual contributor. Each of those projects has a > copyright holding entity (the DSF, the TSF, etc.), that entity can give the > PSF permission. Twisted doesn't have a "copyright holding entity", and I doubt many other projects do. Regards Antoine. -- Software development and contracting: http://pro.pitrou.net From pjenvey at underboss.org Tue Jul 24 21:28:33 2012 From: pjenvey at underboss.org (Philip Jenvey) Date: Tue, 24 Jul 2012 12:28:33 -0700 Subject: [Speed] merging PyPy and Python benchmark suite In-Reply-To: <20120724195219.231247b3@pitrou.net> References: <500D98F0.4080007@behnel.de> <500DAF97.6080905@behnel.de>

<20120724195219.231247b3@pitrou.net> Message-ID: <2BFDC1BE-6035-4B73-A138-86FDC4F21412@underboss.org> On Jul 24, 2012, at 10:52 AM, Antoine Pitrou wrote: > On Tue, 24 Jul 2012 10:42:15 -0700 > Alex Gaynor wrote: >>> >>> PyPy benchmark suite contains stuff from twisted, sympy, mako, tons of >>> other libraries. I doubt we can get everyone to sign the contributor >>> agreement. >>> >> >> You don't need every individual contributor. Each of those projects has a >> copyright holding entity (the DSF, the TSF, etc.), that entity can give the >> PSF permission. > > Twisted doesn't have a "copyright holding entity", and I doubt many > other projects do. Mako certainly doesn't. -- Philip Jenvey From ncoghlan at gmail.com Tue Jul 24 23:38:14 2012 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 25 Jul 2012 07:38:14 +1000 Subject: [Speed] merging PyPy and Python benchmark suite In-Reply-To: <20120724193334.0832f95f@pitrou.net> References: <500D98F0.4080007@behnel.de> <500DAF97.6080905@behnel.de>

<20120724193334.0832f95f@pitrou.net> Message-ID: Antoine's right on this one - just use and redistribute the upstream components under their existing licenses. CPython itself is different because the PSF has chosen to reserve relicensing privileges for that, which requires the extra permissions granted in the contributor agreement. -- Sent from my phone, thus the relative brevity :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Wed Jul 25 01:49:08 2012 From: brett at python.org (Brett Cannon) Date: Tue, 24 Jul 2012 19:49:08 -0400 Subject: [Speed] merging PyPy and Python benchmark suite In-Reply-To: References: <500D98F0.4080007@behnel.de> <500DAF97.6080905@behnel.de>

Message-ID: On Tue, Jul 24, 2012 at 1:14 PM, Alex Gaynor wrote: > > > On Tue, Jul 24, 2012 at 10:10 AM, Brett Cannon wrote: > >> >> >> On Mon, Jul 23, 2012 at 7:34 PM, Maciej Fijalkowski wrote: >> >>> On Mon, Jul 23, 2012 at 11:46 PM, Brett Cannon wrote: >>> > >>> > >>> > On Mon, Jul 23, 2012 at 4:39 PM, Armin Rigo wrote: >>> >> >>> >> Hi Brett, >>> >> >>> >> On Mon, Jul 23, 2012 at 10:15 PM, Brett Cannon >>> wrote: >>> >> > That's what I'm trying to establish; how much have they diverged >>> and if >>> >> > I'm >>> >> > looking in the proper place. >>> >> >>> >> bm_mako.py is not from Unladen Swallow; that's why it is in >>> >> pypy/benchmarks/own/. In case of doubts, check it in the history of >>> >> Hg. The PyPy version was added from virhilo, which seems to be the >>> >> name of his author, on 2010-12-21, and was not changed at all since >>> >> then. >>> > >>> > >>> > OK. Maciej has always told me that a problem with the Unladen >>> benchmarks was >>> > that some of them had artificial loop unrolling, etc., so I had >>> assumed you >>> > had simply fixed those instances instead of creating entirely new >>> > benchmarks. >>> >>> No we did not use those benchmarks. Those were mostly completely >>> artificial microbenchmarks (call, call_method etc.). We decided we're >>> not really that interested in microbenchmarks. >>> >>> > >>> >> >>> >> >>> >> Hg tells me that there was no change at all in the 'unladen_swallow' >>> >> subdirectory, apart from 'unladen_swallow/perf.py' and adding some >>> >> __init__.py somewhere. So at least these benchmarks did not receive >>> >> any pypy-specific adapatations. If there are divergences, they come >>> >> from changes done to the unladen-swallow benchmark suite after PyPy >>> >> copied it on 2010-01-15. >>> > >>> > >>> > I know that directory wasn't changed, but I also noticed that some >>> > benchmarks had the same name, which is why I thought they were forked >>> > versions of the same-named Unladen benchmarks. >>> >>> Not if they're in own/ directory. >>> >> >> OK, good to know. I realized I can't copy code wholesale from PyPy's >> benchmark suite as I don't know the code's history and thus if the >> contributor signed Python's contributor agreement. Can the people who are >> familiar with the code help move benchmarks over where the copyright isn't >> in question? >> >> I can at least try to improve the Python 3 situation by doing things like >> pulling in Vinay's py3k port of Django, etc. to fill in gaps. I will also >> try to get the benchmarks to work with a Python 2.7 control and a Python 3 >> "experimental" target for comparing performance since that's what I need >> (or at least be able to run the benchmarks on their own and writing out the >> results for later comparison). >> >> Anything else that should be worked on? >> >> _______________________________________________ >> Speed mailing list >> Speed at python.org >> http://mail.python.org/mailman/listinfo/speed >> >> > The important thing is that once a benchmark is in the repo it can *never* > change including all the versions of dependencies, only Python can vary, > otherwise you kill the ability to actually do science with the numbers. > > So, e.g., I wouldn't pull in Vijnay's fork, since that's going to be > utterly obsolete in a few weeks probably, I'd wait to have django on py3k > for that work to all be merged into django itself. > If that's happening in a few weeks then I can wait. But remember my desire is to get benchmark numbers between Python 2.7 and Python 3.3 for my November keynotes so I can't punt indefinitely. -Brett > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right > to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Wed Jul 25 01:51:43 2012 From: brett at python.org (Brett Cannon) Date: Tue, 24 Jul 2012 19:51:43 -0400 Subject: [Speed] merging PyPy and Python benchmark suite In-Reply-To: References: <500D98F0.4080007@behnel.de> <500DAF97.6080905@behnel.de>

<20120724193334.0832f95f@pitrou.net> Message-ID: On Tue, Jul 24, 2012 at 5:38 PM, Nick Coghlan wrote: > Antoine's right on this one - just use and redistribute the upstream > components under their existing licenses. CPython itself is different > because the PSF has chosen to reserve relicensing privileges for that, > which requires the extra permissions granted in the contributor agreement. > But I'm talking about the benchmarks themselves, not the wholesale inclusion of Mako, etc. (which I am not worried about since the code in the dependencies is not edited). Can we move the PyPy benchmarks themselves (e.g. bm_mako.py that PyPy has) over to the PSF benchmarks without getting contributor agreements. -Brett > -- > Sent from my phone, thus the relative brevity :) > > _______________________________________________ > Speed mailing list > Speed at python.org > http://mail.python.org/mailman/listinfo/speed > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Wed Jul 25 04:37:42 2012 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 25 Jul 2012 12:37:42 +1000 Subject: [Speed] merging PyPy and Python benchmark suite In-Reply-To: References: <500D98F0.4080007@behnel.de> <500DAF97.6080905@behnel.de>

<20120724193334.0832f95f@pitrou.net> Message-ID: On Wed, Jul 25, 2012 at 9:51 AM, Brett Cannon wrote: > > > On Tue, Jul 24, 2012 at 5:38 PM, Nick Coghlan wrote: >> >> Antoine's right on this one - just use and redistribute the upstream >> components under their existing licenses. CPython itself is different >> because the PSF has chosen to reserve relicensing privileges for that, which >> requires the extra permissions granted in the contributor agreement. > > > But I'm talking about the benchmarks themselves, not the wholesale inclusion > of Mako, etc. (which I am not worried about since the code in the > dependencies is not edited). Can we move the PyPy benchmarks themselves > (e.g. bm_mako.py that PyPy has) over to the PSF benchmarks without getting > contributor agreements. The PyPy team need to put a clear license notice (similar to the one in the main pypy repo) on their benchmarks repo. But yes, I believe you're right that copying that code as it stands would technically be a copyright violation, even if the PyPy team intend for it to be allowed. If you're really concerned, check with Van first, but otherwise I'd just file a bug with the PyPy folks requesting that they clarify the licensing by adding a LICENSE file and in the meantime assume they intended for it to be covered by the MIT license, just like PyPy itself. The PSF license is necessary for CPython because of the long and complicated history of that code base. We can use simpler licenses for other stuff (like the benchmark suite) and just run with license in = license out rather than preserving the right for the PSF to change the license. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From alex.gaynor at gmail.com Wed Jul 25 05:12:27 2012 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Tue, 24 Jul 2012 20:12:27 -0700 Subject: [Speed] merging PyPy and Python benchmark suite In-Reply-To: References: <500D98F0.4080007@behnel.de> <500DAF97.6080905@behnel.de>

<20120724193334.0832f95f@pitrou.net> Message-ID: On Tue, Jul 24, 2012 at 7:37 PM, Nick Coghlan wrote: > On Wed, Jul 25, 2012 at 9:51 AM, Brett Cannon wrote: > > > > > > On Tue, Jul 24, 2012 at 5:38 PM, Nick Coghlan > wrote: > >> > >> Antoine's right on this one - just use and redistribute the upstream > >> components under their existing licenses. CPython itself is different > >> because the PSF has chosen to reserve relicensing privileges for that, > which > >> requires the extra permissions granted in the contributor agreement. > > > > > > But I'm talking about the benchmarks themselves, not the wholesale > inclusion > > of Mako, etc. (which I am not worried about since the code in the > > dependencies is not edited). Can we move the PyPy benchmarks themselves > > (e.g. bm_mako.py that PyPy has) over to the PSF benchmarks without > getting > > contributor agreements. > > The PyPy team need to put a clear license notice (similar to the one > in the main pypy repo) on their benchmarks repo. But yes, I believe > you're right that copying that code as it stands would technically be > a copyright violation, even if the PyPy team intend for it to be > allowed. > > If you're really concerned, check with Van first, but otherwise I'd > just file a bug with the PyPy folks requesting that they clarify the > licensing by adding a LICENSE file and in the meantime assume they > intended for it to be covered by the MIT license, just like PyPy > itself. > > The PSF license is necessary for CPython because of the long and > complicated history of that code base. We can use simpler licenses for > other stuff (like the benchmark suite) and just run with license in = > license out rather than preserving the right for the PSF to change the > license. > > Cheers, > Nick. > > -- > Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia > _______________________________________________ > Speed mailing list > Speed at python.org > http://mail.python.org/mailman/listinfo/speed > First, I believe all the unalden swallow stuff (including the runner) is under the PSF licence, though you'd have to check the repo for a license file or bug Jeffrey and Collin. Someone (fijal) will add an MIT license for our half of the repo. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero -------------- next part -------------- An HTML attachment was scrubbed... URL: From fijall at gmail.com Wed Jul 25 12:54:00 2012 From: fijall at gmail.com (Maciej Fijalkowski) Date: Wed, 25 Jul 2012 12:54:00 +0200 Subject: [Speed] merging PyPy and Python benchmark suite In-Reply-To: References: <500D98F0.4080007@behnel.de> <500DAF97.6080905@behnel.de>

<20120724193334.0832f95f@pitrou.net> Message-ID: On Wed, Jul 25, 2012 at 5:12 AM, Alex Gaynor wrote: > > > On Tue, Jul 24, 2012 at 7:37 PM, Nick Coghlan wrote: >> >> On Wed, Jul 25, 2012 at 9:51 AM, Brett Cannon wrote: >> > >> > >> > On Tue, Jul 24, 2012 at 5:38 PM, Nick Coghlan >> > wrote: >> >> >> >> Antoine's right on this one - just use and redistribute the upstream >> >> components under their existing licenses. CPython itself is different >> >> because the PSF has chosen to reserve relicensing privileges for that, >> >> which >> >> requires the extra permissions granted in the contributor agreement. >> > >> > >> > But I'm talking about the benchmarks themselves, not the wholesale >> > inclusion >> > of Mako, etc. (which I am not worried about since the code in the >> > dependencies is not edited). Can we move the PyPy benchmarks themselves >> > (e.g. bm_mako.py that PyPy has) over to the PSF benchmarks without >> > getting >> > contributor agreements. >> >> The PyPy team need to put a clear license notice (similar to the one >> in the main pypy repo) on their benchmarks repo. But yes, I believe >> you're right that copying that code as it stands would technically be >> a copyright violation, even if the PyPy team intend for it to be >> allowed. >> >> If you're really concerned, check with Van first, but otherwise I'd >> just file a bug with the PyPy folks requesting that they clarify the >> licensing by adding a LICENSE file and in the meantime assume they >> intended for it to be covered by the MIT license, just like PyPy >> itself. >> >> The PSF license is necessary for CPython because of the long and >> complicated history of that code base. We can use simpler licenses for >> other stuff (like the benchmark suite) and just run with license in = >> license out rather than preserving the right for the PSF to change the >> license. >> >> Cheers, >> Nick. >> >> -- >> Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia >> _______________________________________________ >> Speed mailing list >> Speed at python.org >> http://mail.python.org/mailman/listinfo/speed > > > First, I believe all the unalden swallow stuff (including the runner) is > under the PSF licence, though you'd have to check the repo for a license > file or bug Jeffrey and Collin. Someone (fijal) will add an MIT license for > our half of the repo. > > > Alex Done. PyPy benchmarks are MIT From ncoghlan at gmail.com Wed Jul 25 13:56:13 2012 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 25 Jul 2012 21:56:13 +1000 Subject: [Speed] merging PyPy and Python benchmark suite In-Reply-To: References: <500D98F0.4080007@behnel.de> <500DAF97.6080905@behnel.de>

<20120724193334.0832f95f@pitrou.net>

Message-ID: On Wed, Jul 25, 2012 at 8:54 PM, Maciej Fijalkowski wrote: > Done. PyPy benchmarks are MIT Thanks for clearing that up. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From brett at python.org Wed Jul 25 20:16:34 2012 From: brett at python.org (Brett Cannon) Date: Wed, 25 Jul 2012 14:16:34 -0400 Subject: [Speed] merging PyPy and Python benchmark suite In-Reply-To: References: <500D98F0.4080007@behnel.de> <500DAF97.6080905@behnel.de>

<20120724193334.0832f95f@pitrou.net>

Message-ID: On Wed, Jul 25, 2012 at 6:54 AM, Maciej Fijalkowski wrote: > On Wed, Jul 25, 2012 at 5:12 AM, Alex Gaynor > wrote: > > > > > > On Tue, Jul 24, 2012 at 7:37 PM, Nick Coghlan > wrote: > >> > >> On Wed, Jul 25, 2012 at 9:51 AM, Brett Cannon wrote: > >> > > >> > > >> > On Tue, Jul 24, 2012 at 5:38 PM, Nick Coghlan > >> > wrote: > >> >> > >> >> Antoine's right on this one - just use and redistribute the upstream > >> >> components under their existing licenses. CPython itself is different > >> >> because the PSF has chosen to reserve relicensing privileges for > that, > >> >> which > >> >> requires the extra permissions granted in the contributor agreement. > >> > > >> > > >> > But I'm talking about the benchmarks themselves, not the wholesale > >> > inclusion > >> > of Mako, etc. (which I am not worried about since the code in the > >> > dependencies is not edited). Can we move the PyPy benchmarks > themselves > >> > (e.g. bm_mako.py that PyPy has) over to the PSF benchmarks without > >> > getting > >> > contributor agreements. > >> > >> The PyPy team need to put a clear license notice (similar to the one > >> in the main pypy repo) on their benchmarks repo. But yes, I believe > >> you're right that copying that code as it stands would technically be > >> a copyright violation, even if the PyPy team intend for it to be > >> allowed. > >> > >> If you're really concerned, check with Van first, but otherwise I'd > >> just file a bug with the PyPy folks requesting that they clarify the > >> licensing by adding a LICENSE file and in the meantime assume they > >> intended for it to be covered by the MIT license, just like PyPy > >> itself. > >> > >> The PSF license is necessary for CPython because of the long and > >> complicated history of that code base. We can use simpler licenses for > >> other stuff (like the benchmark suite) and just run with license in = > >> license out rather than preserving the right for the PSF to change the > >> license. > >> > >> Cheers, > >> Nick. > >> > >> -- > >> Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia > >> _______________________________________________ > >> Speed mailing list > >> Speed at python.org > >> http://mail.python.org/mailman/listinfo/speed > > > > > > First, I believe all the unalden swallow stuff (including the runner) is > > under the PSF licence, though you'd have to check the repo for a license > > file or bug Jeffrey and Collin. Someone (fijal) will add an MIT license > for > > our half of the repo. > > > > > > Alex > > Done. PyPy benchmarks are MIT Great! Then I'm happy with moving PyPy benchmarks over wholesale. Are there any benchmarks that are *really* good and are thus a priority to move, or any that are just flat-out bad and I shouldn't bother moviing? -------------- next part -------------- An HTML attachment was scrubbed... URL: From solipsis at pitrou.net Wed Jul 25 20:39:33 2012 From: solipsis at pitrou.net (Antoine Pitrou) Date: Wed, 25 Jul 2012 20:39:33 +0200 Subject: [Speed] merging PyPy and Python benchmark suite References:

<500DAF97.6080905@behnel.de>

<20120724193334.0832f95f@pitrou.net>

Message-ID: <20120725203933.6513bf35@pitrou.net> Should we add the MIT license to our benchmarks repo as well? cheers Antoine. On Wed, 25 Jul 2012 14:16:34 -0400 Brett Cannon wrote: > On Wed, Jul 25, 2012 at 6:54 AM, Maciej Fijalkowski wrote: > > > On Wed, Jul 25, 2012 at 5:12 AM, Alex Gaynor > > wrote: > > > > > > > > > On Tue, Jul 24, 2012 at 7:37 PM, Nick Coghlan > > wrote: > > >> > > >> On Wed, Jul 25, 2012 at 9:51 AM, Brett Cannon wrote: > > >> > > > >> > > > >> > On Tue, Jul 24, 2012 at 5:38 PM, Nick Coghlan > > >> > wrote: > > >> >> > > >> >> Antoine's right on this one - just use and redistribute the upstream > > >> >> components under their existing licenses. CPython itself is different > > >> >> because the PSF has chosen to reserve relicensing privileges for > > that, > > >> >> which > > >> >> requires the extra permissions granted in the contributor agreement. > > >> > > > >> > > > >> > But I'm talking about the benchmarks themselves, not the wholesale > > >> > inclusion > > >> > of Mako, etc. (which I am not worried about since the code in the > > >> > dependencies is not edited). Can we move the PyPy benchmarks > > themselves > > >> > (e.g. bm_mako.py that PyPy has) over to the PSF benchmarks without > > >> > getting > > >> > contributor agreements. > > >> > > >> The PyPy team need to put a clear license notice (similar to the one > > >> in the main pypy repo) on their benchmarks repo. But yes, I believe > > >> you're right that copying that code as it stands would technically be > > >> a copyright violation, even if the PyPy team intend for it to be > > >> allowed. > > >> > > >> If you're really concerned, check with Van first, but otherwise I'd > > >> just file a bug with the PyPy folks requesting that they clarify the > > >> licensing by adding a LICENSE file and in the meantime assume they > > >> intended for it to be covered by the MIT license, just like PyPy > > >> itself. > > >> > > >> The PSF license is necessary for CPython because of the long and > > >> complicated history of that code base. We can use simpler licenses for > > >> other stuff (like the benchmark suite) and just run with license in = > > >> license out rather than preserving the right for the PSF to change the > > >> license. > > >> > > >> Cheers, > > >> Nick. > > >> > > >> -- > > >> Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia > > >> _______________________________________________ > > >> Speed mailing list > > >> Speed at python.org > > >> http://mail.python.org/mailman/listinfo/speed > > > > > > > > > First, I believe all the unalden swallow stuff (including the runner) is > > > under the PSF licence, though you'd have to check the repo for a license > > > file or bug Jeffrey and Collin. Someone (fijal) will add an MIT license > > for > > > our half of the repo. > > > > > > > > > Alex > > > > Done. PyPy benchmarks are MIT > > > Great! Then I'm happy with moving PyPy benchmarks over wholesale. Are there > any benchmarks that are *really* good and are thus a priority to move, or > any that are just flat-out bad and I shouldn't bother moviing? > -- Software development and contracting: http://pro.pitrou.net From fijall at gmail.com Wed Jul 25 21:18:15 2012 From: fijall at gmail.com (Maciej Fijalkowski) Date: Wed, 25 Jul 2012 21:18:15 +0200 Subject: [Speed] merging PyPy and Python benchmark suite In-Reply-To: References: <500D98F0.4080007@behnel.de> <500DAF97.6080905@behnel.de>

<20120724193334.0832f95f@pitrou.net>

Message-ID: On Wed, Jul 25, 2012 at 8:16 PM, Brett Cannon