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.gay...@gmail.com>
To: Roger Flores <aide...@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 <aide...@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.gay...@gmail.com>
>To: Roger Flores <aide...@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 <aide...@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
>
>
>
--
"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
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
