Re: [Speed] merging PyPy and Python benchmark suite

2012-07-26 Thread Brett Cannon
On Wed, Jul 25, 2012 at 4:54 PM, Antoine Pitrou solip...@pitrou.net wrote:

 On Wed, 25 Jul 2012 16:45:27 -0400
 Brett Cannon br...@python.org wrote:
  On Wed, Jul 25, 2012 at 2:39 PM, Antoine Pitrou solip...@pitrou.net
 wrote:
 
  
   Should we add the MIT license to our benchmarks repo as well?
  
 
  I'm fine with it, although is there an issue with changing it? I know
 that
  the code has no history and thus doesn't strictly need to use the PSF
  license, but IANAL.

 Well there's no license right now, which makes it non-open source
 software :)


And I noticed you added the MIT license, so now we are license-compatible.
Let the wholesale copying begin! =)

-Brett



 Regards

 Antoine.


 --
 Software development and contracting: http://pro.pitrou.net


 ___
 Speed mailing list
 Speed@python.org
 http://mail.python.org/mailman/listinfo/speed

___
Speed mailing list
Speed@python.org
http://mail.python.org/mailman/listinfo/speed


Re: [Speed] merging PyPy and Python benchmark suite

2012-07-25 Thread Nick Coghlan
On Wed, Jul 25, 2012 at 8:54 PM, Maciej Fijalkowski fij...@gmail.com wrote:
 Done. PyPy benchmarks are MIT

Thanks for clearing that up.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Speed mailing list
Speed@python.org
http://mail.python.org/mailman/listinfo/speed


Re: [Speed] merging PyPy and Python benchmark suite

2012-07-25 Thread Brett Cannon
On Wed, Jul 25, 2012 at 6:54 AM, Maciej Fijalkowski fij...@gmail.comwrote:

 On Wed, Jul 25, 2012 at 5:12 AM, Alex Gaynor alex.gay...@gmail.com
 wrote:
 
 
  On Tue, Jul 24, 2012 at 7:37 PM, Nick Coghlan ncogh...@gmail.com
 wrote:
 
  On Wed, Jul 25, 2012 at 9:51 AM, Brett Cannon br...@python.org wrote:
  
  
   On Tue, Jul 24, 2012 at 5:38 PM, Nick Coghlan ncogh...@gmail.com
   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   |   ncogh...@gmail.com   |   Brisbane, Australia
  ___
  Speed mailing list
  Speed@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?
___
Speed mailing list
Speed@python.org
http://mail.python.org/mailman/listinfo/speed


Re: [Speed] merging PyPy and Python benchmark suite

2012-07-25 Thread Maciej Fijalkowski
On Wed, Jul 25, 2012 at 8:16 PM, Brett Cannon br...@python.org wrote:


 On Wed, Jul 25, 2012 at 6:54 AM, Maciej Fijalkowski fij...@gmail.com
 wrote:

 On Wed, Jul 25, 2012 at 5:12 AM, Alex Gaynor alex.gay...@gmail.com
 wrote:
 
 
  On Tue, Jul 24, 2012 at 7:37 PM, Nick Coghlan ncogh...@gmail.com
  wrote:
 
  On Wed, Jul 25, 2012 at 9:51 AM, Brett Cannon br...@python.org wrote:
  
  
   On Tue, Jul 24, 2012 at 5:38 PM, Nick Coghlan ncogh...@gmail.com
   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   |   ncogh...@gmail.com   |   Brisbane, Australia
  ___
  Speed mailing list
  Speed@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?

Note that not all benchmarks run nightly. twisted_accept for example
run out of TCP connections. benchmarks.py is your helper. We improved
the US runner qutie significantly (the main runner.py file), mostly by
improving reporting. So it can save a .json file or upload stuff to a
codespeed instance.

Other than that, they all measure something. It's really up to you to
decide which ones measure something significant. Of course for our
purposes benchmarks which require large libs are more interesting than
others, but they all do something interesting. We removed those that
we consider completely uninteresting.
___
Speed mailing list
Speed@python.org
http://mail.python.org/mailman/listinfo/speed


Re: [Speed] merging PyPy and Python benchmark suite

2012-07-25 Thread Brett Cannon
On Wed, Jul 25, 2012 at 2:39 PM, Antoine Pitrou solip...@pitrou.net wrote:


 Should we add the MIT license to our benchmarks repo as well?


I'm fine with it, although is there an issue with changing it? I know that
the code has no history and thus doesn't strictly need to use the PSF
license, but IANAL.

-Brett



 cheers

 Antoine.



 On Wed, 25 Jul 2012 14:16:34 -0400
 Brett Cannon br...@python.org wrote:

  On Wed, Jul 25, 2012 at 6:54 AM, Maciej Fijalkowski fij...@gmail.com
 wrote:
 
   On Wed, Jul 25, 2012 at 5:12 AM, Alex Gaynor alex.gay...@gmail.com
   wrote:
   
   
On Tue, Jul 24, 2012 at 7:37 PM, Nick Coghlan ncogh...@gmail.com
   wrote:
   
On Wed, Jul 25, 2012 at 9:51 AM, Brett Cannon br...@python.org
 wrote:


 On Tue, Jul 24, 2012 at 5:38 PM, Nick Coghlan ncogh...@gmail.com
 
 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   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Speed mailing list
Speed@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


 ___
 Speed mailing list
 Speed@python.org
 http://mail.python.org/mailman/listinfo/speed

___
Speed mailing list
Speed@python.org
http://mail.python.org/mailman/listinfo/speed


Re: [Speed] merging PyPy and Python benchmark suite

2012-07-24 Thread Philip Jenvey

On Jul 24, 2012, at 10:52 AM, Antoine Pitrou wrote:

 On Tue, 24 Jul 2012 10:42:15 -0700
 Alex Gaynor alex.gay...@gmail.com 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

___
Speed mailing list
Speed@python.org
http://mail.python.org/mailman/listinfo/speed


Re: [Speed] merging PyPy and Python benchmark suite

2012-07-24 Thread Brett Cannon
On Tue, Jul 24, 2012 at 1:14 PM, Alex Gaynor alex.gay...@gmail.com wrote:



 On Tue, Jul 24, 2012 at 10:10 AM, Brett Cannon br...@python.org wrote:



 On Mon, Jul 23, 2012 at 7:34 PM, Maciej Fijalkowski fij...@gmail.comwrote:

 On Mon, Jul 23, 2012 at 11:46 PM, Brett Cannon br...@python.org wrote:
 
 
  On Mon, Jul 23, 2012 at 4:39 PM, Armin Rigo ar...@tunes.org wrote:
 
  Hi Brett,
 
  On Mon, Jul 23, 2012 at 10:15 PM, Brett Cannon br...@python.org
 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@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


___
Speed mailing list
Speed@python.org
http://mail.python.org/mailman/listinfo/speed