Mailman 3 June 2015 - pypy-dev

use as benchmark pypy vs python if you please
by Dima Tisnek 13 Sep '15

13 Sep '15

Attached is n-queens solver (pardon my naive algorithm), it runs: python 2.7.6: 17s pypy 2.4.0 alpha: 23s same nojit: 32s I've tried similar-looking algorithm for another problem before, and has similar results -- somehow pypy was slower. feel free to investigate / tweak or even use on speed.pypy.org

4 4

Poor performance for Krakatau
by Robert Grosse 10 Aug '15

10 Aug '15

In some cases, Pypy performs worse than CPython when running Krakatau, and it has gotten a lot worse from 2.3 to 2.5 My benchmark is https://github.com/Storyyeller/Krakatau/tree/pypy_benchmark (for future reference, commit d889c7f44723e6d66a3630681f0385f173317dc9) You can run it with pypy Krakatau\benchmark.py -path <path to Java rt.jar> I get the following timings CPython: 17.43s Pypy 2.3: 38.48s (build pypy-c-jit-71056-c8e3b8cbc843-win32) Pypy 2.4: 39.92s (build pypy-c-jit-72200-375133966c12-win32) Pypy 2.5: 49.94s (build pypy-c-jit-74404-9fd586fe0fe5-win32) Not only was it slower than CPython to begin with, but it got much worse recently.

3 4

For Donations, List How Much is Left (or Spent)?
by Donald Stufft 03 Aug '15

03 Aug '15

Hey! So out of someone complaining about PyPy's lack of an up to date port of Python 3, it struck me that for someone just now looking into PyPy it looks like PyPy is sitting on almost 60k USD in order to port PyPy3 from 3.2 to 3.4. However the reality (via fijall) is that most of it, roughly 50k has already been spent going from nothing to 3.2. It might be a good idea to have the numbers reflect how much of the fundraised money has already been spent so that people get a more accurate reflection on just how much money there is left to take the task at hand from where it is now to where folks want it to be. My assumption is that people are going to feel a lot more like their money is going to be useful if it's not just adding onto the tail of what looks to be a fairly major pot of money and thus are more likely to actually donate. This of course doesn't just apply to Python 3 porting, the same thing is true for all of the fundraisers that PyPy is running. Without more information I have no way to evaluate if PyPy is sitting with cash reserves for that task and it's waiting for someone to work on it, or if it's mostly gone and it needs more funding to get any more effort applied to it. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

6 9

Re: [pypy-dev] A simple file reading is 2x slow wrt CPython
by Laura Creighton 01 Jul '15

01 Jul '15

In a message of Mon, 29 Jun 2015 23:53:21 +0200, Ozan Çağlayan writes: >Well I tried again but cant reproduce it. BTW cut down the whole code to 4 >seconds with PyPy vs 28 seconds on CPython. The original C++ code might be >slower than this, i'll check it. > >Thanks for fast replies, contributions, kindness :) You are welcome for the kindness. Try to encourage it wherever you go. So _very_ many things go better with kindness, and so many people think that it is in some way beneath them to be kind, to our great sorrow. Laura

3 2

Re: [pypy-dev] A simple file reading is 2x slow wrt CPython
by Laura Creighton 29 Jun '15

29 Jun '15

In a message of Mon, 29 Jun 2015 21:40:38 +0200, Ozan Çağlayan writes: >Hi, > >Yes I thought of the evident question and I think I can avoid keeping >everything in memory by doing two passes of the file. > >Regarding __slots__, it seemed to help using CPython but pypy + slots >crashed/trashed in a very hardcore way :) PyPy always compacts instances as if they had slots, so it should make no difference. If using it makes things crash, then we have a really horrible bug -- can you post the smallest code that provokes this? (Though my bet is that you have somehting else wrong, not the slots ...) Laura

2 1

A simple file reading is 2x slow wrt CPython
by Ozan Çağlayan 29 Jun '15

29 Jun '15

