On Mon, Mar 4, 2013 at 1:13 AM, Maciej Fijalkowski wrote:
>print sys.maxint
print hex(sys.maxint)
0x7fff
That works. Not so obvious though.
On Monday, March 4, 2013 1:20 AM, Antonio Cuni wrote:
>just a wild guess: is it possible that you generated pyc files with a 32bit
>ve
Hi Bengt,
On Mon, Mar 4, 2013 at 4:32 PM, Bengt Richter wrote:
>
That's an issue of the Python language, which we won't address here.
Note also that Python 3 goes a bit in the direction you describe.
> BTW, what happens if you import in the opposite order?
> Can the 32-bit interpreter process
On 03/04/2013 10:20 AM Antonio Cuni wrote:
On 03/04/2013 09:42 AM, Roger Flores wrote:
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 c
Hi Anto,
On Mon, Mar 4, 2013 at 10:20 AM, Antonio Cuni wrote:
> (This happens because 2147483648 is stored as a long inside the marshalled
> pyc file).
Rght, absolutely. How about deciding that this is a bug and
fixing it in PyPy (even if it's the CPython behavior)? It can even be
done whi
On 03/04/2013 09:42 AM, Roger Flores wrote:
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
import sys
print sys.maxint
On Mon, Mar 4, 2013 at 10:42 AM, Roger Flores wrote:
> 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
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
Pyt
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 s
Thanks Armin. This explains a lot.
I get it better now.
-Roger
- Original Message -
From: Armin Rigo
To: Roger Flores
Cc: "pypy-dev@python.org"
Sent: Friday, March 1, 2013 2:20 PM
Subject: Re: [pypy-dev] Slow int code
Hi Roger,
On Fri, Mar 1, 2013 at 10:13 PM, Ro
Hi Roger,
On Fri, Mar 1, 2013 at 10:13 PM, Roger Flores wrote:
> 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?
If it b
an be happy with only 32 bits, I just
want Pypy to be happy too.
Thanks Armin,
-Roger
________
From: Armin Rigo
To: Roger Flores
Cc: "pypy-dev@python.org"
Sent: Friday, March 1, 2013 2:34 AM
Subject: Re: [pypy-dev] Slow int code
Hi Roger,
On Thu,
Hi Roger,
On Thu, Feb 28, 2013 at 6:00 PM, Roger Flores wrote:
> OK then. Unzip it, grab a text file large enough to warm up the jit, and run
> the line to generate the log for jitviewer.
I think there is nothing quite broken for PyPy. It just has a very
long warm-up time. On my 64-bit laptop,
Hi Roger,
On Wed, Feb 27, 2013 at 9:55 PM, Roger Flores wrote:
> I'll email the code separetely because I'm not sure everyone wants a tiny
> zip.
I'm sure no-one would mind receiving a tiny zip; or just use a paste
site if your program is a single module. (http://bpaste.net/)
A bientôt,
Armin
uary 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 wrote:
Would you like a paste from jitviewer or the source code to run and examine
with jitviewer?
>
>-Roger
>
>
&g
Would you like a paste from jitviewer or the source code to run and examine
with jitviewer?
-Roger
From: Alex Gaynor
To: Roger Flores
Cc: "pypy-dev@python.org"
Sent: Wednesday, February 27, 2013 12:23 PM
Subject: Re: [pypy-dev] Slow int code
ex Gaynor
> *To:* Roger Flores
> *Cc:* "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 examp
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 wrote:
> Hi guys. I've been looking at two simple routines using jitviewer to
> figure out why they're
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
18 matches
Mail list logo
