cfbolz changed the topic of #pypy to: #pypy PyPy, the flexible snake | IRC logs: and | Matti: I made a bit of progress, the tests now only segfault towards the end
jcea has quit [Ping timeout: 272 seconds]
j4at has joined #pypy
<cfbolz> The PyPy-dev Mail by Alex Martelli is pretty awesome
<j4at> cfbolz: good morning
<cfbolz> j4at: that's likely a very subtle thing, I think
<cfbolz> List comprehensions definitely pre allocate the correct length
<cfbolz> j4at: how long does cpython take on these?
<cfbolz> I will try look at the generated code soon (but today is admin day)
<j4at> 30 secs well in this specific case 36 secs/ 120 secs. That's a lot slower than pypy but in other cases Cpython is only x4 slower
<j4at> If I use str&int list (objectstrategy) cpython takes 39 secs and pypy takes 36 secs and mine takes 18!
<cfbolz> j4at: I'll try to take a look
<cfbolz> j4at: how fast is the 'natural' for loop, that preallocates the list with 0s and then directly sets the items?
<j4at> with the str+int it takes 20 secs
<j4at> with range it takes 7 secs
<j4at> with int list it takes 6.7 secs
<j4at> oh forgot to change d=[None] to d=[0]
<j4at> it takes 2 secs with int list
<j4at> cfbolz: reminder list comprehension takes 1.7secs
<j4at> The python version have also slower allocation if we reuse `d` it takes 0.3 secs less
<cfbolz> j4at: the fact that the weird map solution is a tiny bit faster is weird indeed
<j4at> I think that 'natural' for loop is more dynamic tho
<j4at> so it's a lot harder to optimize
<cfbolz> j4at: which pypy are you running?
<cfbolz> on my laptop the lis tcomprehension wins
<cfbolz> on a pypy 3.9 nightly build from last week
<j4at> the prebuilt pypy 3.9 from
<j4at> did you try
<j4at> the int + str one
<cfbolz> j4at: can you try a nightly build?:
<j4at> sure
<j4at> In the older build I got 8 secs
<j4at> instead of 18 :p
<j4at> using __pypy__.newlist_hint
<j4at> ^ that's incorrect I used d.append which doesn't multiply the elements by 2
<j4at> it's actually slower than []*n
* cfbolz does admin now
<j4at> I tried the nightly build with objectlist and got same results 18 secs/36 secs
<j4at> for int list comprehension is faster 1.6 secs /1.3 secs
Atque has quit [Ping timeout: 268 seconds]
j4at has quit [Ping timeout: 255 seconds]
j4at has joined #pypy
<j4at> The problem in the jit is my guess I tried more expensive int functions and mine is always faster.
j4at has quit [Read error: Connection reset by peer]
j4at has joined #pypy
<j4at> ops was using the older build. in the nightly version int lists list comprehension is always same or faster than map. But that doesn't mean there is no problems because int list comprehension in the nightly build is as fast as map in the old build. which is not even optimised for this specific task. for object lists map is always x2 faster.
j4at has quit []
j4at has joined #pypy
<j4at> Well using an actual int list instead of range is slower using list comprehension
j4at has quit []
Atque has joined #pypy
jcea has joined #pypy
reneeontheweb has joined #pypy
Atque has quit [Remote host closed the connection]
Atque has joined #pypy
reneeontheweb has quit [Quit: Client closed]
j4at has joined #pypy
j4at has quit [Read error: Connection reset by peer]
jcea has quit [Ping timeout: 260 seconds]
j4at has joined #pypy
<j4at> cfbolz: After thinking about it. Mine is not really safe, in case of exceptions or mutable object getting changed(it's still same speed with tuples tho) That's maybe why the object list is a lot slower because the jit doesn't know what *2 does. Closed the issue.
j4at has quit []
Atque has quit [Remote host closed the connection]
Atque has joined #pypy
j4at has joined #pypy
j4at has quit [Read error: Connection reset by peer]
<mattip> I wrote a short blog post about the M1 port, comments are welcome
<mattip> and the PR is at
<hexology> :o exciting!
<mattip> hexology: are you a macosx user? We could use help around packaging or testing
<hexology> mattip: i have an m1 machine at work, yes
<hexology> i recently installed pypy3.9-7.3.8 using pyenv, but i realize now that it must be running w/ rosetta
<mattip> "import platform; print(platform.machine()"
<mattip> how does pyenv pull it in, does it use our tarball or some other package?
<hexology> yep, it says x86_64 but uname says arm64
<hexology> good question about pyenv. presumably the tarball but i'm not sure
<hexology> is the arm64/m1 build process the same? if so, it should be trivial to update the homebrew formula accordingly
<mattip> yes, it is all the same
<hexology> i'm less confident about pyenv... i just took a look at the source code for pyenv-install and python-build, but it's all a giant bash script
<hexology> would take a while to figure out where anything is
<mattip> :shrug:
<hexology> maybe if you post this news in their issue tracker a maintainer will be able to quickly update it
<mattip> probably would want to wait for an official release, maybe in a month or two
<hexology> yeah they don't support master/head/trunk releases anyway
<hexology> homebrew does, but i don't know if it's possible to remove the x86_64 requirement exclusively for those builds
<mattip> for the next release, the big blocker right now is HPy 0.0.4
<hexology> funny, the stock ticker HPY is trading at $0.04 CAD currently
<mattip> one thing that might be nice for someone who knows macos, would be to port the cpython installer and make a real *.pkg file
<hexology> that's definitely beyond my knowledge i'm afraid
<mattip> ok
<hexology> is that even useful? unless it bundles idle etc like the cpython installer does. i guess it can't hurt to have, but i wouldn't expect high download stats for it either.
<hexology> i suspect that most pypy installations on macos are either docker, pyenv, homebrew, or some less popular package manager like nix or macports
<mattip> dunno. we get very little feedback about what is useful and what is not
<hexology> has pypy received any interest/feedback from industry recently? i'd sooner expect that something like an official pypy docker base image would be more beneficial for industry adoption
<hexology> well i can definitely contribute docs
<mattip> cool. The web site source is at
<hexology> ty
<hexology> where is the section w/ installation instructions?
<hexology> i'd echo the support for keeping macports & homebrew up-to-date, as well as binary signing, and my own suggestion above for an official docker base image
<mattip> There are actually two documentation web sites, the Homebrew link in the download instructions is at
<mattip> (that is the site)
<mattip> our developer docs at also describe installation
<hexology> thanks
<mattip> the source for those is in the PyPy repo
<mattip> that page is historically much older than the one and has (too much) more information
<hexology> interesting that you recommend conda
<hexology> i guess it makes sense, nowadays a lot of binary wheels for scientific packages are available on pypi, but perhaps not with arm64 support
<hexology> was binary singing ever taken care of? i agree w/ the poster who suggested that people would be happy to contribute towards the $100 fee
<mattip> it is the easiest way to get binary wheels for PyPy, since they rebuild _everything_ from source
<mattip> conda-forge provides a one-point-of-distribution way to build the packages, as long as the builds succeed
<hexology> conda is quite a heroic effort, it's a shame their reputation is so mixed (perhaps because their parent company doesn't do a good job of communication)
<hexology> and conda-forge is a bit weird because it's hard to know who is actually involved in or backing the project
<hexology> the website uses git/github and the dev docs use hg/heptapod? that's interesting
<mattip> conda-forge core team is defined by this I think
<mattip> and documented here
<mattip> as for pypy;s version control: the main project uses mercurial
<mattip> but some things are easier on git, like github pages: heptapod (the friendly gitlab fork that supports mercurial) does not have anything similar
<mattip> as for binary signing: the problem is not the $100, it is finding someone to create the package to be signed
<mattip> can we just sign a tarball, or does it need to be a pkg file
<mgorny> you should really be recommending Gentoo ;-)
* mgorny hides
Atque has quit [Remote host closed the connection]
Atque has joined #pypy
<hexology> mattip: i think the issue is the compiled executable itself
<hexology> actually reading this, i'm not sure. i suppose the idea with a "plain" binary (as opposed to a pkg) is that you submit the zip file?
<hexology> but then idk how end users acquire it. maybe you have to distribute it to macos users in that same format
tsraoien has quit [Ping timeout: 268 seconds]
jcea has joined #pypy