Mailman 3 February 2008 - pypy-dev

buffer protocol.
by Maciek Fijalkowski March 5, 2008

March 5, 2008

I feel a bit clueless about buffer protocol. Current implemntation in pypy is purely app-level, which means it's slow, but more importantly, one cannot get raw, C-level address of it. I've tried approaching the problem, but it seems that there are several serious issues. * what's the future of buffer protocol? * do people use that? ctypes tests are relying on it. anybody knows ctypes module implementation that relies on it? * testing suite sucks. we've got two tests, cpython is not any better in this regard. where to proceed? :.

2 1

Seeking ideas for SoC 2008 participation with PyPy
by amit regmi Feb. 29, 2008

Feb. 29, 2008

Hi, I am looking for project Ideas, that I could take up for SoC 2008. I have a little PyPy experience, working on the "clr-module-improvements" branch and was mentored by Antonio Cuni and Carl, and involved - Enable importing of .NET libraries in PyPy. - Enable Iterations on .NET objects - Add Support for Generic Classes. I would be glad to know if there could be some unexplored PyPy corner which would be easier for me to take up based on the work I did. Waiting in anticipation. Best Regards, Amit

1 0

Seeking ideas for SoC 2008 participation with PyPy
by amit Feb. 28, 2008

Feb. 28, 2008

Hi, I am looking for some project Idea, that I could take up for SoC 2008. I have a little PyPy experience, that involved working on the "clr-module-improvements" branch and was mentored by Antonio Cuni and Carl, which involved - Enable importing of .NET libraries in PyPy. - Enable Iterations on .NET objects - Add Support for Generic Classes. I would be glad to know if there could be some unexplored PyPy corner which would be easier for me to take up based on the work I did. Waiting in anticipation. Best Regards, Amit

1 0

First draft of the openjdk proposal
by Antonio Cuni Feb. 27, 2008

Feb. 27, 2008

Hi all, I just finished to write the first draft of the openjdk proposal; you can find it under extradoc/proposal/openjdk-challenge.txt. It would be nice to hear comments, remarks and suggetions from whoever is interested as soon as possible, since the deadline is close (2nd of march). ciao, Anto

3 2

pypy/jvm Da-Vinci proposal
by holger krekel Feb. 26, 2008

Feb. 26, 2008

Hi all, it seems that Anto and Niko are back - so together with CF we now all plan to be around IRC at #pypy-sync monday 25th Feb afternoon (GMT). Topic is to discuss and maybe work on a PyPy proposal for Sun's Da-Vinci challenge. To cut the copyright/legal discussion short for now: let me try to draft a mail to Sun after or during the discussion tomorrow. Let's for now rather worry about the technical side: which PyPy/JVM/Da-Vinci related promises would we like to make for for the next six months? Note that Anto has created some interesting PyPy/JVM related information to be found e.g. here: http://codespeak.net/pypy/extradoc/planning/roadmap/goal_jython_ironpython_… I suggest to use these as starting points and topics for more thinking and discussion - feel free to commit there, post here or otherwise discuss outside of regulated meetings, please. For those interested to see existing proposal drafts, here is one from today that deals with a "meta compiler for non-python languages": http://mail.openjdk.java.net/pipermail/challenge-discuss/2008-February/0000… best & see you all, holger -- Holger Krekel - freelance manager and programmer merlinux GmbH: http://merlinux.de py.test: http://pytest.org PyPy: http://codespeak.net/pypy

2 1

Catching MemoryError in RPython
by Niko Matsakis Feb. 26, 2008

Feb. 26, 2008

I cannot seem to generate code that catches OOM errors in RPython. I wrote a test like this: def test_memoryerror_due_to_oom(self): def fn(): try: lst = [] for i in range(sys.maxint): lst.append(i) except Exception: #MemoryError: return "OK" assert self.interpret(fn, []) == "OK" but the try:/except: seems to have disappeared by the time the JVM backend is invoked (it's not in the flow graphs anywhere). I assume that it is getting stripped away by a deadcode pass at some point, though I'm not sure where that might be. I haven't managed to concoct code that can fool it into keeping the exception block yet, but I'm pretty sure that if I only could, then the JVM backend would handle it correctly... :) If you comment out the test that causes this out of memory condition, then test_builtin.py *almost* passes in pypy-jvm. There are still two errors, though. :) Niko

