cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://quodlibet.duckdns.org/irc/pypy/latest.log.html#irc-end ) | use cffi for calling C | if a pep adds a mere 25-30 [C-API] functions or so, it's a drop in the ocean (cough) - Armin
<kingsley>
I've been steadily improving my benchmark.
<kingsley>
I tried to let it find
<kingsley>
1.) the fastest number of multiplications to do, which may depend on any given CPU's cache size. For example, POWER9 evidently has a big 120 MB L3 cache, so maybe it would perform each multiplication faster if, in total, more are done.
<kingsley>
2.) the fastest number of CPU cores to actually use.
<kingsley>
Plus, I cut down my python bench mark to just 15 lines of code. All commented.
<kingsley>
I've been testing it on an old AMD Athlon(tm) 64 X2 Dual Core Processor 5200+.
<kingsley>
It has 2 cores.
<kingsley>
Each runs at 2.6 GHz.
<kingsley>
Its cache is evidently only a fraction of POWER9: 2 MB.
<kingsley>
I ran it with python2, python3 and pypy.
<kingsley>
Since python2 and 3 performed similarly, I simplified the chart of results to only python3 and pypy.
<kingsley>
Please consider running it with pypy3 and letting us, and at least me, know how it is on your computers.
<kingsley>
And which CPU(s) you used.
<kingsley>
It seems to me that knowing how to run a language as popular as python fast is a good thing.
<kingsley>
So
<mattip>
kingsley: please try to engage with responses to your previous posts here, IRC is a two-way communication channel
<kingsley>
mattip: Is there a particular response you'd suggest I engage with?
<mattip>
<arigato> sorry, I'm trying to explain why I don't believe you're really doing something interesting here
<mattip>
<arigato> float multiplication is an extreme example: you could try to benchmark it by writing C code---at least you have a better idea of what you're really testing, but it is still a hard exercice
<mattip>
<arigato> the point in pypy is that any float multiply turns into just one CPU instruction after a lot of JIT-compiling takes place
oberstet has joined #pypy
<kingsley>
mattip: Thank you.
<kingsley>
It seems to me that arigato raised reasonable concerns.
<kingsley>
If I might offer my point of view...
<kingsley>
The C programming language is revered, respected, popular, and all those good things.
<kingsley>
But, so is python.
<kingsley>
Especially for data science.
<kingsley>
You can see this is so because it's ranked as a popular language for data scientists at
<kingsley>
arigato also wrote that pypy's JIT-compiling reduces any float multiplication into a machine instruction.
<kingsley>
I hope he or she is right.
<kingsley>
It'd be a cool accomplishment.
antocuni has joined #pypy
<kingsley>
And, I would like to humbly add that even if it's 100% correct, benchmarks, including mine, can discern other interesting ways to maximize performance.
<mattip>
you could check it by translating your benchmark to C, that should provide a lower bound
<gracinet>
cfbolz: another possibility, since it's displayed as part of the commit message, is to filter by it in the branch view. I agree it's not very satisfying
<gracinet>
that means you have to copy-paste the branch name in the search field, though
<gracinet>
we can look into improving these views with Mercurial-specific filtering etc, but again I'd prefer to do it later than sooner :-)
<arigato>
If that is the extent of our "blockers" I think that means we're pretty happy
<gracinet>
in the meanwhile, don't hesitate to file these as issues on dev.heptapod.net, it'll help us keep track of what users want, even if I end up scheduling them for later versions
<gracinet>
arigatoi: :p
<gracinet>
More specifically, are you happy with how issues have been imported from bitbucket ?
<cfbolz>
gracinet: about issues: the usernames need mapping, somehow
<cfbolz>
or we need to know the original user names in the issues somehow
<cfbolz>
also, we need to persist the original issue numbers in some way
<gracinet>
cfbolz: I reckon it does. The thing is, it's supposed to map automatically if people's accounts have been tied to their Bitbucket account (I suppose that means they logged in with the SSO capability of Heptapod). And that's a bit too much to ask
<cfbolz>
yes, particularly for drive-by issue openers
<gracinet>
I have the same problem with other imports, what would be an appropriate minimum for you ?
<cfbolz>
gracinet: replace the "Created by: Anonymous" with "Created by: bitbucket user"
<cfbolz>
I mean, the actual user name
<gracinet>
cfbolz: and also, I can have only one OAuth2 bitbucket application at a given time. I'm not finished exploring the consequences of this, but it could be inacceptable permission -wise for SSO logins
<gracinet>
cfbolz: I'll look at possibilities, didn't introspect what Heptapod actually receives from Bitbucket (hope it's not a numeric id)
<cfbolz>
ok
<gracinet>
I'll keep you guys posted about this anyway
<cfbolz>
gracinet: thanks for all your hard work!
<gracinet>
depends how much you are in a hurry to reach a decision
<gracinet>
cfbolz: my pleasure !
<cfbolz>
gracinet: we are not super in a hurry yet, I think
<cfbolz>
gracinet: out of curiosity, how hard is it to keep up with gitlab evoluation?
<gracinet>
cfbolz: I'm just being started on that
<gracinet>
did a patch-number update for Heptapod 0.6 (GitLab 10.1.4 -> 10.1.7), that was pretty trivial
<gracinet>
had to do some work in Heptapod itself to properly track the branches upstream GitLab uses, will bump to 10.2 or 10.3 for Heptapod 0.7
<gracinet>
We already know that GitLab 11 will require us to implement a big server-side component, and that's also what will allow us to get rid of hg-git
<cfbolz>
oh, interesting!
<gracinet>
that being said, repository integration is but a tiny part of GitLab, so I'm not too worried
<gracinet>
but we will need support, that's for sure
<gracinet>
(financial support or contributor time)
<kenaan>
cfbolz default 5dd2d3cca75b /rpython/jit/metainterp/quasiimmut.py: debug-print quasi-immutable invalidations (been wanting that since a while)
<kenaan>
stevie_92 cpyext-gc-cycle 30c564b06dd8 /: Check state during cpyext rrc gc processing (incorrect state after garbage handling) Handle non-gc obje...
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
dddddd has quit [Ping timeout: 268 seconds]
dddddd has joined #pypy
Rhy0lite has quit [Quit: Leaving]
jacob22_ has joined #pypy
jacob22 has quit [Read error: Connection reset by peer]
<kenaan>
rlamy default 9b953c97479f /requirements.txt: Stop updating hypothesis: 4.40 is incompatible with our ancient pytest
<kingsley>
Does pypy use LLVM?
<Alex_Gaynor>
No
<mattip>
cfbolz: do you have a clue about what happened to unicode_encode_utf_8_elidable on win32? It no longer translates py3.6
<firespeaker>
I just did a new install of pypy3 with apt on another debian unstable machine and get this: ['', '/usr/lib/pypy3/lib_pypy/__extensions__', '/usr/lib/pypy3/lib_pypy', '/usr/lib/pypy3/lib-python/3', '/usr/lib/pypy3/lib-python/3/lib-tk', '/usr/lib/pypy3/lib-python/3/plat-linux2', '/usr/lib/python3/dist-packages']
<tos9>
I *guess* they're thinking "oh we can basically reuse python3-* instead of having pypy specific packages"
<tos9>
but that doesn't work for non-universal wheels? So not sure how that idea would make sense
<tos9>
I am... quite surprised to see this is how they tried to make this work though
<tos9>
Maybe someone else is more informed, but they're all likely asleep on EU hours
<firespeaker>
so what can be done?
<firespeaker>
just poke people when they're awak?
<firespeaker>
e
<tos9>
Yes -- also I have vague recollection that the debian maintainer is in here
<firespeaker>
would not be surprised
<tos9>
So maybe they'll straighten me / us out tomorrow and explain whatever I'm missing
<firespeaker>
:D
<tos9>
(it's also possible debian does things I don't know about, like have the ability to somehow swap out the target files for a package with the same name based on whatever the current system alternative is or whatever it's called? I really do know quite little about it)
<tos9>
but yeah I think your best option is either to ask again in the morning, but pypy folks will likely not have much more info on debian's packaging choices, or better is likely filing a bug on the debian issue tracker with a reproducer saying you can't install pip to pypy3
<tos9>
or give up on all of this and just install portable pypy
<firespeaker>
portable pypy?
<firespeaker>
isn't debian's preferred method for reporting issues to send stuff to the mailing list?
<firespeaker>
it's like git; I tried to submit a patch to their documentation as a PR, and they were like "why don't you just email this patch to our mailing list"
<firespeaker>
and I was like, I have better things to do; git's documentation can go with some ambiguity for all I care. if they want to fix it they can