[pypy-dev] Performance challenge of mutating class variables

I mentioned this issue in a private conversation with Carl and he suggested that I send the details to the mailinglist. The following blog post is a nice summary of a significant performance problem in IronPython's early implementation with good links to the key discussions:

Re: [pypy-dev] PPC backend design questions

Attached is a new patch that corrects the PPC fields. The only simple way I can think of handling the 64 bit immediate shift field is by adding a keyword argument to Field to ignore overlap. Expressing the details of the field splitting will be complicated and doesn't seem worth it. Is there a

Re: [pypy-dev] Linux 3.0 kernel fallout

On Tue, Aug 16, 2011 at 4:20 PM, Leonardo Santagada santag...@gmail.com wrote: On Tue, Aug 16, 2011 at 3:36 PM, Amaury Forgeot d'Arc amaur...@gmail.com wrote: 2011/8/16 Reiner | chocri rei...@chocri.de $ python -c 'import sys; print sys.platform' linux2 $ uname -r 3.0.0-1-686-pae So,

Re: [pypy-dev] PPC JIT test_load_and_store()

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)

[pypy-dev] Update import path of PPC JIT tests

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

[pypy-dev] PPC64 JIT test_ppc.py tests fixed and working

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

[pypy-dev] test_ppc successful on PPC64

I fixed test_call_function on PPC64 so all test_ppc.py tests succeed on PPC64. Now on to the more general tests. - David ___ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev

Re: [pypy-dev] STM

On Thu, Jan 5, 2012 at 5:38 AM, Armin Rigo ar...@tunes.org wrote: Ah, I realized something else.  When considering solutions for CPython, if we go for the one-transaction-per-bytecode approach, like the approach taken in the 2 papers so far about CPython+TM, then we need non-lexically-nested

Re: [pypy-dev] STM

On Fri, Jan 6, 2012 at 9:23 AM, Armin Rigo ar...@tunes.org wrote: I agree, but my issue is precisely that (say) gcc 4.7, as far as I can tell, *imposes* the dynamic extent to be a nested block.  There is no way to ask gcc to produce code handling the lower-level but more general alternative.  

Re: [pypy-dev] STM

On Fri, Jan 6, 2012 at 11:04 AM, Armin Rigo ar...@tunes.org wrote: Just for the sake of the argument:  This seems wrong to me.  You could declare C functions with an attribute meaning this function is meant to be called in a transaction, but it may end the transaction and start the next one.  

Re: [pypy-dev] set with instances very slow from 1.8 to 1.9

On Tue, Jun 19, 2012 at 12:33 PM, Lukas Diekmann lukas.diekm...@uni-duesseldorf.de wrote: Hi, you are right. Union between two sets of objects are slower, since we introduced mechanics to make set operations with primitive types (e.g. ints) faster. The problem was that a fastpath was removed

Re: [pypy-dev] Any publications regarding PyPy / trace-based JIT compiler?

On Wed, Jul 4, 2012 at 8:44 AM, Carl Friedrich Bolz cfb...@gmx.de wrote: On 07/03/2012 11:28 PM, Michael Sioutis wrote: Dear PyPy team, I am in the process of writing a paper that will target some AI conference, and I would like to ask if there are any relevant publications of yours or in

Re: [pypy-dev] Any publications regarding PyPy / trace-based JIT compiler?

On Wed, Jul 4, 2012 at 11:29 AM, Michael Sioutis papito@gmail.com wrote: Thank you all very much! Of course I don't want to present trace-based JITs as the best choice, but leave some hints on the possible advantages that it possibly offers, just to put an additional comment on my

[pypy-dev] PPC64 backend compile_framework_7_interior failure

Armin, et al, compile_framework_7_interior in test_zrpy_gc fails for the PPC64 backend in a strange way. Identical problems happen on the public system and my private system, but GDB on the public system is not permitting hardware watchpoints, so it is more difficult to catch the cause of the

Re: [pypy-dev] PPC64 backend compile_framework_7_interior failure

