From fijal at genesilico.pl Tue Apr 1 06:24:16 2008 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Tue, 01 Apr 2008 06:24:16 +0200 Subject: [pypy-dev] PyOpenGL Message-ID: <47F1B8F0.5000803@genesilico.pl> It seems that sentence on a web page saying "The binding is created using the standard (in Python 2.5) ctypes library" is simply a lie :( There is a SWIG binding laying there. There is roughly 20k lines of swig interface code. Not sure how easy would be to wrap automatically, but this binding is definitely not written using ctypes, hence I think we're not going to support this any time soon. :. From amauryfa at gmail.com Tue Apr 1 09:30:19 2008 From: amauryfa at gmail.com (Amaury Forgeot d'Arc) Date: Tue, 1 Apr 2008 09:30:19 +0200 Subject: [pypy-dev] PyOpenGL In-Reply-To: References: <47F1B8F0.5000803@genesilico.pl> Message-ID: Hello, On Tue, Apr 1, 2008 at 6:24 AM, Maciek Fijalkowski wrote: > It seems that sentence on a web page saying "The binding is created > using the standard (in Python 2.5) ctypes library" is simply a lie :( > There is a SWIG binding laying there. There is roughly 20k lines of swig > interface code. Not sure how easy would be to wrap automatically, but > this binding is definitely not written using ctypes, hence I think we're > not going to support this any time soon. It seems that Version 3 of PyOpenGL migrated from SWIG to ctypes: http://pyopengl.sourceforge.net/ctypes/development.html The source code contains tons of blocks like: # /usr/include/GL/freeglut_std.h 385 glutInitWindowPosition = platform.createBaseFunction( 'glutInitWindowPosition', dll=platform.GLUT, resultType=None, argTypes=[c_int,c_int], doc='glutInitWindowPosition( c_int(x), c_int(y) ) -> None', argNames=('x', 'y'), ) which is more pypy-friendly. -- Amaury Forgeot d'Arc From fijall at gmail.com Tue Apr 1 17:48:17 2008 From: fijall at gmail.com (Maciej Fijalkowski) Date: Tue, 1 Apr 2008 17:48:17 +0200 Subject: [pypy-dev] PyOpenGL In-Reply-To: References: <47F1B8F0.5000803@genesilico.pl> Message-ID: <693bc9ab0804010848j4f8b9e19v4bf41cfc0e02edfc@mail.gmail.com> Hum, good news :) I'll try. On Tue, Apr 1, 2008 at 9:30 AM, Amaury Forgeot d'Arc wrote: > Hello, > > > On Tue, Apr 1, 2008 at 6:24 AM, Maciek Fijalkowski wrote: > > It seems that sentence on a web page saying "The binding is created > > using the standard (in Python 2.5) ctypes library" is simply a lie :( > > There is a SWIG binding laying there. There is roughly 20k lines of swig > > interface code. Not sure how easy would be to wrap automatically, but > > this binding is definitely not written using ctypes, hence I think we're > > not going to support this any time soon. > > It seems that Version 3 of PyOpenGL migrated from SWIG to ctypes: > http://pyopengl.sourceforge.net/ctypes/development.html > > The source code contains tons of blocks like: > > # /usr/include/GL/freeglut_std.h 385 > glutInitWindowPosition = platform.createBaseFunction( > 'glutInitWindowPosition', dll=platform.GLUT, resultType=None, > argTypes=[c_int,c_int], > doc='glutInitWindowPosition( c_int(x), c_int(y) ) -> None', > argNames=('x', 'y'), > ) > > which is more pypy-friendly. > > -- > Amaury Forgeot d'Arc > > > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > From bea at changemaker.nu Fri Apr 4 14:25:25 2008 From: bea at changemaker.nu (Beatrice During) Date: Fri, 04 Apr 2008 14:25:25 +0200 Subject: [pypy-dev] Next sprints In-Reply-To: <20080313083931.GA8571@code0.codespeak.net> References: <20080313083931.GA8571@code0.codespeak.net> Message-ID: <47F61E35.700@changemaker.nu> Hi there Just checking to see how things went with the sprint plans? Cheers Bea Armin Rigo wrote: > Hi all, > > This e-mail is about starting the discussion for ideas and plans about > the next sprints. > > What we have planned at the moment: > > * The next PyPy sprint is going to be a small one at PyCon > (http://us.pycon.org/2008/sprints/projects/#pypy). > > * In Leysin, beginning of April, will probably be held a "Paper writing" > sprint. Confirmation and more details should come soon (from Michael > Leuschel and Carl Friedrich). > > Another idea I now about is a follow-up Smalltalk-in-RPython (SPy) > sprint (nothing concrete though). > > It seems that we could starting planning for a regular PyPy development > sprint soon. I'm never tired of inviting people to Leysin but I guess > we could pick another location now (additionally, there are many places > where Spring is a nice season, but Leysin is not one of them). > > > A bientot, > > Armin > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > > -- Bea D?ring Change Maker J?rntorget 3 412 55 G?teborg phone: +46 31 7750940 mobile: +46 734 22 89 06 bea at changemaker.nu www.changemaker.nu From fijal at genesilico.pl Fri Apr 4 18:41:49 2008 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Fri, 04 Apr 2008 18:41:49 +0200 Subject: [pypy-dev] Next sprints In-Reply-To: <47F61E35.700@changemaker.nu> References: <20080313083931.GA8571@code0.codespeak.net> <47F61E35.700@changemaker.nu> Message-ID: <47F65A4D.4000701@genesilico.pl> Beatrice During wrote: > Hi there > > Just checking to see how things went with the sprint > plans? > > Cheers > > Bea > The didn't :. From brett at python.org Wed Apr 9 00:51:58 2008 From: brett at python.org (Brett Cannon) Date: Tue, 8 Apr 2008 15:51:58 -0700 Subject: [pypy-dev] What parts of the sys modules does PyPy implement? Message-ID: A discussion of what parts of the sys module various VMs should be expected to implement has come up on python-dev. I am hoping someone here can let me know what PyPy currently implements. - argv - byteorder - path, path_hooks, meta_path, path_importer_cache, and modules - copyright, hexversion, version, and version_info - displayhook, __displayhook__ - excepthook, __excepthook__, exc_info, and exc_clear - exec_prefix and prefix - executable - exit - flags, py3kwarning, dont_write_bytecode, and warn_options - getfilesystemencoding - get/setprofile - get/settrace, call_tracing - getwindowsversion - maxint and maxunicode - platform - ps1 and ps2 - stdin, stderr, stdout, __stdin__, __stderr__, __stdout__ - tracebacklimit - get/setrecursionlimit - get/setcheckinterval - _getframe and _current_frame - getrefcount - get/setdlopenflags - settscdumps - api_version - winver - dllhandle - float_info - _compact_freelists - _clear_type_cache - subversion - builtin_module_names - callstats - intern -Brett From brunogola at gmail.com Wed Apr 9 01:15:29 2008 From: brunogola at gmail.com (Bruno Gola) Date: Tue, 8 Apr 2008 20:15:29 -0300 Subject: [pypy-dev] What parts of the sys modules does PyPy implement? In-Reply-To: References: Message-ID: Hi, On Tue, Apr 8, 2008 at 7:51 PM, Brett Cannon wrote: > A discussion of what parts of the sys module various VMs should be > expected to implement has come up on python-dev. I am hoping someone > here can let me know what PyPy currently implements. I've made a comparison between python2.4 sys module and the one in pypy, it's really simple and I'm not sure that all the others features are implemented and working as expected, but I hope it helps. This are the features from 2.4 sys that are not present in PyPy's sys: - exc_type - getdlopenflags - getrefcount - pydebug - setdlopenflags -- Bruno Fialho Marques Gola http://www.brunogola.com.br Cel: (11) 9294-5883 From arigo at tunes.org Wed Apr 9 16:40:19 2008 From: arigo at tunes.org (Armin Rigo) Date: Wed, 9 Apr 2008 16:40:19 +0200 Subject: [pypy-dev] What parts of the sys modules does PyPy implement? In-Reply-To: References: Message-ID: <20080409144019.GA17589@code0.codespeak.net> Hi Bruno, On Tue, Apr 08, 2008 at 08:15:29PM -0300, Bruno Gola wrote: > This are the features from 2.4 sys that are not present in PyPy's sys: > - exc_type Actually, exc_type, exc_value and exc_traceback are present in PyPy's sys module but they are not in sys.__dict__. There is a __getattr__ handler on the sys module that provides these attributes in a thread-safe way. > - pydebug Where does this come from? It is not in my Python 2.4 either. A bientot, Armin. From arigo at tunes.org Wed Apr 9 16:49:54 2008 From: arigo at tunes.org (Armin Rigo) Date: Wed, 9 Apr 2008 16:49:54 +0200 Subject: [pypy-dev] What parts of the sys modules does PyPy implement? In-Reply-To: References: Message-ID: <20080409144954.GA18427@code0.codespeak.net> Hi Brett, On Tue, Apr 08, 2008 at 03:51:58PM -0700, Brett Cannon wrote: > A discussion of what parts of the sys module various VMs should be > expected to implement has come up on python-dev. I am hoping someone > here can let me know what PyPy currently implements. PyPy implements the attributes that existed in 2.4 already. We haven't decided anything about the newer attributes but I guess they will be added as we upgrade. Here is the justification for the few 2.4 attributes that are missing (mentioned by Bruno) and the post-2.4 attributes that maybe we will not implement when we upgrade. > - exec_prefix and prefix These ones are stubs at the moment. We haven't thought much about what they should contain and how to install PyPy's standard library in a way that applications like distutils will find it. > - getfilesystemencoding No support for file system encoding yet. > - getwindowsversion > - winver > - dllhandle Not much support for Windows-specific features. Should probably be improved over time. > - getrefcount Makes only sense in CPython. > - get/setdlopenflags > - api_version No support for loading separately-compiled extension modules in PyPy so far. > - settscdumps > - callstats I think these are ways to access internal performance counters of ceval.c. > - _compact_freelists > - _clear_type_cache Looks very much like internal details of CPython. A bientot, Armin. From brett at python.org Wed Apr 9 19:24:03 2008 From: brett at python.org (Brett Cannon) Date: Wed, 9 Apr 2008 19:24:03 +0200 Subject: [pypy-dev] What parts of the sys modules does PyPy implement? In-Reply-To: References: Message-ID: On Tue, Apr 8, 2008 at 4:15 PM, Bruno Gola wrote: > Hi, > > > On Tue, Apr 8, 2008 at 7:51 PM, Brett Cannon wrote: > > A discussion of what parts of the sys module various VMs should be > > expected to implement has come up on python-dev. I am hoping someone > > here can let me know what PyPy currently implements. > > I've made a comparison between python2.4 sys module and the one in > pypy, it's really simple and I'm not sure that all the others features > are implemented and working as expected, but I hope it helps. > > This are the features from 2.4 sys that are not present in PyPy's sys: > - exc_type > - getdlopenflags > - getrefcount > - pydebug What attribute is that? The 2.6 trunk doesn't have it. > - setdlopenflags > -- Thanks for the info, Bruno! -Brett From brett at python.org Wed Apr 9 19:27:18 2008 From: brett at python.org (Brett Cannon) Date: Wed, 9 Apr 2008 19:27:18 +0200 Subject: [pypy-dev] What parts of the sys modules does PyPy implement? In-Reply-To: <20080409144954.GA18427@code0.codespeak.net> References: <20080409144954.GA18427@code0.codespeak.net> Message-ID: On Wed, Apr 9, 2008 at 7:49 AM, Armin Rigo wrote: > Hi Brett, > > > On Tue, Apr 08, 2008 at 03:51:58PM -0700, Brett Cannon wrote: > > A discussion of what parts of the sys module various VMs should be > > expected to implement has come up on python-dev. I am hoping someone > > here can let me know what PyPy currently implements. > > PyPy implements the attributes that existed in 2.4 already. We haven't > decided anything about the newer attributes but I guess they will be > added as we upgrade. Here is the justification for the few 2.4 > attributes that are missing (mentioned by Bruno) and the post-2.4 > attributes that maybe we will not implement when we upgrade. > Thanks, Armin. -Brett From cfbolz at gmx.de Mon Apr 14 23:44:19 2008 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Mon, 14 Apr 2008 23:44:19 +0200 Subject: [pypy-dev] Workshop on Self-sustaining Systems (S3) 2008 | Call for Participation Message-ID: <348899050804141444t607fa2ceqf5cde3b100483b9f@mail.gmail.com> Call for Participation *** Workshop on Self-sustaining Systems (S3) 2008 *** May 15-16, 2008 Hasso-Plattner-Institut Potsdam, Germany http://www.swa.hpi.uni-potsdam.de/s3/ ---------------------------------------------------------------------- [ Important dates ] * Early registration: April 20, 2008 * S3 workshop: May 15-16, 2008 [ Program ] * 3 invited talks * 6 technical papers * http://www.swa.hpi.uni-potsdam.de/s3/program/ [ Invited speakers ] * Ian Piumarta (Viewpoints) * Dan Ingalls (Sun Labs) * Richard P. Gabriel (IBM Research) [ Registration ] * http://www.swa.hpi.uni-potsdam.de/s3/registration/ We hope to see you in Potsdam, Kim Rose and Robert Hirschfeld From lac at openend.se Tue Apr 15 02:39:57 2008 From: lac at openend.se (Laura Creighton) Date: Tue, 15 Apr 2008 02:39:57 +0200 Subject: [pypy-dev] If we are getting somewhere with a port of pygame ... Message-ID: <200804150039.m3F0dvjS007933@theraft.openend.se> now would be a great time to let the pygame list know. Laura, going back to vacation, and not going to be the person who tells them if there is any telling that needs doing. ------- Forwarded Message Return-Path: owner-pygame-users at seul.org Delivery-Date: Mon Apr 14 02:04:47 2008 Date: Mon, 14 Apr 2008 10:04:39 +1000 From: "=?ISO-8859-1?Q?Ren=E9_Dudfield?=" To: pygame-users at seul.org Subject: Re: [pygame] SDL ctypes ImportError In-Reply-To: hello, pygame-ctypes has been abandoned. The authors email is in the docs if you'd like to email him. You might get a good response on the ctypes list to your issue. cheers, On Mon, Apr 14, 2008 at 9:50 AM, PyMike wrote: > Hi, > > I've been interested in making something similar to pygame, but completely > in python. I came across http://www.pygame.org/ctypes/ and after I installed > the SDL lib I get this error when I run __init__.py... > > >>> > Traceback (most recent call last): > File "C:\Python25\Lib\site-packages\SDL\dll.py", line 221, in > _dll = SDL_DLL('SDL', 'SDL_Linked_Version') > File "C:\Python25\Lib\site-packages\SDL\dll.py", line 54, in __init__ > _platform_library_name(library_name) > ImportError: Dynamic library "SDL" was not found > >>> > > ...and I have all the SDL DLLs that are included pygame in the same dir as > the SDL lib. I want to be able to include SDL with the pkg and not have > users have to install it into their system folder for the python lib to > work. > > Please help! > -- > - pymike (pymike93.googlepages.com) ------- End of Forwarded Message From fijal at genesilico.pl Tue Apr 15 07:34:01 2008 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Tue, 15 Apr 2008 07:34:01 +0200 Subject: [pypy-dev] If we are getting somewhere with a port of pygame ... In-Reply-To: <200804150039.m3F0dvjS007933@theraft.openend.se> References: <200804150039.m3F0dvjS007933@theraft.openend.se> Message-ID: <48043E49.4000902@genesilico.pl> Laura Creighton wrote: > now would be a great time to let the pygame list know. > > Laura, going back to vacation, and not going to be the person who > tells them if there is any telling that needs doing. > > No, we're not. We're basically using pyglet for graphics. :. From Martin.vonLoewis at hpi.uni-potsdam.de Wed Apr 16 09:21:03 2008 From: Martin.vonLoewis at hpi.uni-potsdam.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 16 Apr 2008 09:21:03 +0200 Subject: [pypy-dev] S3 Call for Participation Message-ID: <4805A8DF.8030504@hpi.uni-potsdam.de> ---------------------------------------------------------------------- Call for Participation *** Workshop on Self-sustaining Systems (S3) 2008 *** May 15-16, 2008 Hasso-Plattner-Institut Potsdam, Germany http://www.swa.hpi.uni-potsdam.de/s3/ ---------------------------------------------------------------------- [ Important dates ] * Early registration: April 20, 2008 * S3 workshop: May 15-16, 2008 [ Program ] * 3 invited talks * 6 technical papers * http://www.swa.hpi.uni-potsdam.de/s3/program/ [ Invited speakers ] * Ian Piumarta (Viewpoints) * Dan Ingalls (Sun Labs) * Richard P. Gabriel (IBM Research) [ Registration ] * http://www.swa.hpi.uni-potsdam.de/s3/registration/ We hope to see you in Potsdam, Kim Rose and Robert Hirschfeld ---------------------------------------------------------------------- From arigo at tunes.org Tue Apr 22 12:01:05 2008 From: arigo at tunes.org (Armin Rigo) Date: Tue, 22 Apr 2008 12:01:05 +0200 Subject: [pypy-dev] io-improvements branch Message-ID: <20080422100104.GA24646@code0.codespeak.net> Hi, I reviewed the io-improvements branch that speeds up operations like os.read() by avoiding many copies of the data. First note that the branch also kills coalloc, which proved to be not useful (cfbolz: objections?). There is a failure in test_lloperation.py that shows that the llinterp doesn't implement the new operations malloc_nonmovable(_varsize). But first, we need to add a test in rpython/memory/test/test_gc.py that uses these operations (as well as gc_can_move, which I think is also untested in the llinterp). When that's done I think we can run all tests and if they pass, merge the branch. A bientot, Armin From anto.cuni at gmail.com Tue Apr 22 22:56:55 2008 From: anto.cuni at gmail.com (Antonio Cuni) Date: Tue, 22 Apr 2008 22:56:55 +0200 Subject: [pypy-dev] [Fwd: Re: Fan Programing Language] Message-ID: <480E5117.2040306@gmail.com> Hi Niko, hi all, there is an interesting thread going on on the jvm-languages mailing list; among the other things, I discovered that the JVM can handle the exception much faster if you override the fillInStack method to do nothing instead of building the traceback. I think that since we don't rely on jvm tracebacks for exceptions, overriding such a method in all our exception classes might lead to some speedup. Note that hotspot is smart enough to optimize well the case in which you raise a prebuilt exception, but in all cases in which you have to dynamically construct a new exception (e.g., OperationError) it can't. ciao, Anto -------- Original Message -------- Subject: [jvm-l] Re: Fan Programing Language Date: Tue, 22 Apr 2008 15:05:04 -0400 From: John Cowan Reply-To: jvm-languages at googlegroups.com To: jvm-languages at googlegroups.com References: <200804221911.40276.jon at ffconsultancy.com> <480E31B8.5090504 at gmail.com> <200804221941.11608.jon at ffconsultancy.com> On Tue, Apr 22, 2008 at 2:41 PM, Jon Harrop wrote: > > 2) you are allocating a new exception every time; the optimization > > described here [1] works only if the exception is pre-allocated. > > [1] http://blogs.sun.com/jrose/entry/longjumps_considered_inexpensive > > I think that is not thread safe. Specifically, when the branch conveys > information (passed as arguments using a tail call, or embedded in the > exception) then you must use a locally allocated exception, right? Yes, you must. However, what makes allocating an exception expensive is the fillInStack method, which has to walk the JVM stack. If you override that in your exception class with a do-nothing method, then locally allocating exceptions is very cheap. -- GMail doesn't have rotating .sigs, but you can see mine at http://www.ccil.org/~cowan/signatures --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages at googlegroups.com To unsubscribe from this group, send email to jvm-languages-unsubscribe at googlegroups.com For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~--- From paul.degrandis at gmail.com Tue Apr 22 23:25:38 2008 From: paul.degrandis at gmail.com (Paul deGrandis) Date: Tue, 22 Apr 2008 17:25:38 -0400 Subject: [pypy-dev] [Fwd: Re: Fan Programing Language] In-Reply-To: <480E5117.2040306@gmail.com> References: <480E5117.2040306@gmail.com> Message-ID: <9c0bb8a00804221425u2e69f00dgbf59f77eb1bd818d@mail.gmail.com> Anto, Niko had previously discovered this and we dscussed coming up with a way to do it. This is a good motivator to stepping up and getting it done. Thanks for hitting the list with this. Paul On 4/22/08, Antonio Cuni wrote: > Hi Niko, > hi all, > > there is an interesting thread going on on the jvm-languages mailing > list; among the other things, I discovered that the JVM can handle the > exception much faster if you override the fillInStack method to do > nothing instead of building the traceback. > > I think that since we don't rely on jvm tracebacks for exceptions, > overriding such a method in all our exception classes might lead to some > speedup. > > Note that hotspot is smart enough to optimize well the case in which you > raise a prebuilt exception, but in all cases in which you have to > dynamically construct a new exception (e.g., OperationError) it can't. > > ciao, > Anto > > -------- Original Message -------- > Subject: [jvm-l] Re: Fan Programing Language > Date: Tue, 22 Apr 2008 15:05:04 -0400 > From: John Cowan > Reply-To: jvm-languages at googlegroups.com > To: jvm-languages at googlegroups.com > References: > > <200804221911.40276.jon at ffconsultancy.com> <480E31B8.5090504 at gmail.com> > <200804221941.11608.jon at ffconsultancy.com> > > > On Tue, Apr 22, 2008 at 2:41 PM, Jon Harrop wrote: > > > > 2) you are allocating a new exception every time; the optimization > > > described here [1] works only if the exception is pre-allocated. > > > [1] http://blogs.sun.com/jrose/entry/longjumps_considered_inexpensive > > > > I think that is not thread safe. Specifically, when the branch conveys > > information (passed as arguments using a tail call, or embedded in the > > exception) then you must use a locally allocated exception, right? > > Yes, you must. However, what makes allocating an exception expensive > is the fillInStack method, which has to walk the JVM stack. If you > override that in your exception class with a do-nothing method, then > locally allocating exceptions is very cheap. > > -- > GMail doesn't have rotating .sigs, but you can see mine at > http://www.ccil.org/~cowan/signatures > > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google > Groups "JVM Languages" group. > To post to this group, send email to jvm-languages at googlegroups.com > To unsubscribe from this group, send email to > jvm-languages-unsubscribe at googlegroups.com > For more options, visit this group at > http://groups.google.com/group/jvm-languages?hl=en > -~----------~----~----~----~------~----~------~--~--- > > > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > From niko at alum.mit.edu Wed Apr 23 06:22:42 2008 From: niko at alum.mit.edu (Niko Matsakis) Date: Wed, 23 Apr 2008 06:22:42 +0200 Subject: [pypy-dev] [Fwd: Re: Fan Programing Language] In-Reply-To: <480E5117.2040306@gmail.com> References: <480E5117.2040306@gmail.com> Message-ID: <2F5B0247-7980-430C-8C10-B9CA598276B5@alum.mit.edu> > there is an interesting thread going on on the jvm-languages mailing > list; among the other things, I discovered that the JVM can handle > the exception much faster if you override the fillInStack method to > do nothing instead of building the traceback. I didn't know about overriding the fillInStack method, that should be fairly easy to do. Niko From charles.nutter at sun.com Fri Apr 25 06:05:41 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Thu, 24 Apr 2008 23:05:41 -0500 Subject: [pypy-dev] [Fwd: Re: Fan Programing Language] In-Reply-To: <2F5B0247-7980-430C-8C10-B9CA598276B5@alum.mit.edu> References: <480E5117.2040306@gmail.com> <2F5B0247-7980-430C-8C10-B9CA598276B5@alum.mit.edu> Message-ID: <48115895.4050606@sun.com> Niko Matsakis wrote: >> there is an interesting thread going on on the jvm-languages mailing >> list; among the other things, I discovered that the JVM can handle >> the exception much faster if you override the fillInStack method to >> do nothing instead of building the traceback. > > I didn't know about overriding the fillInStack method, that should be > fairly easy to do. Trivial even. And if you are just using exceptions as a message-passing or stack-unrolling mechanism, just instantiate it once per thread. - Charlie From anto.cuni at gmail.com Fri Apr 25 11:25:17 2008 From: anto.cuni at gmail.com (Antonio Cuni) Date: Fri, 25 Apr 2008 11:25:17 +0200 Subject: [pypy-dev] [Fwd: Re: Fan Programing Language] In-Reply-To: <48115895.4050606@sun.com> References: <480E5117.2040306@gmail.com> <2F5B0247-7980-430C-8C10-B9CA598276B5@alum.mit.edu> <48115895.4050606@sun.com> Message-ID: <4811A37D.4030304@gmail.com> Charles Oliver Nutter wrote: > Niko Matsakis wrote: >>> there is an interesting thread going on on the jvm-languages mailing >>> list; among the other things, I discovered that the JVM can handle >>> the exception much faster if you override the fillInStack method to >>> do nothing instead of building the traceback. >> >> I didn't know about overriding the fillInStack method, that should be >> fairly easy to do. > > Trivial even. I tried to manually override fillInStackTrace by editing the generated .j file; the resulting pypy-jvm runs about 8% faster on richards and 14% on pystone. > And if you are just using exceptions as a message-passing or > stack-unrolling mechanism, just instantiate it once per thread. I think we already do that; all the standard exceptions are prebuilt objects, stored as public static fields. I don't know if there are other exceptions that are used inside the interpreter to unroll the stack but which are not prebuilt. ciao, anto From arigo at tunes.org Fri Apr 25 13:56:33 2008 From: arigo at tunes.org (Armin Rigo) Date: Fri, 25 Apr 2008 13:56:33 +0200 Subject: [pypy-dev] [Fwd: Re: Fan Programing Language] In-Reply-To: <4811A37D.4030304@gmail.com> References: <480E5117.2040306@gmail.com> <2F5B0247-7980-430C-8C10-B9CA598276B5@alum.mit.edu> <48115895.4050606@sun.com> <4811A37D.4030304@gmail.com> Message-ID: <20080425115633.GA1322@code0.codespeak.net> Hi Antonio, On Fri, Apr 25, 2008 at 11:25:17AM +0200, Antonio Cuni wrote: > I don't know if there are other exceptions that are used inside the > interpreter to unroll the stack but which are not prebuilt. We tried to avoid all non-prebuilt exceptions for control flow purposes. I think that in any performance-critical place there is only OperationError that could possibly be instantiated at run-time. A bientot, Armin. From anto.cuni at gmail.com Sat Apr 26 12:52:33 2008 From: anto.cuni at gmail.com (Antonio Cuni) Date: Sat, 26 Apr 2008 12:52:33 +0200 Subject: [pypy-dev] [Fwd: Re: Fan Programing Language] In-Reply-To: <20080425115633.GA1322@code0.codespeak.net> References: <480E5117.2040306@gmail.com> <2F5B0247-7980-430C-8C10-B9CA598276B5@alum.mit.edu> <48115895.4050606@sun.com> <4811A37D.4030304@gmail.com> <20080425115633.GA1322@code0.codespeak.net> Message-ID: <48130971.8030600@gmail.com> Armin Rigo wrote: > We tried to avoid all non-prebuilt exceptions for control flow purposes. > I think that in any performance-critical place there is only > OperationError that could possibly be instantiated at run-time. I supposed this, but I was not sure. Good news :-). ciao, Anto From fijall at gmail.com Mon Apr 28 12:38:52 2008 From: fijall at gmail.com (Maciej Fijalkowski) Date: Mon, 28 Apr 2008 12:38:52 +0200 Subject: [pypy-dev] microbench & pybench Message-ID: <693bc9ab0804280338h77c82c45u6acc5288333bd8f9@mail.gmail.com> First: benchmarks (especially those which are micro) sucks. It seems that these days we're vastly faster on microbenchs than cpython 2.5 and way slower on some tests from pybench (like small tuple operations). Here are some results (it's the other way around than on tuatara, higher is better, more than 1 means faster than cpython). This only showcases how much microbenchmarks are dependand on tight loop speed in my opinion :-( Pybench is slightly smarter in this regard. 0.22x slower on test_unicode.test_bad_case_python2_5() 0.26x slower on test_formatting.test_format_unicode() 0.26x slower on test_formatting.test_format_long() 0.78x slower on test_exception.test_reraise() 0.83x slower on test_bltn.test_call_fabs() 0.84x slower on test_exception.test_except_specific_builtin_exception() 0.87x slower on test_exception.test_except_multiple_builtin_exception() 0.87x slower on test_bltn.test_call_sin() 0.91x slower on test_exception.test_except_specific_user_exception() 0.94x slower on test_count1.test_loop_unrolled() 0.94x slower on test_count1.test_loop() 0.97x slower on test_dict.test_dict_creation_mode3() 1.01x slower on test_exception.test_except_multiple_user_exception() 1.10x slower on test_bltn.test_isinstance2() 1.12x slower on test_count1.test_call_function_with_arguments_in_cellvars() 1.15x slower on test_count1.test_count_in_attr() 1.15x slower on test_dispatch.test_dispatch_nop() 1.18x slower on test_unicode.test_find_pattern1() 1.19x slower on test_bltn.test_isinstance1() 1.19x slower on test_count1.test_loop_other_count() 1.23x slower on test_exception.test_raise_builtin_exception() 1.23x slower on test_count1.test_call_function_without_arguments_in_cellvars() 1.24x slower on test_count1.test_call_method_of_old_style_class() 1.28x slower on test_count1.test_count_in_global() 1.29x slower on test_exception.test_raise_user_exception() 1.29x slower on test_count1.test_call_method_of_new_style_class() 1.29x slower on test_bltn.test_isinstance3() 1.30x slower on test_count1.test_count_in_global2() 1.30x slower on test_formatting.test_number_formatting() 1.32x slower on test_create1.test_simple_loop_with_new_style_class_new() 1.35x slower on test_exception.test_try_except_finally() 1.36x slower on test_count1.test_count_in_dict() 1.37x slower on test_exception.test_try_except_else() 1.38x slower on test_count1.test_call_nested_function_many_args() 1.39x slower on test_dict.test_dict_class_dict_getmethod() 1.39x slower on test_exception.test_try_except() 1.40x slower on test_count1.test_call_nested_function() 1.40x slower on test_create1.test_simple_loop() 1.42x slower on test_dict.test_dict_instance_setattr_instance_dict() 1.44x slower on test_dict.test_dict_instance_setnewattr_instance_dict() 1.45x slower on test_count1.test_call_nested_function_other_count() 1.49x slower on test_list.test_list_setitem() 1.55x slower on test_list.test_list_extend() 1.59x slower on test_count1.test_call_function() 1.63x slower on test_dict.test_dict_getitem() 1.64x slower on test_count1.test_count_in_slot() 1.65x slower on test_formatting.test_dict_formatting() 1.68x slower on test_dict.test_dict_creation_mode1() 1.72x slower on test_unicode.test_find_pattern2() 1.75x slower on test_dict.test_dict_setitem2() 1.75x slower on test_dict.test_dict_raw_range() 1.75x slower on test_dict.test_dict_creation_mode2() 1.76x slower on test_dict.test_dict_instance_getattr_instance_dict() 1.80x slower on test_list.test_list_append() 1.92x slower on test_create1.test_simple_loop_with_old_style_class_creation() 2.01x slower on test_formatting.test_simple_formatting() 2.12x slower on test_formatting.test_evil_formatting() 2.27x slower on test_create1.test_simple_loop_with_new_style_class_creation() 2.37x slower on test_list.test_list_getitem() 2.55x slower on test_dict.test_dict_setitem1() 2.59x slower on test_unicode.test_find_worstcase() 2.67x slower on test_unicode.test_find_pattern4() 2.95x slower on test_list.test_list_slice() 3.24x slower on test_unicode.test_count_worstcase() 3.27x slower on test_exception.test_instantiate_user_exception() 3.64x slower on test_exception.test_instantiate_builtin_exception() 3.73x slower on test_formatting.test_repr_formatting() 4.22x slower on test_unicode.test_find_pattern8() 6.32x slower on test_unicode.test_find_pattern16() PyPy-c compiled using --gc=generation --gcrootfinder=asmgcc --faassen cpython 2.5 from release On pybench we're 70% slower in general than cpython, 55% slower with --objspace-std-withstrslice, comparison table of withstrslice (positive numbers means slowdown compared to cpython, negative means speedup, in %): Tests: per run per oper. diff *) ------------------------------------------------------------------------ BuiltinFunctionCalls: 37.70 ms 0.30 us -7.82% BuiltinMethodLookup: 133.65 ms 0.25 us +47.27% CompareFloats: 71.55 ms 0.16 us +5.53% CompareFloatsIntegers: 376.70 ms 0.84 us +339.04% CompareIntegers: 69.20 ms 0.08 us -19.25% CompareInternedStrings: 91.60 ms 0.18 us +51.66% CompareLongs: 71.55 ms 0.16 us +19.65% CompareStrings: 104.65 ms 0.21 us +17.12% CompareUnicode: 67.95 ms 0.18 us -25.78% ConcatStrings: 28.30 ms 0.19 us -70.40% ConcatUnicode: 442.10 ms 2.95 us +225.67% CreateInstances: 81.60 ms 1.94 us +20.18% CreateStringsWithConcat: 46.40 ms 0.23 us +8.54% CreateUnicodeWithConcat: 107.45 ms 0.54 us +7.56% DictCreation: 104.65 ms 0.70 us +77.67% DictWithFloatKeys: 311.75 ms 0.52 us +135.46% DictWithIntegerKeys: 171.65 ms 0.29 us +113.89% DictWithStringKeys: 105.70 ms 0.18 us +33.04% ForLoops: 147.00 ms 14.70 us +145.00% IfThenElse: 79.15 ms 0.12 us +4.77% ListSlicing: 52.00 ms 14.86 us +63.27% NestedForLoops: 93.00 ms 0.27 us +126.83% NormalClassAttribute: 185.40 ms 0.31 us +114.09% NormalInstanceAttribute: 113.25 ms 0.19 us +40.25% PythonFunctionCalls: 99.55 ms 0.60 us +21.92% PythonMethodCalls: 82.75 ms 1.10 us +23.69% Recursion: 86.65 ms 6.93 us +46.99% SecondImport: 51.90 ms 2.08 us +44.17% SecondPackageImport: 34.95 ms 1.40 us -7.66% SecondSubmoduleImport: 77.75 ms 3.11 us +52.45% SimpleComplexArithmetic: 67.75 ms 0.31 us +47.60% SimpleDictManipulation: 105.70 ms 0.35 us +104.05% SimpleFloatArithmetic: 80.20 ms 0.15 us -4.18% SimpleIntFloatArithmetic: 87.15 ms 0.13 us +21.72% SimpleIntegerArithmetic: 89.20 ms 0.14 us +22.95% SimpleListManipulation: 54.50 ms 0.20 us +21.92% SimpleLongArithmetic: 63.80 ms 0.39 us +64.01% SmallLists: 66.30 ms 0.26 us -6.09% SmallTuples: 250.55 ms 1.04 us +270.36% SpecialClassAttribute: 197.45 ms 0.33 us +127.61% SpecialInstanceAttribute: 114.35 ms 0.19 us -14.41% StringMappings: 104.10 ms 0.83 us +30.86% StringPredicates: 68.25 ms 0.24 us -10.02% StringSlicing: 64.30 ms 0.37 us +17.87% TryExcept: 105.80 ms 0.07 us +15.82% TryRaiseExcept: 37.55 ms 2.50 us +14.31% TupleSlicing: 91.65 ms 0.87 us +43.54% UnicodeMappings: 132.60 ms 7.37 us +67.11% UnicodePredicates: 56.95 ms 0.25 us -15.75% UnicodeSlicing: 169.15 ms 0.97 us +123.60% ------------------------------------------------------------------------ Average round time: 6238.00 ms +55.21% Cheers, fijal From santagada at gmail.com Mon Apr 28 13:20:49 2008 From: santagada at gmail.com (Leonardo Santagada) Date: Mon, 28 Apr 2008 12:20:49 +0100 Subject: [pypy-dev] microbench & pybench In-Reply-To: <693bc9ab0804280338h77c82c45u6acc5288333bd8f9@mail.gmail.com> References: <693bc9ab0804280338h77c82c45u6acc5288333bd8f9@mail.gmail.com> Message-ID: On 28/04/2008, at 11:38, Maciej Fijalkowski wrote: > First: benchmarks (especially those which are micro) sucks. It seems > that these days we're vastly faster on microbenchs than cpython 2.5 > and way slower on some tests from pybench (like small tuple > operations). Here are some results (it's the other way around than on > tuatara, higher is better, more than 1 means faster than cpython). > This only showcases how much microbenchmarks are dependand on tight > loop speed in my opinion :-( Pybench is slightly smarter in this > regard. One important question is, can we profile some real python programs and see the same behavior in slowdowns? Because right now what you are doing is comparing two synthetic benchmarks, which I think is not as usefull for pypython. The python interpreter needs better benchmarks... that is a given.