Mailman 3 April 2008 - pypy-dev

microbench & pybench
by Maciej Fijalkowski April 28, 2008

April 28, 2008

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

2 1

[Fwd: Re: Fan Programing Language]
by Antonio Cuni April 26, 2008

April 26, 2008

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 <johnwcowan(a)gmail.com> Reply-To: jvm-languages(a)googlegroups.com To: jvm-languages(a)googlegroups.com References: <bfb6e3b0-8e81-4e38-95ea-2ce1187558fc(a)u69g2000hse.googlegroups.com> <200804221911.40276.jon(a)ffconsultancy.com> <480E31B8.5090504(a)gmail.com> <200804221941.11608.jon(a)ffconsultancy.com> On Tue, Apr 22, 2008 at 2:41 PM, Jon Harrop <jon(a)ffconsultancy.com> 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(a)googlegroups.com To unsubscribe from this group, send email to jvm-languages-unsubscribe(a)googlegroups.com For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---

5 6

io-improvements branch
by Armin Rigo April 22, 2008

April 22, 2008

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

1 0

S3 Call for Participation
by "Martin v. Löwis" April 16, 2008

April 16, 2008

---------------------------------------------------------------------- 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 ----------------------------------------------------------------------

1 0

If we are getting somewhere with a port of pygame ...
by Laura Creighton April 15, 2008

April 15, 2008

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(a)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?=" <renesd(a)gmail.com> To: pygame-users(a)seul.org Subject: Re: [pygame] SDL ctypes ImportError In-Reply-To: <a0efdb8a0804131650q7ffc58xeb7fe9300f96e4d7(a)mail.gmail.com> 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 <pymike93(a)gmail.com> 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 <module> > _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

2 1

Workshop on Self-sustaining Systems (S3) 2008 | Call for Participation
by Carl Friedrich Bolz April 14, 2008

April 14, 2008

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

1 0

What parts of the sys modules does PyPy implement?
by Brett Cannon April 9, 2008

April 9, 2008

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

3 5

Next sprints
by Armin Rigo April 4, 2008

April 4, 2008

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

3 3

PyOpenGL
by Amaury Forgeot d'Arc April 1, 2008

April 1, 2008

Hello, On Tue, Apr 1, 2008 at 6:24 AM, Maciek Fijalkowski <fijal(a)genesilico.pl> 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

2 1

PyOpenGL
by Maciek Fijalkowski April 1, 2008

April 1, 2008

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. :.

1 0