[pypy-dev] Slow int code

Roger Flores aidembb at yahoo.com
Wed Feb 27 21:55:48 CET 2013


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 at gmail.com>
To: Roger Flores <aidembb at yahoo.com> 
Cc: "pypy-dev at python.org" <pypy-dev at 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 at 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 at gmail.com>
>To: Roger Flores <aidembb at yahoo.com> 
>Cc: "pypy-dev at python.org" <pypy-dev at 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 at 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 at 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
>
>
>


-- 
"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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130227/3752fb4b/attachment.html>


More information about the pypy-dev mailing list