On March 3, 2013 2:20 AM, Carl Friedrich Bolz wrote: >Are you *sure* you are running on a 64 bit machine?
Sure? No. I assumed it's 64bit pypy because it was generating x86_64 instructions. How would you check for sure? uname reports x86_64 on the machine I built pypy on. $ pypy --version Python 2.7.3 (42c0d1650cf4, Feb 23 2013, 01:53:42) [PyPy 2.0.0-beta1 with GCC 4.6.3] That doesn't show the machine size. pypy --info is interesting but doesn't help either ? >When I run diz.py on a 64 bit machine, the BINARY_XOR bytecodes turn into >int_xor low level operations, as expected. I would like to see what you see using jitviewer since it differs from what I pasted (and maybe to figure out why). >Anyway, to debug where low and high turn into Python longs, you can putthe >following properties in arithmetic32.Encoder: ... That was some clever code. I like it. :) > In 32 bit they obviously trigger because of the line self.low = (self.low << > 1) & 0xffffffff (0xffffffff is a Python long on 32 bit). Specifically it's a long because 0xffffffff is unsigned 32 bit and thus can't fit in a signed 32bit. There no hope for the 32 bit version unless more int types are added beyond Python's two, specifically an uint32 type. And that's not python. Except, I did notice that numpy has this type and more: https://github.com/numpy/numpy/blob/master/numpy/core/include/numpy/npy_common.h It's conceivable that the efforts to bring numpy into pypy will be dealing with these various int sizes and could better support uint32 code like that in diz. However, I suspect it's not a huge win because the int operations will remain function calls instead of single x86 instructions. That's the real pain, on all platforms. Anyways, I run the code and it works. Everywhere. And I've finally convinced myself to stop abusing the dict with millions of items, so I've got more stuff to do. :) -Roger _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