I have a newer version of GDB installed in my account on the gcc110 that has hw watchpoint working. We can continue to add debugging capabilities to the PPC64 backend, but it is fairly clear how the ops correspond to assembler instructions. The overwriting occurs in the first call to

Re: [pypy-dev] PPC

On Mon, Dec 3, 2012 at 10:24 AM, Wiktor Mizdal wiktor8...@o2.pl wrote: Which operating systems will support Pypy PowerPC backend? PPC64 Linux. It probably could run on PPC64 FreeBSD as well. It could run on AIX, because it does not rely on a lot of system services, but the PyPy infrastructure

Re: [pypy-dev] Christian Rafael: Community Development in Brazil(pypy.com.br or pypy.org.br)

2013/3/11 Christian Rafael christ...@paradix.com.br: Original -- Olá, Meu nome é Christian Rafael moro no Brasil e tenho 15 anos e fiquei impressionado com o projeto PyPy e gostária de liderar um grupo de desenvolvimento no Brasil através de uma página na internet('www.pypy.com.br

Re: [pypy-dev] Esclarecimentos(pypy.org.br ou pypy.com.br)

2013/3/12 Christian Rafael christ...@paradix.com.br: O objetivo do desenvolvimento da página seria, disponibilizar o PyPy para download como feito no site pypy.org, tradução colaborativa da documentação para o Português e Espanhol, unir desenvolvedores da América Latina que a apoiam o

Re: [pypy-dev] Esclarecimentos(pypy.org.br ou pypy.com.br)

2013/3/14 Christian Rafael christ...@paradix.com.br: Olá Sr.David, Para mim também é indiferente, não tinha pensado na possibilidade de um subdomínio br.pypy.org seria excelente. Também tenho disponibilidade para estar fazendo apresentações em Escolas Técnicas e Faculdades, mas tudo isso

Re: [pypy-dev] GSoC Application Process

On Mon, Apr 15, 2013 at 9:05 AM, Maciej Fijalkowski fij...@gmail.com wrote: Surprisingly enough, both of those projects has been done, however, there is plenty of work to be done in both the area of GUI (say gobject?) and JIT (especially on ARM), like optimizing ARM, setting up buildbot etc.

Re: [pypy-dev] ARM v6 GSOC

On Mon, Apr 15, 2013 at 9:35 AM, Maciej Fijalkowski fij...@gmail.com wrote: Surprisingly, ARMv6 support for PyPy has been done already. There is however tons and tons of stuff you can do with the ARM backend, like optimize it. Hi, William Another opportunity is working on the PPC port --

Re: [pypy-dev] Fwd: Re: ARM v6 GSOC

On Sat, Apr 20, 2013 at 4:58 AM, Maciej Fijalkowski fij...@gmail.comwrote: I suppose I'm missing some context. Few things: * feel free to propose *anything* that you find interesting and is related to pypy as a project (I'll update the wiki to say that), the list of projects is just an

Re: [pypy-dev] Fwd: Re: ARM v6 GSOC

On Sat, Apr 20, 2013 at 3:10 AM, william williamandrewalumba...@gmail.comwrote: On Wed, Apr 17, 2013 at 9:41 PM, williamwilliamandrewalumba...@gmail.com williamandrewalumba...@gmail.com wrote: What would be a good way to propose either of these as a project? If you want to discuss it, we

Re: [pypy-dev] LLVM next steps

On Sun, Sep 8, 2013 at 11:17 AM, Armin Rigo ar...@tunes.org wrote: Hi again, On Sun, Sep 8, 2013 at 9:42 AM, Armin Rigo ar...@tunes.org wrote: We've been suitably impressed by the results on the new llvm backend during the sprint (well, or suitably un-impressed by both gcc and clang's

[pypy-dev] remove-globals-in-jit for ppc backend

Hi, David Ivan and Andre from Unicamp and I are trying to update the ppc backend to the current RPython internals API. We're trying to understand the removal of fail_boxes_int, etc. from the backends. It looks like this was done on the remove-globals-in-jit branch. I guess we need to adapt all

