Mailman 3 February 2006 - pypy-dev

Request for Review
by Gerald Klix 13 Mar '06

13 Mar '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, can someone with more knowledge than me - I am thinking of Samuele and Armin here - look at pypy/dist/pypy/doc/ctypes-integration.txt and tell me and the other ctypes workers, wether the pointer representation is translateable? Currently I am running into problems when I want to translate a function that returns a pointer to a strcuture. Michael gave a hint, telling me that returning a pointer won't work with the test wrapper., but if I change the function to return something differnt (False) the problem persists. I am talking about the tests in pypy/dist/pypy/rpython/rctypes/test/test_rctypes.py around line 423 (def test_compile_pointer_to_struct). Any help is welcome. Best regards, Gerald - -- GPG-Key: http://keyserver.veridis.com:11371/search?q=0xA140D634 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEA3KYEDg9cqFA1jQRAq46AJ4ormuSdskdAsIyIJM4lh9brcWv/wCfWdGj Qzet6bd2Zp36+vfK2+DZJ34= =zsrh -----END PGP SIGNATURE-----

2 1

Re: [pypy-svn] r23609 - pypy/dist/pypy/translator/c/src
by Michael Hudson 06 Mar '06

06 Mar '06

tismer(a)codespeak.net writes: > Author: tismer > Date: Thu Feb 23 02:48:31 2006 > New Revision: 23609 > > Modified: > pypy/dist/pypy/translator/c/src/ll_stackless.h > Log: > had to disable Eric's stackless optimization. The fifth test on > test_stackless.py crashes after utilizing all memory. This error > should have been caught by running tests. How comes? Just py.test pypy/translator/c/test_stackless.py ? I ran that at least 10 times yesterday with no failures... Cheers, mwh -- TRSDOS: Friendly old lizard. Or, at least, content to sit there eating flies. -- Jim's pedigree of operating systems, asr

2 1

Re: [pypy-svn] r23678 - pypy/extradoc/talk/pycon2006
by Aurélien Campéas 28 Feb '06

28 Feb '06

On Sun, 2006-02-26 at 16:27 +0100, bea(a)codespeak.net wrote: [...] > +- Sprints: Lovain La Neuve, Tokyo, EuroPython, Ireland that's Louvain-La-Neuve Cheers, Aurélien.

1 0

profile based compiler optimization for PyPy
by Eric van Riet Paap 26 Feb '06

26 Feb '06

Hi, I've been experimenting with with some gcc options and features. What I found out so far is that with the options -fprofile-generate and - fprofile-use I was able to increase the Richards and pystone benchmark results (on top of pypy-c) with a little over 15%. Stackless is currently still 10-15% slower compared to plain vanilla PyPy, but I have some idea that I would like to look into in the next couple of days to make that better. cheers Eric

1 0

Re: [pypy-svn] r23602 - in pypy/dist/pypy: rpython/memory rpython/memory/test translator/c
by Richard Emslie 23 Feb '06

23 Feb '06

On Wed, 22 Feb 2006 mwh(a)codespeak.net wrote: > Author: mwh > Date: Wed Feb 22 22:39:23 2006 > New Revision: 23602 > > Modified: > pypy/dist/pypy/rpython/memory/gctransform.py > pypy/dist/pypy/rpython/memory/test/test_gctransform.py > pypy/dist/pypy/translator/c/database.py > pypy/dist/pypy/translator/c/extfunc.py > pypy/dist/pypy/translator/c/node.py > Log: > rework the gc transformer to use the mixlevelannotator and do all its rtyping > in one big go at the end. the hard part of this is attacking genc such that it > gets all its annotating done before the end of db.complete() and avoids looking > too hard at any of the gc helpers until after they get rtyped. > > this almost certainly breaks llvm :/ > oops! :-) Well I am now attending the sprint at pycon - would like to take a look at this and hopefully have a chance to get an understanding of gctransform. It is quite nice a dependency when something changes here and breaks llvm, prompts me to have a look into what has going on. ;-) Cheers, Richard

2 1

stackless optimization is somehow wrong
by Christian Tismer 23 Feb '06

23 Feb '06

Hi Eric, I ran the whole stackless tests again. First I used my tiny optimisation, but the fifth test crashes after eating all memory. Then I switched back to your latest version, with the same result. Then I disabled the patch completely, and things worked, again. We must be missing something, no idea what. As an addition, the fifteenth test always crashes with too many heap sections (on windows). ciao - chris -- Christian Tismer :^) <mailto:tismer@stackless.com> tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

1 0

Re: [pypy-svn] r23599 - pypy/dist/pypy/translator/c/src
by Eric van Riet Paap 23 Feb '06

23 Feb '06