Hi, I just downloaded PyPy 2.6.0 just to play with it. I have a simple line-by-line file reading example where the file is 324MB. Code: # Not doing this import crashes PyPy with MemoryError?? from io import open a = 0 f = open(fname) for line in f.readlines(): a += len(line) f.close() PyPy: Python 2.7.9 (295ee98b69288471b0fcf2e0ede82ce5209eb90b, Jun 01 2015, 17:30:13) [PyPy 2.6.0 with GCC 4.9.2] on linux2 real 0m6.068s user 0m4.582s sys 0m0.846s CPython (2.7.10) real 0m3.799s user 0m2.851s sys 0m0.860s Am I doing something wrong or is this expected? Thanks! -- Ozan Çağlayan Research Assistant Galatasaray University - Computer Engineering Dept. http://www.ozancaglayan.com

7 16

pypy blocked at RPyGilAcquire ()
by Yicong Huang 25 Jun '15

25 Jun '15

Hi, We embedded Pypy in C++ code, and found out if Pypy was initialized twice it would block at function RpyGilAcquire(). Here is the case: rpython_startup_code(); res = pypy_setup_home("...") res = pypy_execute_source_ptr(...) //Some code here rpython_startup_code(); res = pypy_setup_home("...") res = pypy_execute_source_ptr(...) We found pypy blocked at second pypy_execute_source_pty(...), the detail call stack are #0 0x0000003fea40b1c0 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f8543087a1d in RPyGilAcquire () from /usr/ali/odps-pypy/libpypy-c.so #2 0x00007f85425a5f8d in pypy_g_pypy_execute_source_ptr () from /usr/ali/odps-pypy/libpypy-c.so #3 0x00007f85423a6743 in pypy_execute_source_ptr () from /usr/ali/odps-pypy/libpypy-c.so The reason that we initialized pypy twice is that we would like to get a clean environment to execute without any global variables' pollution from the first run.

4 3

Final CFP: 2015 Workshop on Exascale Multi/many Core Computing Systems (E-MuCoCoS) (fwd)
by Laura Creighton 25 Jun '15

25 Jun '15

