On 03/01/2013 10:13 PM, Roger Flores wrote:
I think there is nothing quite broken for PyPy. It just has a very long
warm-up time.
I think the jit has warmed up, for a few different reasons. Maybe some of them
are leading me astray though.
That means every additional run takes only 5 seconds.
Right. The way I interpret that is no matter how many more copies of data
added, the jit is not getting measurably faster, i.e. it's warmed up.
Second, diz prints out progress information at regular intervals, and it
noticeably speeds up. The jit is certainly kicking in. Cool.
Third, there are traces listed by jitviewer showing asm code generated. Again,
clearly the jit is doing it's thing.
Perhaps you're implying that the jit is constantly improving the code and will do better with a
longer run. OK, there's no shortage of larger files to try. When I try the 10MB file dickens from
http://www.data-compression.info/Corpora/SilesiaCorpus/index.htm which is over 10x longer and look
at the asm code generated (I'm looking at the various traces of output() at line 84) then the code
gen remains the "same" as when the shorter frank.txt is used, where same means the parts
that seem large still seem large. I do see a new trace "line 84 run 13165807 times" so
the jit is still changing things - I just can't see the improvement.
I think the jit is doing it's thing and more time doesn't change much. If you
want me to try larger files I will.
I think there is nothing quite broken for PyPy.
OK. The Pypy asm is working fine, certainly correct, and faster than CPython,
but it's still somewhat lengthlier than I was expecting. Could you explain why
a couple parts use much larger alternatives to what I'd expect to see?
For line 84 "if (self.low ^ self.high) & 0x80000000 == 0:" I was hopingfor code
along the lines of:
(Linux, 64 bit)
LOAD_ATTR low
LOAD_ATTR high
mov r10,QWORD PTR [rbx+0x8] mov r11,QWORD PTR [rbx+0x16]
BINARY_XOR
mov rax, r10
mov rdx, r11
xor rax, rdx
BINARY_AND
and rax, 0x80000000
COMPARE_OP ==
jnz after_if
I see both BINARY_XOR and BINARY_AND call a function instead of xor and and.
Why? Is there something I can change in my code to let those instructions be
used instead? Can xoring two ints really cause an exception?
BINARY_XOR
p120 = call(ConstClass(rbigint.xor), p118, p119, descr=<Callr 8 rr EF=3>)
mov QWORD PTR [rbp-0x170],rdx
mov QWORD PTR [rbp-0x178],rax
mov rdi,r15
mov rsi,r13
mov r11d,0x26db2a0
call r11
guard_no_exception(descr=<Guard239>)
cmp QWORD PTR ds:0x457d6e0,0x0
jne 0x3aed3fa2
Are you *sure* you are running on a 64 bit machine? When I run diz.py
on a 64 bit machine, the BINARY_XOR bytecodes turn into int_xor low
level operations, as expected. On 32 bit I get the call, as you pasted.
Anyway, to debug where low and high turn into Python longs, you can put
the following properties in arithmetic32.Encoder:
def get_low(self):
return self._low
def set_low(self, val):
assert isinstance(val, int)
self._low = val
low = property(get_low, set_low)
def get_high(self):
return self._high
def set_high(self, val):
assert isinstance(val, int)
self._high = val
high = property(get_high, set_high)
Indeed, they didn't trigger on 64 bit for me. In 32 bit they obviously
trigger because of the line self.low = (self.low << 1) & 0xffffffff
(0xffffffff is a Python long on 32 bit).
Cheers,
Carl Friedrich
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
