Re: [pypy-dev] gdbm
On 11/24/2010 01:13 AM, Dan Stromberg wrote: I've created a branch at http://codespeak.net/svn/pypy/branch/gdbm and made the proposed changes in it. I took the liberty of creating an attic directory to put dbm.py in. Any reason not to just delete dbm.py? This attic stuff is annoying, and if necessary you can still get the file from svn history. Cheers, Carl Friedrich ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] ype object 'BlackholeInterpreter' has no attribute 'bhimpl_direct_ptradd'
On 11/23/2010 09:48 PM, wlavrij...@lbl.gov wrote: I've been banging my head on the error below. I've removed the references to lltype.direct_ptradd in my code that I'm aware of, but that didn't do the trick. I told the JIT not to look into TypeConverter._get_fieldptr, see revision 79444. Afterwards it seemed to work. Any ideas, or perhaps an implementation of bhimpl_direct_ptradd? Ideally support should be added to the JIT, yes (Armin? :-) ). But for now the above solution should work too. Cheers, Carl Friedrich ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] [pypy-svn] r79382 - pypy/trunk/pypy/config
Hi, On Wed, Nov 24, 2010 at 1:19 AM, exar...@twistedmatrix.com wrote: I guess it should just be another log category, like jit-summary. Then you can get the effect you want by setting (in the shell) PYPYLOG to jit-summary:-. This or an env variable. The PYPYLOG solution I described *is* an environment variable. What do you mean? A bientôt, Armin. ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] [pypy-svn] r79382 - pypy/trunk/pypy/config
On Wed, Nov 24, 2010 at 2:39 PM, Armin Rigo ar...@tunes.org wrote: Hi, On Wed, Nov 24, 2010 at 1:19 AM, exar...@twistedmatrix.com wrote: I guess it should just be another log category, like jit-summary. Then you can get the effect you want by setting (in the shell) PYPYLOG to jit-summary:-. This or an env variable. The PYPYLOG solution I described *is* an environment variable. What do you mean? yes of course. nothing any more :) ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] gdbm
One tiny reason: People tend to forget that they can pull things from SVN history, when an isolated file disappears. I'm expecting someday someone's going to want to add bsddb - when they do, dbm.py might be a decent starting point (but it likely has memory leaks that were corrected in gdbm.py). I'd be happy to delete it if that's the consensus. On Wed, Nov 24, 2010 at 12:41 AM, Carl Friedrich Bolz cfb...@gmx.de wrote: On 11/24/2010 01:13 AM, Dan Stromberg wrote: I've created a branch at http://codespeak.net/svn/pypy/branch/gdbm and made the proposed changes in it. I took the liberty of creating an attic directory to put dbm.py in. Any reason not to just delete dbm.py? This attic stuff is annoying, and if necessary you can still get the file from svn history. Cheers, Carl Friedrich ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] gdbm
On 05:04 pm, drsali...@gmail.com wrote: One tiny reason: People tend to forget that they can pull things from SVN history, when an isolated file disappears. I'm expecting someday someone's going to want to add bsddb - when they do, dbm.py might be a decent starting point (but it likely has memory leaks that were corrected in gdbm.py). Anyone who cannot figure out how to use svn has a negligible chance of successfully implementing the bsddb module. Jean-Paul ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] gdbm
On Wed, Nov 24, 2010 at 10:50 AM, exar...@twistedmatrix.com wrote: On 05:04 pm, drsali...@gmail.com wrote: One tiny reason: People tend to forget that they can pull things from SVN history, when an isolated file disappears. I'm expecting someday someone's going to want to add bsddb - when they do, dbm.py might be a decent starting point (but it likely has memory leaks that were corrected in gdbm.py). Anyone who cannot figure out how to use svn has a negligible chance of successfully implementing the bsddb module. It's not really a matter of not knowing how to use SVN. Peg revisions are easy enough - even people who don't know them yet, will probably learn them easily. But if no one points out that there was once something vaguely related to what they want to do in the present,... Well, I think few would know to look for it under the name of dbm.py, even if it occurred to them to look backward in time before getting started. That is, unless they saw this thread in the archives :) But I'm starting to get the feeling that the consensus is that it should be deleted. That's not a problem. ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] ype object 'BlackholeInterpreter' has no attribute 'bhimpl_direct_ptradd'
Hi Carl, I told the JIT not to look into TypeConverter._get_fieldptr, see revision 79444. Afterwards it seemed to work. yes ... I now finally have my executable again. :) Some initial numbers from bench1, which we ran during the sprint, are (and they are not as accurate as the digits seem to presume): PyROOT: 62.8 PyCintex: 84.9 pypy-c: 11.0 C++: 0.05 For reminder: PyCintex is Reflex + PyROOT; the number is the difference between an empty loop and one calling into a C++ function that basically does nothing. I'm a little surprised b/c I remember that PyROOT was only 2x slower when we measured during the sprint, but that might simply be improvement in the JIT of course, and I don't remember the C++ data point to anchor it (although I thought it was lower than a factor 200), so oh well. Best regards, Wim -- wlavrij...@lbl.gov--+1 (510) 486 6411--www.lavrijsen.net ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] ype object 'BlackholeInterpreter' has no attribute 'bhimpl_direct_ptradd'
Hi, so I'm revising my numbers after finding out that I was using a debug version of ROOT/Reflex ... PyROOT: 48.6 PyCintex: 50.2 pypy-c:5.5 C++: 0.05 Note that although PyROOT speeds up only marginally in opt mode, pypy-c has a huge speedup. For PyROOT, this is b/c most of the time is spent in CPython through API calls and that was already in opt mode. For pypy-c, this is telling me quite clearly that I've got to work some on capi.py. ;) Of course, the factor 6 that I saw originally (v.s. 2 during the sprint) is now a factor 10 almost ... Best regards, Wim -- wlavrij...@lbl.gov--+1 (510) 486 6411--www.lavrijsen.net ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] [pypy-svn] r79480 - pypy/trunk/pypy/jit/tool
Is pypy repository really a place for such files? Maybe we should keep it somewhere else? On Wed, Nov 24, 2010 at 6:39 PM, antoc...@codespeak.net wrote: Author: antocuni Date: Wed Nov 24 17:39:03 2010 New Revision: 79480 Added: pypy/trunk/pypy/jit/tool/cpython.vmrss Log: add the vmrss file produced by armin's memusage.py when running ./translate.py -Ojit at rev 79456 Added: pypy/trunk/pypy/jit/tool/cpython.vmrss == --- (empty file) +++ pypy/trunk/pypy/jit/tool/cpython.vmrss Wed Nov 24 17:39:03 2010 @@ -0,0 +1,4101 @@ +124 +16600 +20620 +20640 +22036 +94084 +94084 +94108 +94108 +94108 +94108 +94108 +94120 +94164 +94160 +94160 +94160 +94160 +94160 +94216 +110644 +123144 +135236 +143680 +148500 +153104 +157088 +160640 +164760 +167992 +163108 +163232 +163232 +163436 +163436 +163436 +163444 +163444 +163444 +163448 +163448 +163448 +163448 +163448 +163448 +167060 +170948 +174432 +177212 +177216 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176508 +176520 +176520 +176520 +176520 +176520 +176520 +176520 +176520 +176520 +176540 +176544 +176544 +176544 +176544 +176544 +176544 +176544 +176544 +176544 +176544 +176544 +176544 +179120 +187120 +189380 +191052 +192156 +193320 +194900 +195860 +198516 +201484 +202600 +202600 +202600 +202600 +202832 +202832 +202836 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +202840 +207784 +212136 +216320 +220508 +224696 +228876 +245088 +245088 +247844 +252032 +256212 +260400 +264592 +268776 +272776 +275060 +279244 +283428 +287616 +291032 +293900 +298080 +302272 +304364 +308548 +310644 +312740 +316924 +319016 +323208 +325296 +327392 +331572 +333668 +335760 +337856 +354328 +356424 +358520 +362700 +364792 +366892 +368984 +371080 +373168 +375260 +377356 +379448 +381540 +383636 +383636 +385732 +387820 +390032 +391160 +392292 +394552 +396816 +397092 +399072 +401340 +403600 +405860 +408008 +408148 +412640 +414900 +417164 +419420 +421680 +423944 +426204 +428464 +430724 +432768 +434980 +436476 +437932 +440332 +441984 +442740 +445152 +447688 +449148 +449960 +452436 +454712 +454896 +457180 +45 +459688 +462040 +463480 +464408 +466812 +467244 +469224 +471096 +471684 +474136 +474328 +476508 +478872 +481356 +483472 +483780 +486072 +488480 +489668 +490888 +493420 +495704 +496836 +498116 +500520 +502756 +503668 +505400 +507760 +509296 +510204 +512764 +514708 +515508 +517372 +519764 +520648 +522188 +524596 +525524 +527004 +529412 +534224 +536632 +538080 +539216 +541588 +542560 +543384 +543384 +518804 +518804 +518804 +518804 +518804 +518804 +518804 +518804 +518804 +518804 +518804 +518804 +518804 +518804 +518804 +518804 +518804 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519024 +519028 +519028 +519028 +519028 +519028 +519028 +519028 +519028 +519028 +519028 +519028 +519028 +519032 +519032 +519032 +519032 +519036 +519036 +519036 +519036 +519036 +519036 +519036 +519036 +519036 +519036 +519036 +519036 +519036 +519036 +519036 +519036 +519036 +519036 +519036 +519036 +519036 +519036 +519036 +519048 +519048 +519048 +519048 +519048 +519048 +519048 +519048 +519048 +519048 +519048 +519048 +519048 +519048 +519052 +519052 +519052 +519052 +519052
Re: [pypy-dev] [pypy-svn] r79480 - pypy/trunk/pypy/jit/tool
On 25/11/10 07:40, Maciej Fijalkowski wrote: Is pypy repository really a place for such files? Maybe we should keep it somewhere else? well, it's the memory usage of cpython when translating pypy. Why the pypy repo should not be the place for a pypy-related file? On Wed, Nov 24, 2010 at 6:39 PM,antoc...@codespeak.net wrote: Author: antocuni Date: Wed Nov 24 17:39:03 2010 New Revision: 79480 Added: pypy/trunk/pypy/jit/tool/cpython.vmrss Log: add the vmrss file produced by armin's memusage.py when running ./translate.py -Ojit at rev 79456 ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] ype object 'BlackholeInterpreter' has no attribute 'bhimpl_direct_ptradd'
Hi Wim, On 25/11/10 01:32, wlavrij...@lbl.gov wrote: Hi, so I'm revising my numbers after finding out that I was using a debug version of ROOT/Reflex ... PyROOT: 48.6 PyCintex: 50.2 pypy-c:5.5 C++: 0.05 wow, impressive numbers :-). You said that the benchmark you used is a loop calling a c++ function that does nothing. What is the signature of that function? If you remember, in interp_cppyy there is a fast path that gives huge speedups when calling a c++ function which takes an integer and returns an integer, so depending on the signature you get very different numbers today. The good news is that nowadays the JIT has got the capability to optimise external calls in a general way: this means that as soon as we integrate it with cppyy we can have all calls as fast as the ones that go through the current fast path. ciao, Anto ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
