I'll email the code separetely because I'm not sure everyone wants a tiny zip. Anyone is welcome to it. It's a newer version of the compressor I entered into the Large Text Compression Benchmark.
I'm running it as:
PYPYLOG=jit-log-opt,jit-backend:dizlog.pypylog pypy diz.py -p -t frank.txt
You can get frank.txt from http://www.gutenberg.org/ebooks/84 (and rename it) or substitute a similar file.
Examine the second line in output():
if (self.low ^ self.high) & 0x80000000 == 0:
The remaining lines are similar. Also, the routine encode() listed one line above in jitviewer has the same issues. If I comment out the two calls to encode(), I save a huge percentage of time (up to 40% in some configurations).
-Roger
________________________________ From: Alex Gaynor alex.gaynor@gmail.com To: Roger Flores aidembb@yahoo.com Cc: "pypy-dev@python.org" pypy-dev@python.org Sent: Wednesday, February 27, 2013 12:35 PM Subject: Re: [pypy-dev] Slow int code
The original source code would be best!
Thanks, Alex
On Wed, Feb 27, 2013 at 12:32 PM, Roger Flores aidembb@yahoo.com wrote:
Would you like a paste from jitviewer or the source code to run and examine with jitviewer?
-Roger
From: Alex Gaynor alex.gaynor@gmail.com To: Roger Flores aidembb@yahoo.com Cc: "pypy-dev@python.org" pypy-dev@python.org Sent: Wednesday, February 27, 2013 12:23 PM Subject: Re: [pypy-dev] Slow int code
In that context large longs means HUNDREDS or THOUSANDS of bits, not 64 :) Can you show us a full runnable example that illustrates this?
Alex
On Wed, Feb 27, 2013 at 12:10 PM, Roger Flores aidembb@yahoo.com wrote:
Hi guys. I've been looking at two simple routines using jitviewer to figure out why they're so much slower than expected.
I've also noticed that http://pypy.org/performance.html has the line "Bad examples include doing computations with large longs – which is performed by unoptimizable support code.". I'm worried that my 32 bit int code is falling into this, and I'm wondering what I can do to avoid it?
Trivial code like
if (self.low ^ self.high) & 0x80000000 == 0:
is expanding into several dozen asm instructions. I'm suspecting that lines like
self.low = (self.low << 1) & 0xffffffff
with it's shift left are convincing the jit to consider the int to need 64 bits (large long?) instead of 32.
Ideas? The asm is clearly operating on QWORDs and calling routines to do the bit arithmetic instead of single instructions. Is this what that line in performance.html is warning about?
-Roger
BTW Fijal's jitviewer is a *must see* for anyone interested in how pypy makes their code fast!
pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
-- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero