<Dejan>
I wonder what could possibly be the reason why in few benchmarks CPython performs better...
<simpson>
Dejan: There's two common reasons. The older reason, less common, is that the benchmark tests a slow corner of PyPy's functionality; the more common modern reason is that sometimes a benchmark is so small that CPython wins by starting up and interpreting more code faster.
marky1991 has joined #pypy
<mattip>
in this case I think it is apple to oranges, the implementations are different
<mattip>
so you are measuring numpy to cffi
<Dejan>
yea... :)
<Dejan>
anyway, I love Pypy!
Dejan has quit [Remote host closed the connection]
kaeptmblaubaer has quit [Ping timeout: 250 seconds]
marky1991 has quit [Remote host closed the connection]
marky1991 has joined #pypy
esc has joined #pypy
<esc>
hi
<esc>
what is the current state of Numpy on PyPy?
<esc>
I have heard rumours that Numpy and Pandas compile without modification, is it true?
<cfbolz>
esc: it works, but often is not super fast
<esc>
cfbolz: O.K. do you have any references that I could cite?
<esc>
cfbolz: that is a great link, thank you very much
<cfbolz>
esc: the plan is to start some work to improve this performance later this year
<esc>
cool!
<esc>
I just recently started working on Numba so I'm currently researching how all of this fits together.
<esc>
I'll have to read and digest that blog post
marky1991 has quit [Remote host closed the connection]
marky1991 has joined #pypy
<ronan>
esc: it would be interesting to get numba working on pypy as they are quite complementary in terms of what they optimise well
darkman66 has quit [Remote host closed the connection]
darkman66 has joined #pypy
<mjacob>
mattip: you could do "hg log -r 'head()'" and filter out all branches with only one head (not sure how to automatize this)
<tos9>
ronan: hm interesting -- are they?
<tos9>
It's been awhile since I looked at numba
marky1991 has quit [Remote host closed the connection]
<tos9>
Oh interesting. It does SIMD at least
marky1991 has joined #pypy
<mattip>
mjacob: I did "hg heads -T '{branch}\n' |sort | uniq -d" but there are no repeat branches in that report
<mattip>
uniq -d should return repeated lines
<mjacob>
mattip: it changes when passing --closed to heads
darkman66 has quit [Remote host closed the connection]
<mattip>
hmm
<mattip>
that seems like a problem with mercurial. Every closed brandh has a head at the close and another head when merged into another branch
<mattip>
i.e. look at 1d46f3a5d4c1 and 6c50bbbada5b, which both are on the shadowstack-again branch
<mattip>
the second one is the result of `hg --close-branch`, but is not really a head
<mjacob>
there is the notion of a topological branch as well
<mjacob>
from the help of `hg heads`: "Branch heads are changesets that have no descendants on the same branch"
<mjacob>
sorry, i meant "topological head" earlier
<mattip>
6c50bbbada5b has a decendant: 10a7e84783d7, but that does not show up in hg log -r 6c50bbbada5b
<mattip>
hg log -r 10a7e84783d7 does show 6c50bbbada5b as a parent
<mjacob>
"topological head" matches your idea of a head: a "leaf" in the DAG
<mattip>
it seems to me a decendant's parent, when that parent doesn;t listing the decendant is a bug
<mattip>
I don't see how we can resolve this in the repo without breaking history
<mattip>
I think the problem is that the branches were closed twice
<mjacob>
?? in which cases does `hg log` show descendants?
jacob22 has quit [Ping timeout: 246 seconds]
<mjacob>
sorry, my internet connection is too slow to do a conversation
<mattip>
that is the bug IMO, hg log -r 10a7e84783d7 shows 6c50bbbada5b as a parent
<mattip>
but hg log -r 6c50bbbada5b does not show 10a7e84783d7 as a decendant
<mjacob>
sorry, my internet connecion is too slow to do a proper conversation
<mjacob>
oops, i thought that the previous message didn't get through ;)
darkman66 has joined #pypy
<mjacob>
"but hg log -r 6c50bbbada5b does not show 10a7e84783d7 as a decendant" <- i'm still confused about this sentence. hg log doesn't show descendants by default.
darkman66 has quit [Remote host closed the connection]
darkman66 has joined #pypy
adamholmberg has joined #pypy
marky1991 has quit [Ping timeout: 255 seconds]
marky1991 has joined #pypy
adamholmberg has quit [Remote host closed the connection]
darkman66 has quit [Read error: Connection reset by peer]
darkman6_ has joined #pypy
esc has quit [Read error: Connection reset by peer]
jacob22 has joined #pypy
darkman6_ has quit [Remote host closed the connection]
<arigato>
mjacob: I think that hg log -r 'head()' shows revisions with no descendants on the same branch. If that's the case then indeed, it occurs randomly inside pypy
<arigato>
for example if we merge a branch and then later create an unrelated branch with the same name
<arigato>
(of *course* it's a bad idea to do that, but 10 years ago we didn't know that)
darkman66 has joined #pypy
<mattip>
the particular commits I posted are on a single branch. Apparently hg considers a commit that closes a branch to be a head, even if the branch continues
<mattip>
and has decendants
<arigato>
no, I think you're wrong
<arigato>
the two most recent commits on branch shadowstack-again are indeed 1d46f3a5d4c1 and 6c50bbbada5b, both of which are "close" commits, but they are not parents of each other
<arigato>
both of them have exactly one descendant, but they are both on the "closed-branches" branch
<mattip>
so we merged it to closed-branches twice?
<arigato>
yes, it is really structured like two different branches, and each one ends in a "close" followed by a merge to "closed-branches"
<mattip>
ahh, got it
<arigato>
so both "close" commits are branch heads, but that's not directly coming from the fact that they are "close" commits
<arigato>
mjacob: just for reference: it would be easy to fix, by making new commits that merge the multiple heads (but e.g. that keep the most recent of the two trees only)
<arigato>
...and try to break mercurial by trying to see if a merge commit can also be a --close commit :-)
darkman66 has quit [Remote host closed the connection]
darkman66 has joined #pypy
darkman66 has quit [Remote host closed the connection]
darkman66 has joined #pypy
marky1991 has quit [Ping timeout: 244 seconds]
darkman66 has quit [Remote host closed the connection]
darkman66 has joined #pypy
marky1991 has joined #pypy
marky1991 has quit [Remote host closed the connection]
marky1991 has joined #pypy
marky1991 has quit [Ping timeout: 255 seconds]
adamholmberg has joined #pypy
marky1991 has joined #pypy
adamholmberg has quit [Ping timeout: 245 seconds]
Rhy0lite has quit [Quit: Leaving]
darkman66 has quit [Remote host closed the connection]
marky1991 has quit [Remote host closed the connection]
marky1991 has joined #pypy
marky1991 has quit [Ping timeout: 245 seconds]
marky1991 has joined #pypy
<mjacob>
arigato: so, you're proposing to do the same thing as the closed-branch script, but on the same branch?
<mjacob>
an alternative would be to wait until heptapod supports multiple branch heads