On Thu, Aug 18, 2011 at 2:13 AM, Eli Stevens (Gmail)
wrote:
> On Wed, Aug 17, 2011 at 4:01 PM, Yury Selivanov
> wrote:
>> +1 to the question. Why can't it be that way?
>
> If by "that way" you mean "leave python 2.x behind post 1.6" I'd like
> to note that IMO pypy has been under-acknowledged b
Hi Miquel,
On Wed, Aug 17, 2011 at 8:30 PM, Miquel Torres wrote:
>> This would remain as a branch for the foreseeable future though,
>> because we still need a Python 2 interpreter, if only to run our own
>> translation toolchain on (and not suffer the 2.5x slow-down of running
>> it on CPython 2
so the situation is even better: even if the PyPy Python 2.x
implementation was not updated any more after 1.6 (which won't be the
case), future versions of PyPy could have *both* a 2.x and a 3.x
interpreter (separately packaged), and *both* would leverage the newer
JIT versions. Is that correct Ma
Hi Gabriel,
On Wed, Aug 17, 2011 at 10:42 PM, Gabriel Lavoie wrote:
> Hum... It seems it's the end of my FreeBSD buildslave. :( I don't know when
> it time the memory requirement jumped to over 4GB (Armin told me it was now
> around 4.5GB for 64bits).
Actually I found out that with proper settin
Sven,
Does test_ppc.py:test_load_and_store() succeed for you? The code
stores the values in registers r10 and r11 to the memory addressed by
registers r8 and r9, but r8 and r9 never are initialized, so it stores
to an arbitrary location in memory that may not be valid and causes a
segfault.
I un
To be more concrete, the current test code is
def test_load_and_store(self):
a = PPCBuilder()
word1 = 1000
word2 = 2000
a.load_word(10, word1) # load constant 1000 into r10
a.load_word(11, word2) # load constant 2000 into r11
a.stw(10, 8, 0)
Many of the files in ppc/ppcgen/test (and
ppc/ppcgen/rassemblermaker.py) reference the old path of
pypy.jit.codegen.XXX. Updating the paths to pypy.jit.backend.XXX
allows most of the tests to run and pass.
Thanks, David
ppcjit-diff6
Description: Binary data
_
Hi David,
On Thu, Aug 18, 2011 at 4:50 PM, David Edelsohn wrote:
> r8 and r9 are not initialized and point to whatever locations those
> registers happen to hold.
I think that the test is just wrong... You need to load explicitly
the address of some CArray in r8 and r9, for example with:
p = l
On 08/18/2011 04:50 PM, David Edelsohn wrote:
To be more concrete, the current test code is
def test_load_and_store(self):
a = PPCBuilder()
word1 = 1000
word2 = 2000
a.load_word(10, word1) # load constant 1000 into r10
a.load_word(11, word2)
PyPy 1.6 - kickass panda
We're pleased to announce the 1.6 release of PyPy. This release brings a lot
of bugfixes and performance improvements over 1.5, and improves support for
Windows 32bit and OS X 64bit. This version fully implements Python 2.7
Sweet. ^_^ I see the permissions bits look better now too.
I miss os.stat().st_rdev though - was it removed for a reason?
On Thu, Aug 18, 2011 at 10:30 AM, Maciej Fijalkowski wrote:
>
> PyPy 1.6 - kickass panda
>
>
> We're pleased to announce t
Sven,
With the attached patch, all of the ppc/ppcgen/test/test_ppc.py tests
pass except for test_call_function that I skip while I debug it.
I updated ppc_assembler.py:load_from() to load a full 64 bit value on
64 bit systems. It is not exactly right because I need to fix the
signed offset compe
Great news! Thanks..
> From: Maciej Fijalkowski
> To: PyPy Developer Mailing List
> Date: Thu, 18 Aug 2011 19:30:44 +0200
> Subject: [pypy-dev] PyPy 1.6 released
>
> PyPy 1.6 - kickass panda
>
>
> We're pleased to announce the 1.6 release of PyPy
Hi all,
New to the list and fairly new to pypy. First of all, congrats on the new
1.6 release-- the growing support for numpy is very exciting (go, fight,
win, take state!).
So I snagged the 1.6 release to test if it would be faster on the kind of
code I often write: Bioinformatics. In this sni
A better breakdown...
fasta_file = sys.argv[1] # should be *.fa
> print 'loading dna from', fasta_file
> chroms = {}
> dna = None
> for l in open(fasta_file):
> if l.startswith('>'): # new chromosome
> if dna is not None:
> chroms[chrom] = dna
> chrom = l.strip().
Hello,
Try this:
import sys
fasta_file = sys.argv[1] # should be *.fa
print 'loading dna from', fasta_file
chroms = {}
dna = []
for l in open(fasta_file):
if l.startswith('>'): # new chromosome
if len(dna) > 0:
chroms[chrom] = ''.join(dna)
chrom = l.strip().repl
Yes, Vincent's way is the better way to go. To elaborate more on the
problem, string appending is O(N^2) while appending to a list and then
joining is an O(N) operation. Why CPython is faster than Pypy at doing
the less efficient way is something that I'm not fully sure about, but
I believe that it
Python 2.4 introduced a change that helps improve performance of
string concatenation, according to its release notes. I don't know
anything beyond that.
-Aaron DeVore
On Thu, Aug 18, 2011 at 3:31 PM, Justin Peel wrote:
> Yes, Vincent's way is the better way to go. To elaborate more on the
> pro
Yes, I just looked at it. For cases like this where there is
effectively only one reference to the string being appended to, it
just resizes the string in-place and copies in the string being
appended which gives it O(N) performance. It is a hack that is
available only because of the reference coun
Wow thanks for the quick response. The performance is *much, much* better
with the suggested list-join. CPython still beats Pypy, but only by a
narrow margin:
pypy1.6: 1m33.142s
CPython 2.7.1: 1m12.092s
Thanks for the advice-- I had forgotten about string immutability and its
20 matches
Mail list logo
