From anto.cuni at gmail.com Sat Sep 1 06:02:00 2018 From: anto.cuni at gmail.com (Antonio Cuni) Date: Sat, 1 Sep 2018 12:02:00 +0200 Subject: [pypy-dev] last benchmark run was June 2 In-Reply-To: References: Message-ID: Even if we decide to run them less often, we still need to setup the whole machinery: so, once we have done that, running them nightly or once a week doesn't change much. If we can get usage of speed.python.org it would be awesome I think: it would also immediately enable comparison between PyPy and CPython On Fri, Aug 31, 2018 at 9:41 AM Matti Picus wrote: > We lost the machine that was running our benchmark suite, the last run > sees to have been June2 http://speed.pypy.org/changes/. > > Choices: > - Ask the PSF to run on the machine that is used to run benchmarks for > speed.python.org. The machine, speed-python.osuosl.org, is very > powerful and not heavily used, a description of it is > https://speed.python.org/about/ under "The Machine". The users with > psf-authorized access to the machine, from > https://github.com/python/psf-chef, are fijal, zware, mattip, haypo > (results of "grep python-speed -r ." in that repo) > > - Use one of bencher4, baroquesoftware.com, or any other pypy-specific > donated machine. > > - Stop running benchmarks > > Any thoughts? Do we need nightly benchmarks or should we run them less > often? Should we also be running py3.5 benchmarks? Should we upload to > speed.python.org, speed.pypy.org or both? > Matti > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shuaib.Osman at investec.co.za Tue Sep 4 08:05:55 2018 From: Shuaib.Osman at investec.co.za (Shuaib Osman) Date: Tue, 4 Sep 2018 12:05:55 +0000 Subject: [pypy-dev] tensorflow support Message-ID: Hi, I've been using pypy on windows (32-bit) for some time now, and was wondering what the status is on the following: 1) Windowx x64 support 2) Tensorflow support on linux Now that numpy works quite well, if tensorflow manages to compile and run in pypy, it would speed up graph construction time considerably (although running a graph should be the same time as in Cpython). My particular use case is dynamically constructing complex tensorflow graphs, differentiating them and then running them once - so pypy could potentially offer a huge speedup. Thanks. Disclaimer This e-mail and any attachments thereto may contain confidential and proprietary information. This e-mail is intended for the addressee only and should only be used by the addressee for the related purpose. If you are not the intended recipient of this e-mail, you are requested to delete it immediately. Any disclosure, copying, distribution of or any action taken or omitted in reliance on this information is prohibited and may be unlawful. The views expressed in this e-mail are, unless otherwise stated, those of the sender and not those of the Investec Group of Companies or its management. E-mails cannot be guaranteed to be secure or free of errors or viruses. No liability or responsibility is accepted for any interception, corruption, destruction, loss, late arrival or incompleteness of or tampering or interfering with any of the information contained in this e-mail or for its incorrect delivery or non-delivery or for its effect on any electronic device of the recipient. For more information on the Investec Group of Companies see www.investec.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fijall at gmail.com Wed Sep 5 08:34:42 2018 From: fijall at gmail.com (Maciej Fijalkowski) Date: Wed, 5 Sep 2018 14:34:42 +0200 Subject: [pypy-dev] tensorflow support In-Reply-To: References: Message-ID: Hi Shuaib The windows 64bit support is not being worked on due to lack of commercial interest. We never manage to organize even modest funds to work on that. The tensorflow support - I don't frankly know, maybe someone else can speak up? PS. If you're based in Cape Town, I'm happy to discuss in person :) Best regards, Maciej Fijalkowski On Tue, Sep 4, 2018 at 2:05 PM, Shuaib Osman wrote: > Hi, > > > > I?ve been using pypy on windows (32-bit) for some time now, and was > wondering what the status is on the following: > > > > 1) Windowx x64 support > > 2) Tensorflow support on linux > > > > Now that numpy works quite well, if tensorflow manages to compile and run in > pypy, it would speed up graph construction time considerably (although > running a graph should be the same time as in Cpython). My particular use > case is dynamically constructing complex tensorflow graphs, differentiating > them and then running them once ? so pypy could potentially offer a huge > speedup. > > > > Thanks. > > > > > > > > Disclaimer > > This e-mail and any attachments thereto may contain confidential and > proprietary information. This e-mail is intended for the addressee only and > should only be used by the addressee for the related purpose. If you are not > the intended recipient of this e-mail, you are requested to delete it > immediately. Any disclosure, copying, distribution of or any action taken or > omitted in reliance on this information is prohibited and may be unlawful. > The views expressed in this e-mail are, unless otherwise stated, those of > the sender and not those of the Investec Group of Companies or its > management. E-mails cannot be guaranteed to be secure or free of errors or > viruses. No liability or responsibility is accepted for any interception, > corruption, destruction, loss, late arrival or incompleteness of or > tampering or interfering with any of the information contained in this > e-mail or for its incorrect delivery or non-delivery or for its effect on > any electronic device of the recipient. For more information on the Investec > Group of Companies see www.investec.com. > > > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev > From matti.picus at gmail.com Wed Sep 5 16:28:43 2018 From: matti.picus at gmail.com (Matti Picus) Date: Wed, 5 Sep 2018 23:28:43 +0300 Subject: [pypy-dev] tensorflow support In-Reply-To: References: Message-ID: <6ad0090d-9261-cad6-1bd0-de39d2a630e5@gmail.com> On 05/09/18 15:34, Maciej Fijalkowski wrote: > Hi Shuaib > > The windows 64bit support is not being worked on due to lack of > commercial interest. We never manage to organize even modest funds to > work on that. > > The tensorflow support - I don't frankly know, maybe someone else can speak up? > > PS. If you're based in Cape Town, I'm happy to discuss in person :) > > Best regards, > Maciej Fijalkowski > > On Tue, Sep 4, 2018 at 2:05 PM, Shuaib Osman > wrote: >> Hi, >> >> >> >> I?ve been using pypy on windows (32-bit) for some time now, and was >> wondering what the status is on the following: >> >> >> >> 1) Windowx x64 support >> >> 2) Tensorflow support on linux >> I would imagine tensorflow should Just Work (tm) but someone would need to rebuild the python c-extensions for PyPy. It would be nice to get some wheels up on https://github.com/antocuni/pypy-wheels. Matti From wickedgrey at gmail.com Fri Sep 7 14:26:08 2018 From: wickedgrey at gmail.com (Eli Stevens (Gmail)) Date: Fri, 7 Sep 2018 11:26:08 -0700 Subject: [pypy-dev] Effort required to support (or ignore) type annotations? Message-ID: Hi all, I've got a hobby project that I think would benefit from PyPy's pure-python speedups. I've been using CPython 3.6 for the type-annotation-based IDE hinting (nothing with a runtime impact). Would it be possible to get a release of PyPy that supported the syntax of type annotations? I wouldn't even need the language support, I don't think. Format strings would be keen too, but those are easy enough to change out to the old style that I'd be fine without support there. Thanks for all the work that you've all sunk into PyPy over the years. :) Cheers, Eli -------------- next part -------------- An HTML attachment was scrubbed... URL: From matti.picus at gmail.com Sat Sep 8 12:28:28 2018 From: matti.picus at gmail.com (Matti Picus) Date: Sat, 8 Sep 2018 19:28:28 +0300 Subject: [pypy-dev] Effort required to support (or ignore) type annotations? In-Reply-To: References: Message-ID: On 07/09/18 21:26, Eli Stevens (Gmail) wrote: > Hi all, > > I've got a hobby project that I think would benefit from PyPy's > pure-python speedups. I've been using CPython 3.6 for the > type-annotation-based IDE hinting (nothing with a runtime impact). > > Would it be possible to get a release of PyPy that supported the > syntax of type annotations? I wouldn't even need the language support, > I don't think. > > Format strings would be keen too, but those are easy enough to change > out to the old style that I'd be fine without support there. > > Thanks for all the work that you've all sunk into PyPy over the years.? :) > > Cheers, > Eli > Did you try the pre-release 3.6 nightlies http://buildbot.pypy.org/nightly/py3.6 ? Matti From wickedgrey at gmail.com Sat Sep 8 12:36:49 2018 From: wickedgrey at gmail.com (Eli Stevens (Gmail)) Date: Sat, 8 Sep 2018 09:36:49 -0700 Subject: [pypy-dev] Effort required to support (or ignore) type annotations? In-Reply-To: References: Message-ID: I didn't even realize those were a thing! Thanks, I'll check them out when I have time. :) Cheers, Eli On Sat, Sep 8, 2018 at 9:28 AM Matti Picus wrote: > On 07/09/18 21:26, Eli Stevens (Gmail) wrote: > > Hi all, > > > > I've got a hobby project that I think would benefit from PyPy's > > pure-python speedups. I've been using CPython 3.6 for the > > type-annotation-based IDE hinting (nothing with a runtime impact). > > > > Would it be possible to get a release of PyPy that supported the > > syntax of type annotations? I wouldn't even need the language support, > > I don't think. > > > > Format strings would be keen too, but those are easy enough to change > > out to the old style that I'd be fine without support there. > > > > Thanks for all the work that you've all sunk into PyPy over the years. > :) > > > > Cheers, > > Eli > > > Did you try the pre-release 3.6 nightlies > http://buildbot.pypy.org/nightly/py3.6 ? > > Matti > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndbecker2 at gmail.com Sat Sep 22 09:12:59 2018 From: ndbecker2 at gmail.com (Neal Becker) Date: Sat, 22 Sep 2018 09:12:59 -0400 Subject: [pypy-dev] Any news on pypy3 + numpy? Message-ID: https://mail.python.org/pipermail//pypy-dev/2016-September/014644.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From matti.picus at gmail.com Sat Sep 22 12:32:38 2018 From: matti.picus at gmail.com (Matti Picus) Date: Sat, 22 Sep 2018 19:32:38 +0300 Subject: [pypy-dev] Any news on pypy3 + numpy? In-Reply-To: References: Message-ID: On 22/09/18 16:12, Neal Becker wrote: > https://mail.python.org/pipermail//pypy-dev/2016-September/014644.html > > > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev That was two years ago. Now you can just do pip install numpy, which will download the latest upstream numpy and build it, using any openblas/atlas you have available. Or you can try pip install --extra-index https://antocuni.github.io/pypy-wheels/ubuntu numpy on ubuntu, or on windows download from gohlke's site https://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy which seems to have 1.14.5-pp360-win32.whl but not 1.15.0 Matti From ndbecker2 at gmail.com Sun Sep 23 10:32:50 2018 From: ndbecker2 at gmail.com (Neal Becker) Date: Sun, 23 Sep 2018 10:32:50 -0400 Subject: [pypy-dev] Any news on pypy3 + numpy? References: Message-ID: Matti Picus wrote: > On 22/09/18 16:12, Neal Becker wrote: >> https://mail.python.org/pipermail//pypy-dev/2016-September/014644.html >> >> >> _______________________________________________ >> pypy-dev mailing list >> pypy-dev at python.org >> https://mail.python.org/mailman/listinfo/pypy-dev > That was two years ago. Now you can just do pip install numpy, which > will download the latest upstream numpy and build it, using any > openblas/atlas you have available. Or you can try > > pip install --extra-index https://antocuni.github.io/pypy-wheels/ubuntu > numpy > > on ubuntu, or on windows download from gohlke's site > https://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy which seems to have > 1.14.5-pp360-win32.whl but not 1.15.0 > > Matti Reason I asked is, Here's what I get: pypy3 Python 3.5.3 (c573badf1521, Apr 25 2018, 17:27:42) [PyPy 6.0.0 with GCC 8.0.1 20180424 (Red Hat 8.0.1-0.22)] on linux Type "help", "copyright", "credits" or "license" for more information. >>>> import numpy Traceback (most recent call last): File "/home/nbecker/.local/lib/python3.5/site- packages/numpy/core/__init__.py", line 16, in from . import multiarray ImportError: cannot import name 'multiarray' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 1, in File "/home/nbecker/.local/lib/python3.5/site-packages/numpy/__init__.py", line 142, in from . import add_newdocs File "/home/nbecker/.local/lib/python3.5/site- packages/numpy/add_newdocs.py", line 13, in from numpy.lib import add_newdoc File "/home/nbecker/.local/lib/python3.5/site- packages/numpy/lib/__init__.py", line 8, in from .type_check import * File "/home/nbecker/.local/lib/python3.5/site- packages/numpy/lib/type_check.py", line 11, in import numpy.core.numeric as _nx File "/home/nbecker/.local/lib/python3.5/site- packages/numpy/core/__init__.py", line 26, in raise ImportError(msg) ImportError: Importing the multiarray numpy extension module failed. Most likely you are trying to import a failed build of numpy. If you're working with a numpy git repo, try `git clean -xdf` (removes all files not under version control). Otherwise reinstall numpy. Original error was: cannot import name 'multiarray' From matti.picus at gmail.com Sun Sep 23 10:40:28 2018 From: matti.picus at gmail.com (Matti Picus) Date: Sun, 23 Sep 2018 17:40:28 +0300 Subject: [pypy-dev] Any news on pypy3 + numpy? In-Reply-To: References: Message-ID: <7d817880-1e3f-f71c-8fff-1f561f4205a6@gmail.com> On 23/09/18 17:32, Neal Becker wrote: > Matti Picus wrote: > >> On 22/09/18 16:12, Neal Becker wrote: >>> https://mail.python.org/pipermail//pypy-dev/2016-September/014644.html >>> >>> >>> _______________________________________________ >>> pypy-dev mailing list >>> pypy-dev at python.org >>> https://mail.python.org/mailman/listinfo/pypy-dev >> That was two years ago. Now you can just do pip install numpy, which >> will download the latest upstream numpy and build it, using any >> openblas/atlas you have available. Or you can try >> >> pip install --extra-index https://antocuni.github.io/pypy-wheels/ubuntu >> numpy >> >> on ubuntu, or on windows download from gohlke's site >> https://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy which seems to have >> 1.14.5-pp360-win32.whl but not 1.15.0 >> >> Matti > Reason I asked is, > Here's what I get: > pypy3 > Python 3.5.3 (c573badf1521, Apr 25 2018, 17:27:42) > [PyPy 6.0.0 with GCC 8.0.1 20180424 (Red Hat 8.0.1-0.22)] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>>>> import numpy > Traceback (most recent call last): > File "/home/nbecker/.local/lib/python3.5/site- > packages/numpy/core/__init__.py", line 16, in > from . import multiarray > ImportError: cannot import name 'multiarray' > > During handling of the above exception, another exception occurred: > > Traceback (most recent call last): > File "", line 1, in > File "/home/nbecker/.local/lib/python3.5/site-packages/numpy/__init__.py", > line 142, in > from . import add_newdocs > File "/home/nbecker/.local/lib/python3.5/site- > packages/numpy/add_newdocs.py", line 13, in > from numpy.lib import add_newdoc > File "/home/nbecker/.local/lib/python3.5/site- > packages/numpy/lib/__init__.py", line 8, in > from .type_check import * > File "/home/nbecker/.local/lib/python3.5/site- > packages/numpy/lib/type_check.py", line 11, in > import numpy.core.numeric as _nx > File "/home/nbecker/.local/lib/python3.5/site- > packages/numpy/core/__init__.py", line 26, in > raise ImportError(msg) > ImportError: > Importing the multiarray numpy extension module failed. Most > likely you are trying to import a failed build of numpy. > If you're working with a numpy git repo, try `git clean -xdf` (removes all > files not under version control). Otherwise reinstall numpy. > > Original error was: cannot import name 'multiarray' > > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev My guess, from the path /home/nbecker/.local/lib/python3.5/site-packages/numpy is that you are trying to use a numpy from cpython on pypy. Are you sure you did what I suggested, or did you simply set your PYTHONPATH to the cpython site-packages? Matti From ndbecker2 at gmail.com Sun Sep 23 12:55:40 2018 From: ndbecker2 at gmail.com (Neal Becker) Date: Sun, 23 Sep 2018 12:55:40 -0400 Subject: [pypy-dev] Any news on pypy3 + numpy? References: <7d817880-1e3f-f71c-8fff-1f561f4205a6@gmail.com> Message-ID: Thanks! I've gotten much further now than before. Now I've hit this when importing my c++ module which uses pybind11: pypy3 test3.py Traceback (most recent call last): File "test3.py", line 9, in from constellation import QAMconstellation, bipolar ImportError: QAMconstellation64_base: dynamic attributes are currently not supported in conjunction with PyPy! From renesd at gmail.com Sun Sep 23 13:43:05 2018 From: renesd at gmail.com (=?UTF-8?Q?Ren=C3=A9_Dudfield?=) Date: Mon, 24 Sep 2018 05:43:05 +1200 Subject: [pypy-dev] Any news on pypy3 + numpy? In-Reply-To: References: <7d817880-1e3f-f71c-8fff-1f561f4205a6@gmail.com> Message-ID: Remember there is the really bad issue where pypy3 uses the wrong folder for packages - the cpython one! This is fixed in hg, but not in a release yet(i think). On Monday, September 24, 2018, Neal Becker wrote: > Thanks! I've gotten much further now than before. Now I've hit this when > importing my c++ module which uses pybind11: > > pypy3 test3.py > Traceback (most recent call last): > File "test3.py", line 9, in > from constellation import QAMconstellation, bipolar > ImportError: QAMconstellation64_base: dynamic attributes are currently not > supported in conjunction with PyPy! > > > > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndbecker2 at gmail.com Sun Sep 23 13:48:34 2018 From: ndbecker2 at gmail.com (Neal Becker) Date: Sun, 23 Sep 2018 13:48:34 -0400 Subject: [pypy-dev] Any news on pypy3 + numpy? References: <7d817880-1e3f-f71c-8fff-1f561f4205a6@gmail.com> Message-ID: Ren? Dudfield wrote: > Remember there is the really bad issue where pypy3 uses the wrong folder > for packages - the cpython one! You mean that pypy3 is using ~/.local/lib/python3.5/site-packages? That would be a big problem, except that fedora28 is currently using python3.6, while pypy3 is python3.5, so there is no conflict at the moment. > > This is fixed in hg, but not in a release yet(i think). > ... Fixed in pypy hg? I guess pybind11 would also have to be fixed. From alendit at googlemail.com Wed Sep 26 11:52:40 2018 From: alendit at googlemail.com (Dimitri Vorona) Date: Wed, 26 Sep 2018 17:52:40 +0200 Subject: [pypy-dev] CFFI: better performance when calling a function from address Message-ID: Hi all, I am JIT-generating functions in my code and call them by first ffi.cast'ing them to a function pointer. In my microbenchmarks its has pretty much the same call performance as when using cffi ABI mode (dumping the functions to a shared library first) and is around 250ns per call slower than when using API mode. I haven't looked at the generating assembly yet, but I guess pypy has to be more careful, since not all information from API mode is available. So the question is: is there any way to provide the missing information, since I basically know everything about the function behind the pointer that a compile would know? Cheers, Dimitri. -------------- next part -------------- An HTML attachment was scrubbed... URL: From armin.rigo at gmail.com Wed Sep 26 15:47:10 2018 From: armin.rigo at gmail.com (Armin Rigo) Date: Wed, 26 Sep 2018 21:47:10 +0200 Subject: [pypy-dev] CFFI: better performance when calling a function from address In-Reply-To: References: Message-ID: Hi Dimitri, On Wed, 26 Sep 2018 at 21:19, Dimitri Vorona via pypy-dev wrote: > In my microbenchmarks its has pretty much the same call performance as when using cffi ABI mode (dumping the functions to a shared library first) and is around 250ns per call slower than when using API mode. I doubt that these microbenchmarks are relevant. But just in case, I found out that the JIT is producing two extra instructions in the ABI case, if you call ``lib.foobar()``. These two instructions are caused by reading the ``foobar`` method on the ``lib`` object. If you write instead ``foobar()``, with either ``foobar = lib.foobar`` or ``from _x_cffi.lib import foobar`` done earlier, then the speed is exactly the same. A bient?t, Armin. From armin.rigo at gmail.com Wed Sep 26 15:54:30 2018 From: armin.rigo at gmail.com (Armin Rigo) Date: Wed, 26 Sep 2018 21:54:30 +0200 Subject: [pypy-dev] CFFI: better performance when calling a function from address In-Reply-To: References: Message-ID: Hi again, On Wed, 26 Sep 2018 at 21:19, Dimitri Vorona via pypy-dev wrote: > In my microbenchmarks its has pretty much the same call performance as when using cffi ABI mode (dumping the functions to a shared library first) and is around 250ns per call slower than when using API mode. > > I haven't looked at the generating assembly yet, but I guess pypy has to be more careful, since not all information from API mode is available. Just for completeness, the documentation of CFFI says indeed that the API mode is faster than the ABI mode. That's true mostly on CPython, where the ABI mode always requires using libffi for the calls, which is slow. On PyPy, the JIT has got enough information to do mostly the same thing in the end. (And before the JIT, PyPy uses libffi both for the ABI and the API mode for simplicity.) A bient?t, Armin. From cfbolz at gmx.de Wed Sep 26 16:28:20 2018 From: cfbolz at gmx.de (Carl Friedrich Bolz-Tereick) Date: Wed, 26 Sep 2018 22:28:20 +0200 Subject: [pypy-dev] CFFI: better performance when calling a function from address In-Reply-To: References: Message-ID: <8F666BA9-B602-4D71-9185-8EEC120AABD5@gmx.de> Hi Armin, Couldn't that slowness of getattr be fixed by making the lib objects eg use module dicts or something? Cheers, Carl Friedrich On September 26, 2018 9:47:10 PM GMT+02:00, Armin Rigo wrote: >Hi Dimitri, > >On Wed, 26 Sep 2018 at 21:19, Dimitri Vorona via pypy-dev > wrote: >> In my microbenchmarks its has pretty much the same call performance >as when using cffi ABI mode (dumping the functions to a shared library >first) and is around 250ns per call slower than when using API mode. > >I doubt that these microbenchmarks are relevant. But just in case, I >found out that the JIT is producing two extra instructions in the ABI >case, if you call ``lib.foobar()``. These two instructions are caused >by reading the ``foobar`` method on the ``lib`` object. If you write >instead ``foobar()``, with either ``foobar = lib.foobar`` or ``from >_x_cffi.lib import foobar`` done earlier, then the speed is exactly >the same. > > >A bient?t, > >Armin. >_______________________________________________ >pypy-dev mailing list >pypy-dev at python.org >https://mail.python.org/mailman/listinfo/pypy-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From armin.rigo at gmail.com Wed Sep 26 17:05:05 2018 From: armin.rigo at gmail.com (Armin Rigo) Date: Wed, 26 Sep 2018 23:05:05 +0200 Subject: [pypy-dev] CFFI: better performance when calling a function from address In-Reply-To: <8F666BA9-B602-4D71-9185-8EEC120AABD5@gmx.de> References: <8F666BA9-B602-4D71-9185-8EEC120AABD5@gmx.de> Message-ID: Hi Carl Friedrich, On Wed, 26 Sep 2018 at 22:28, Carl Friedrich Bolz-Tereick wrote: > Couldn't that slowness of getattr be fixed by making the lib objects eg use module dicts or something? If we use the out-of-line API mode then ``lib`` is an RPython object, but if we use the in-line ABI mode then it's a pure Python object. More precisely it's a singleton instance of a newly created Python class, and the two extra instructions are reading and guard_value'ing the map. It might be possible to rewrite the whole section of pure-Python code making the ``lib`` for the in-line ABI mode, but that looks like it would be even slower on CPython. And I don't like the idea of duplicating---or even making any non-necessary changes to---this slightly-fragile-looking logic... Anyway, I'm not sure to understand how just a guard_value on the map of an object can cause a 250 ns slow-down. I'd rather have thought it would cause no measurable difference. Maybe I missed another difference. Maybe the effect is limited to microbenchmarks. Likely another mystery of modern CPUs. A bient?t, Armin. From alendit at googlemail.com Thu Sep 27 04:30:06 2018 From: alendit at googlemail.com (Dimitri Vorona) Date: Thu, 27 Sep 2018 10:30:06 +0200 Subject: [pypy-dev] CFFI: better performance when calling a function from address In-Reply-To: References: <8F666BA9-B602-4D71-9185-8EEC120AABD5@gmx.de> Message-ID: Hi guys, thanks for your replies. 250ns sounded like a lot, and apparently it was. I can't reproduce it anymore. Thanks for the confirmation that API and ABI modes should have the same performance. I looked at the jitlog, and both api, abi and cast pointer seem to produce exactly the same code (assuming I bind the function to its own variable). Cheers, Dimitri. On Wed, Sep 26, 2018 at 11:05 PM Armin Rigo wrote: > Hi Carl Friedrich, > > On Wed, 26 Sep 2018 at 22:28, Carl Friedrich Bolz-Tereick > wrote: > > Couldn't that slowness of getattr be fixed by making the lib objects eg > use module dicts or something? > > If we use the out-of-line API mode then ``lib`` is an RPython object, > but if we use the in-line ABI mode then it's a pure Python object. > More precisely it's a singleton instance of a newly created Python > class, and the two extra instructions are reading and guard_value'ing > the map. > > It might be possible to rewrite the whole section of pure-Python code > making the ``lib`` for the in-line ABI mode, but that looks like it > would be even slower on CPython. And I don't like the idea of > duplicating---or even making any non-necessary changes to---this > slightly-fragile-looking logic... > > Anyway, I'm not sure to understand how just a guard_value on the map > of an object can cause a 250 ns slow-down. I'd rather have thought it > would cause no measurable difference. Maybe I missed another > difference. Maybe the effect is limited to microbenchmarks. Likely > another mystery of modern CPUs. > > > A bient?t, > > Armin. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jyouyj at gmail.com Fri Sep 28 19:36:48 2018 From: jyouyj at gmail.com (Jie You) Date: Fri, 28 Sep 2018 16:36:48 -0700 Subject: [pypy-dev] install pypy3 error Message-ID: Dear, I can not install the pypy3 on my Mac. I try several times. It raised NOTTY("Can not start the debugger when stdout is capture"). I have enclosed the screenshot in the attachment. Please tell me how to fix it. Thank you so much for your kindly support. Best regards, Jie -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pypy3_install_error.jpg Type: image/jpeg Size: 294181 bytes Desc: not available URL: From armin.rigo at gmail.com Sat Sep 29 01:24:55 2018 From: armin.rigo at gmail.com (Armin Rigo) Date: Sat, 29 Sep 2018 07:24:55 +0200 Subject: [pypy-dev] install pypy3 error In-Reply-To: References: Message-ID: Hi Jie, On Sat, 29 Sep 2018 at 07:18, Jie You wrote: > I can not install the pypy3 on my Mac. I try several times. It raised NOTTY("Can not start the debugger when stdout is capture"). I have enclosed the screenshot in the attachment. Please tell me how to fix it. Thank you so much for your kindly support. Sorry, this screenshot only shows the generic error "oops something went wrong". It doesn't print what went wrong. The error message was eaten; it may have been stored in some log file by the Homebrew installer. I would suggest that you first look on the Homebrew side to figure out how to display the error message---you probably need to start by reading the instructions at "https://docs.brew.sh/Troubleshooting". A bient?t, Armin.