3 3

Re: [pypy-dev] Sun's Open JDK Challenge http://openjdk.java.net/challenge/
by Laura Creighton Feb. 26, 2008

Feb. 26, 2008

In a message of Mon, 18 Feb 2008 21:13:28 +0100, holger krekel writes: <lots of good stuff> <what looks to me like a completely workable plan> >However, IMO the main current issue is to come up with possible >goals and technical promises. Any comments and ideas about >possible PyPy/JVM Da-Vinci technical goals? yes, we need to hear from Samuele who is on John Rose's lead team for making adaptation to the JVM as suits dynamic languages. How this and the Da Vinci Machine hang together is not clear to me -- at least the last time I thought I understood it, Samuele made it clear to me that my model of what was going on was a grossly oversimplified model of what really was. >Otherwise i guess we may need to wait for Anto and >Niko getting back. Maybe, but maybe we ought to get started ahead of time. I happen to know Samuele's workload for 2 weeks from now -- we have an in house design sprint. If we could get some things settled ahead of time, this week, then this might be easier for him. Also, one reason I posted this here was that I was interested in hearing from people who are on this list, but so far not large contributors to the PyPy code base. Interested Lurkers, as it were. Are there any of you out there? Does this sound like something any of you are interested in? Laura > >best & cheers, > >holger

6 9

Micro benchmarks on i386 and ppc
by Jacob Hallén Feb. 24, 2008

Feb. 24, 2008

