On Thu, Aug 18, 2011 at 2:13 AM, Eli Stevens (Gmail)
wickedg...@gmail.com wrote:
On Wed, Aug 17, 2011 at 4:01 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
+1 to the question. Why can't it be that way?
If by that way you mean leave python 2.x behind post 1.6 I'd like
to note that IMO
so the situation is even better: even if the PyPy Python 2.x
implementation was not updated any more after 1.6 (which won't be the
case), future versions of PyPy could have *both* a 2.x and a 3.x
interpreter (separately packaged), and *both* would leverage the newer
JIT versions. Is that correct
To be more concrete, the current test code is
def test_load_and_store(self):
a = PPCBuilder()
word1 = 1000
word2 = 2000
a.load_word(10, word1) # load constant 1000 into r10
a.load_word(11, word2) # load constant 2000 into r11
a.stw(10, 8, 0)
Many of the files in ppc/ppcgen/test (and
ppc/ppcgen/rassemblermaker.py) reference the old path of
pypy.jit.codegen.XXX. Updating the paths to pypy.jit.backend.XXX
allows most of the tests to run and pass.
Thanks, David
ppcjit-diff6
Description: Binary data
Hi David,
On Thu, Aug 18, 2011 at 4:50 PM, David Edelsohn dje@gmail.com wrote:
r8 and r9 are not initialized and point to whatever locations those
registers happen to hold.
I think that the test is just wrong... You need to load explicitly
the address of some CArray in r8 and r9, for
On 08/18/2011 04:50 PM, David Edelsohn wrote:
To be more concrete, the current test code is
def test_load_and_store(self):
a = PPCBuilder()
word1 = 1000
word2 = 2000
a.load_word(10, word1) # load constant 1000 into r10
a.load_word(11, word2)
Sweet. ^_^ I see the permissions bits look better now too.
I miss os.stat().st_rdev though - was it removed for a reason?
On Thu, Aug 18, 2011 at 10:30 AM, Maciej Fijalkowski fij...@gmail.comwrote:
PyPy 1.6 - kickass panda
We're pleased
Sven,
With the attached patch, all of the ppc/ppcgen/test/test_ppc.py tests
pass except for test_call_function that I skip while I debug it.
I updated ppc_assembler.py:load_from() to load a full 64 bit value on
64 bit systems. It is not exactly right because I need to fix the
signed offset
Yes, Vincent's way is the better way to go. To elaborate more on the
problem, string appending is O(N^2) while appending to a list and then
joining is an O(N) operation. Why CPython is faster than Pypy at doing
the less efficient way is something that I'm not fully sure about, but
I believe that
Python 2.4 introduced a change that helps improve performance of
string concatenation, according to its release notes. I don't know
anything beyond that.
-Aaron DeVore
On Thu, Aug 18, 2011 at 3:31 PM, Justin Peel pee...@gmail.com wrote:
Yes, Vincent's way is the better way to go. To elaborate
Yes, I just looked at it. For cases like this where there is
effectively only one reference to the string being appended to, it
just resizes the string in-place and copies in the string being
appended which gives it O(N) performance. It is a hack that is
available only because of the reference
Wow thanks for the quick response. The performance is *much, much* better
with the suggested list-join. CPython still beats Pypy, but only by a
narrow margin:
pypy1.6: 1m33.142s
CPython 2.7.1: 1m12.092s
Thanks for the advice-- I had forgotten about string immutability and its
12 matches
Mail list logo