Re: [pypy-dev] s390x the last failing tests

; is hard to find out the cause if they do not fail on the development > machine... We could try to start a translation, but I'm unsure if it > will really work. > > Cheers, > Richard > > > > On 01/19/2016 04:40 PM, David Edelsohn wrote: >> $ as -v >> GNU assemb

Re: [pypy-dev] s390x the last failing tests

the update has any effect. > Some of the failing tests (on the buildbot only) are very severe, and it > is hard to find out the cause if they do not fail on the development > machine... We could try to start a translation, but I'm unsure if it > will really work. > > Cheers, > R

Re: [pypy-dev] s390x the last failing tests

s (on the buildbot only) are very severe, and it > is hard to find out the cause if they do not fail on the development > machine... We could try to start a translation, but I'm unsure if it > will really work. > > Cheers, > Richard > > > > On 01/19/2016 04:40 PM, D

Re: [pypy-dev] s390x the last failing tests

$ as -v GNU assembler version 2.25.90 (s390x-linux-gnu) using BFD version (GNU Binutils for Debian) 2.25.90.20160101 $ ld -v GNU ld (GNU Binutils for Debian) 2.25.90.20160101 On Tue, Jan 19, 2016 at 6:12 AM, Richard Plangger wrote: > hi, > > I wanted to give a quick update

Re: [pypy-dev] s390x the last failing tests

On Tue, Jan 19, 2016 at 6:12 AM, Richard Plangger wrote: > hi, > > I wanted to give a quick update on the state of the implementation. Good > news! I think there is not that much left to be done! > > I'm currently waiting for a bigger VM (already wrote an email to >

Re: [pypy-dev] [ANN] Python compilers workshop at SciPy this year

Maciej, How about a little more useful response of "we'll help you find the right audience for this discussion and collaborate with you to make the case."? - David On Thu, Mar 24, 2016 at 11:32 AM, Maciej Fijalkowski wrote: > Ok fine, but we're not the receipents of such a

Re: [pypy-dev] PyPy 5.4 release

On Tue, Aug 30, 2016 at 12:10 PM, Armin Rigo wrote: > Hi Matti, > > On 29 August 2016 at 01:14, Matti Picus wrote: >> I will be unable to repackage and upload to bitbucket for the next few days, >> so if anyone with fast internet can run the repackages

Re: [pypy-dev] More feedback on new pypy.org

The new website design is looking better and better. The graph should probably have a label "<--- Better" pointing downward. Otherwise it naively looks like PyPy is striving to approach CPython bar. - David On Tue, Feb 19, 2019 at 12:34 PM Maciej Fijalkowski wrote: > > Hi everyone! > > Here

Re: [pypy-dev] Changing the PyPy download page

On Sun, Jun 28, 2020 at 3:36 PM Ram Rachum wrote: > > Hi everyone! > > The last week, I've been talking with Matti about ways in which PyPy could be > friendlier to new users, and what to do about that. One of the examples I > raised in which PyPy is, in my opinion, giving newbies a hard time,

Re: [pypy-dev] Differences performance Julia / PyPy on very similar codes

e by PyPy and analyze the reason for the performance gap. It should be evident if the difference is abstraction or SIMD. Thanks, David On Mon, Dec 21, 2020 at 5:20 PM PIERRE AUGIER wrote: > > > - Mail original - > > De: "David Edelsohn" > > À: "PIERRE AUGI

Re: [pypy-dev] Differences performance Julia / PyPy on very similar codes

Does Julia based on LLVM auto-vectorize the code? I assume yes because you specifically mention SIMD design of the data structure. Have you tried NumPyPy? Development on NumPyPy has not continued, but it probably would be a better comparison of what PyPy with auto-vectorization could accomplish

[pypy-dev] Re: Moving to github

I think that this is a good suggestion and a good plan. David On Thu, Dec 28, 2023 at 3:21 AM Matti Picus wrote: > Now that 7.3.14 has been released, I would like to move the canonical > repo for pypy and rpython to github. Reasons: > > - foss.heptapod.net is not well tracked in