Using the outputs of Leonardo's test run on i386 and a run of the same revision on Tuatara (ppc), I have calculated the speed ratios between the two architectures. For each ratio, there are 4 numbers that can vary: - The speed of CPython for the test on ppc - The speed of CPython for the test on i386 - The speed of PyPy for the test on ppc - The speed of PyPy for the test on i386 In the list below, the first number is the ratio, with smaller numbers meaning that PyPy is doing better on i386 and larger meaning that PyPy is relatively better on ppc. The first number in parenthesis after the name of the test is relative performance to CPython on i386, the second number in parenthesis is relative performance on ppc. I'm a bit surprised that some tests have a huge difference in relative performance on the two platforms. Maybe something worth looking into. 0.41 test_unicode.test_bad_case_python2_5() (0.11), (0.27) 0.47 test_unicode.test_find_worstcase() (0.58), (1.24) 0.47 test_unicode.test_find_pattern1() (0.37), (0.79) 0.53 test_unicode.test_count_worstcase() (0.48), (0.90) 0.70 test_unicode.test_find_pattern8() (0.80), (1.14) 0.71 test_unicode.test_find_pattern2() (0.80), (1.13) 0.71 test_unicode.test_find_pattern4() (0.80), (1.13) 0.71 test_unicode.test_find_pattern16() (0.81), (1.14) 0.76 test_dict.test_dict_instance_setattr_instance_dict() (1.96), (2.59) 0.76 test_exception.test_reraise() (1.24), (1.63) 0.79 test_list.test_list_setitem() (2.06), (2.61) 0.79 test_dict.test_dict_setitem1() (3.43), (4.32) 0.83 test_exception.test_raise_builtin_exception() (1.91), (2.31) 0.84 test_count1.test_call_nested_function() (1.80), (2.15) 0.84 test_exception.test_raise_user_exception() (1.91), (2.27) 0.84 test_bltn.test_call_sin() (1.24), (1.47) 0.86 test_count1.test_count_in_attr() (1.70), (1.97) 0.87 test_count1.test_call_nested_function_other_count() (1.86), (2.15) 0.87 test_formatting.test_dict_formatting() (2.12), (2.45) 0.87 test_formatting.test_simple_formatting() (0.60), (0.69) 0.87 test_count1.test_count_in_slot() (2.37), (2.72) 0.87 test_create1.test_simple_loop_with_old_style_class_creation() (2.72), (3.12) 0.88 test_count1.test_call_nested_function_many_args() (1.77), (2.02) 0.88 test_count1.test_call_function() (1.88), (2.13) 0.88 test_dict.test_dict_setitem2() (2.34), (2.65) 0.88 test_count1.test_call_function_with_arguments_in_cellvars() (1.29), (1.46) 0.89 test_count1.test_call_function_without_arguments_in_cellvars() (1.47), (1.66) 0.90 test_formatting.test_format_long() (0.43), (0.48) 0.90 test_create1.test_simple_loop_with_new_style_class_creation() (3.54), (3.93) 0.90 test_exception.test_except_specific_builtin_exception() (1.79), (1.98) 0.90 test_exception.test_except_specific_user_exception() (1.89), (2.09) 0.90 test_dict.test_dict_instance_setnewattr_instance_dict() (2.00), (2.21) 0.92 test_bltn.test_call_fabs() (1.33), (1.44) 0.93 test_create1.test_simple_loop_with_new_style_class_new() (1.89), (2.03) 0.93 test_dict.test_dict_creation_mode1() (1.93), (2.07) 0.94 test_dict.test_dict_instance_getattr_instance_dict() (2.18), (2.33) 0.95 test_exception.test_except_multiple_user_exception() (3.01), (3.17) 0.95 test_bltn.test_isinstance3() (1.60), (1.68) 0.95 test_count1.test_call_method_of_new_style_class() (1.62), (1.70) 0.95 test_count1.test_loop_unrolled() (1.25), (1.31) 0.97 test_exception.test_except_multiple_builtin_exception() (2.67), (2.76) 0.98 test_count1.test_loop() (1.93), (1.96) 0.99 test_exception.test_try_except_else() (2.24), (2.27) 0.99 test_create1.test_simple_loop() (2.60), (2.63) 1.00 test_count1.test_loop_other_count() (2.16), (2.17) 1.00 test_count1.test_count_in_dict() (2.06), (2.06) 1.00 test_exception.test_try_except_finally() (2.14), (2.13) 1.01 test_exception.test_try_except() (2.27), (2.25) 1.01 test_bltn.test_isinstance1() (1.36), (1.34) 1.02 test_bltn.test_isinstance2() (1.34), (1.32) 1.02 test_dict.test_dict_class_dict_getmethod() (1.58), (1.55) 1.03 test_dict.test_dict_creation_mode2() (2.02), (1.96) 1.05 test_count1.test_call_method_of_old_style_class() (1.59), (1.51) 1.06 test_exception.test_instantiate_builtin_exception() (1.11), (1.05) 1.06 test_list.test_list_getitem() (3.12), (2.95) 1.06 test_list.test_list_append() (2.39), (2.25) 1.07 test_dict.test_dict_getitem() (2.45), (2.29) 1.10 test_exception.test_instantiate_user_exception() (1.34), (1.22) 1.12 test_formatting.test_format_unicode() (0.45), (0.40) 1.15 test_list.test_list_slice() (2.80), (2.44) 1.16 test_dict.test_dict_raw_range() (1.68), (1.45) 1.17 test_count1.test_count_in_global2() (2.14), (1.83) 1.17 test_count1.test_count_in_global() (2.13), (1.82) 1.21 test_formatting.test_number_formatting() (1.62), (1.34) 1.23 test_dict.test_dict_creation_mode3() (1.03), (0.84) 1.31 test_formatting.test_repr_formatting() (4.61), (3.53) 1.51 test_list.test_list_extend() (1.40), (0.93) 2.03 test_dispatch.test_dispatch_nop() (1.36), (0.67) Jacob

1 0

real-time gc ?
by Simon Burton Feb. 21, 2008

Feb. 21, 2008

I've taken some statistics on how the boehm gc performs with our current application, it has terrible worst case performance, often stopping for hundreds of mS at a time. I tried calling GC_enable_incremental() but that seems to cause the code to explode. I don't have any idea how to obtain similar statistics for the refcounting gc, which is also non-realtime. Perhaps it is in fact worse than boehm in this regard. Over-all CPU usage is significantly less with boehm, but a lot can happen in 300mS of a garbage collection. I don't think it's feasable compiling the pypy interpreter with refcounting, it takes a truly vast amount of time (some hours...) It would be good using the pypy interpreter to script our rpython codebase, but this gc issue seems to be a blocker. Simon.

2 2

Re: [pypy-dev] Sun's Open JDK Challenge http://openjdk.java.net/challenge/
by Laura Creighton Feb. 20, 2008

Feb. 20, 2008

I can ask John Rose about it again. Suggestions on how exactly to word what we want to do? What I think we want to do is to develop under the MIT license and then, should there be parts of it that just drop into the JDK, immediately relicense those bits under the Sun Contributors license. Is this correct? Laura

1 0