This showed up in python-list, of all places, apparantly posted to comp.lang.python In case somebody wants to go to Portugal in September. Note: I am still a little hazy on what Exascale means, and therefore if we do it. :) Laura ------- Forwarded Message From: SP <sabri.pllana(a)gmail.com> Injection-Date: Tue, 23 Jun 2015 09:51:23 +0000 To: python-list(a)python.org CALL FOR PAPERS 2015 Workshop on Exascale Multi/many Core Computing Systems (E-MuCoCoS) - - Paper submission deadline: June 30, 2015 (firm deadline) - - Workshop proceedings are published by the IEEE * CONTEXT Exascale computing will revolutionize computational science and engineering by providing 1000x the capabilities of currently available computing systems, while having a similar power footprint. The HPC community is working towards the development of the first Exaflop computer (expected around 2020) after reaching the Petaflop milestone in 2008. There are concerns that computer designs based on existing multi-core and many-core solutions will not scale to Exascale considering technical challenges (such as, productivity, energy consumption or reliability) and reasonable economic constraints. Therefore, novel multi-core and many-core solutions are required to reach Exascale. E-MuCoCoS will be organized in conjunction with the 18th IEEE Conference on Computational Science and Engineering (CSE 2015), Porto, Portugal, October 21 - 23, 2015. Previous editions of MuCoCoS workshop include: MuCoCoS 2014 (Porto, PT), MuCoCoS 2013 (Edinburgh, UK), MuCoCoS 2012 (SLC, US), MuCoCoS 2011 (Seoul, KR), MuCoCoS 2010 (Krakow, PL), MuCoCoS 2009 (Fukuoka, JP), MuCoCoS 2008 (Barcelona, ES). * TOPICS OF INTEREST E-MuCoCoS focuses on multi/many core languages, system software and architectural solutions towards Exascale computing systems. The topics of the workshop include but are not limited to: :: Methods and tools for preparing applications for Exascale :: Programming models, languages, libraries and compilation techniques :: Run-time systems and hardware support :: Patterns, algorithms and data structures :: Performance analysis, modeling, optimization and tuning * SUBMISSION GUIDELINES - - The papers should be prepared using the IEEE format, and no longer than 6 pages. Submitted papers will be carefully evaluated based on originality, significance to workshop topics, technical soundness, and presentation quality. - - Submission of the paper implies that should the paper be accepted, at least one of the authors will register and present the paper at the workshop. - - Please submit your paper (as PDF) electronically using the online submission system https://easychair.org/conferences/?conf=emucocos2015 * IMPORTANT DATES - - Submission: June 30, 2015 (firm deadline) - - Notification: July 28, 2015 - - Camera ready: September 4, 2015 - - Registration: September 4, 2015 - - Workshop: October 20, 2015 * PROGRAM COMMITTEE - - Erika Abraham, RWTH Aachen University (DE) - - Siegfried Benkner, University of Vienna (AT) - - Eduardo Cesar, UAB (ES) - - Jiri Dokulil, University of Vienna, (AT) - - Norbert Eicker, J�lich Supercomputing Centre (DE) - - Franz Franchetti, Carnegie Mellon University (US) - - Samir Genaim, Universidad Complutense de Madrid (ES) - - Houcine Hassan, Universitat Politecnica de Valencia, (ES) - - Atsushi Hori, RIKEN AICS (JP) - - Einar Broch Johnsen, University of Oslo, (NO) - - Christos Kartsaklis, Oak Ridge National Laboratory (US) - - J�rg Keller, FernUniversit�t in Hagen (DE) - - Christoph Kessler, Link�ping University (SE) - - Joanna Kolodziej, Cracow University of Technology (PL) - - Ivan Kondov, Karlsruhe Institute of Technology (DE) - - Erwin Laure, KTH/PDC (SE) - - Renato Miceli, SENAI CIMATEC (BR) - - Lasse Natvig, Norwegian University of Science and Technology (NO) - - Dana Petcu, West University of Timisoara (RO) - - Uwe Schwiegelshohn, TU Dortmund University (DE) - - Achim Streit, Karlsruhe Institute for Technology (DE) - - Osamu Tatebe, University of Tsukuba, (JP) - - Josef Weidendorfer, TUM (DE) * WORKSHOP CHAIR - - Sabri Pllana, Linnaeus University, Sweden http://homepage.lnu.se/staff/saplaa/ - -- https://mail.python.org/mailman/listinfo/python-list ------- End of Forwarded Message

3 2

[PSF-Board-Public] PSF Meeting Minutes - 2015-06-08 (fwd)
by lac＠openend.se 24 Jun '15

24 Jun '15

------- Forwarded Message I've trimmed the minutes. Return-Path: <psf-board-public-bounces+lac=openend.se(a)python.org> Received: from mail.python.org (mail.python.org [82.94.164.166]) From: Diana Clarke <diana.joan.clarke(a)gmail.com> To: Public PSF Board List <psf-board-public(a)python.org>, PSF Members List <psf-members(a)python.org> Subject: [PSF-Board-Public] PSF Meeting Minutes - 2015-06-08 Hi folks: The first PSF board meeting for the 2015/2016 term was held on June 8, 2015. Those meeting minutes can be found here: https://www.python.org/psf/records/board/minutes/2015-06-08/ <snip> The PSF also formally recognized the Scientific Python Working Group. More information about the working group can be found here: https://wiki.python.org/psf/ScientificWG https://pyfound.blogspot.com/2015/05/psfnumfocus-joint-working-group-on.html For more updates from the PSF, please check out our blog and follow us on Twitter. https://twitter.com/ThePSF https://pyfound.blogspot.com/ Cheers, - --diana _______________________________________________ PSF-Board-Public mailing list PSF-Board-Public(a)python.org https://mail.python.org/mailman/listinfo/psf-board-public ------- End of Forwarded Message Do we have any presence in that wg? We should probably have somebody be a member just to be on top of what the PSF, at any rate, thinks is scientific python .... Laura

1 0

tkinter tests broken
by Armin Rigo 24 Jun '15

24 Jun '15

Hi Amaury, In fd331e4bf733 you did an untested change to the tkinter library; as it turns out, the CPython tests find problems: http://buildbot.pypy.org/summary/longrepr?testname=unmodified&builder=pypy-… Can you fix the situation? Thanks! Armin

2 3