H, I have a local version that does the test for the 'errorvalue' that gets returned when stack unwinding is going on. I did not check this in yet because it did not give a speedup, I will keep it around and look into a little further. We probably are making life difficult for the compiler because of the use of the resume_label. What we IMO really should to do is tell the compiler not to bother with the label and let all the register setup be handled in the resume block. In other words we need to make it clearer (for the compiler) that non stack unwind/resume is the case to optimize. Now the question is of course, how to do that? cheers Eric On Feb 22, 2006, at 9:22 PM, tismer(a)codespeak.net wrote: > Author: tismer > Date: Wed Feb 22 21:22:46 2006 > New Revision: 23599 > > Modified: > pypy/dist/pypy/translator/c/src/ll_stackless.h > Log: > a tiny change to stackless switching. This is still optimizable by > using special return values (please talk with me when > considering). Anyway the effects of these changes are still rather > unpredictably. > > Modified: pypy/dist/pypy/translator/c/src/ll_stackless.h > ====================================================================== > ======== > --- pypy/dist/pypy/translator/c/src/ll_stackless.h (original) > +++ pypy/dist/pypy/translator/c/src/ll_stackless.h Wed Feb 22 > 21:22:46 2006 > @@ -26,14 +26,33 @@ > > #define RPyExceptionClear() rpython_exc_type = NULL > > +/* > #define StacklessUnwindAndRPyExceptionHandling(unwind_label, > resume_label, exception_label) \ > if (RPyExceptionOccurred()) { \ > if (slp_frame_stack_bottom) \ > goto unwind_label; \ > - resume_label: \ > + resume_label: \ > if (RPyExceptionOccurred()) \ > FAIL(exception_label); \ > } > + > + Following code was supposed to compiler to shorter machine > code, but on windows it doesn't. > + Probably some other code folding is prevented, and there is a > tiny increase of 20 kb. > + I'm leaving the change in here, anyway. Richards is getting a > bit slower, PySone > + is getting faster, all in all speed is slightly increased. > + We should further investigate and try to use Eric's suggestion > of checking certain > + return values to get even shorter code paths. > + In any case, these optimizations are still flaky, because we > are probably in a high > + noise level of caching effects and random decisions of the > compiler. > +*/ > +#define StacklessUnwindAndRPyExceptionHandling(unwind_label, > resume_label, exception_label) \ > + resume_label: \ > + if (RPyExceptionOccurred()) { \ > + if (slp_frame_stack_bottom) \ > + goto unwind_label; \ > + FAIL(exception_label); \ > + } > +*/ > #else > > #define RPyRaisePseudoException() > _______________________________________________ > pypy-svn mailing list > pypy-svn(a)codespeak.net > http://codespeak.net/mailman/listinfo/pypy-svn

1 1

JIT
by Ben.Young＠risk.sungard.com 21 Feb '06

21 Feb '06

Hi All, As you probably know by now, I enjoy following the progress of the PyPy project, and generally I can understand roughly what is going on, but I have to admit I am stumpt by the JIT. Is there a document that describes what is going on anywhere? What's the goal of the current bit of work? I can't actually work out if the current JIT for the toy language is actaully jitt'ed, or if you are currently just working on the data structures that will produce the JIT? I.e will there need to be a machine code backend for the JIT or does it somehow magically produce fast code without a compiler, using some other kind of dispatch loop? Cheers, Ben

2 1

stackless patch
by Christian Tismer 21 Feb '06

21 Feb '06

Hi Eric, using your nice patch, I expected both a speed increase and a size decrease. The latter did not happen, because the exception is tested twice. #define StacklessUnwindAndRPyExceptionHandling(unwind_label, resume_label, exception_label) \ if (RPyExceptionOccurred()) { \ if (slp_frame_stack_bottom) \ goto unwind_label; \ resume_label: \ if (RPyExceptionOccurred()) \ FAIL(exception_label); \ } Just out of curiosity: does the code shrink if we do this? : #define StacklessUnwindAndRPyExceptionHandling(unwind_label, resume_label, exception_label) \ resume_label: \ if (RPyExceptionOccurred()) { \ if (slp_frame_stack_bottom) \ goto unwind_label; \ FAIL(exception_label); \ } Maybe this is slightly less machine code and not slower in the common case. Is it correct, btw? :-) ciao - chris -- Christian Tismer :^) <mailto:tismer@stackless.com> tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

1 0

Snake server downtime
by Armin Rigo 18 Feb '06

18 Feb '06

Hi all, The "snake" server will be down during the next couple of days (Wed-Thu), apparently for a change of the cooling system of the server room. If anyone would really like the server around, I can try to negotiate to have other machines shut down in its place -- some machines can be left running, as long as the room doesn't heat up too much. A bientot, Armin

1 1

pypy-dev February 2006