cfbolz changed the topic of #pypy to: #pypy PyPy, the flexible snake | IRC logs: and | the pypy angle is to shrug and copy the implementation of CPython as closely as possible, and staying out of design decisions
Techcable has quit [Remote host closed the connection]
fijal has quit [Server closed connection]
fijal has joined #pypy
[Arfrever] has quit [Ping timeout: 258 seconds]
[Arfrever] has joined #pypy
dmalcolm__ has joined #pypy
dmalcolm_ has quit [Ping timeout: 245 seconds]
[Arfrever] has quit [Read error: Connection reset by peer]
[Arfrever] has joined #pypy
<mattip> hexology: it is difficult to build pyarrow, but it should build successfully
<mattip> it does not pass tests, it seems they do too much in __del__ for PyPy
jinsun_ has joined #pypy
jinsun has quit [Killed ( (Nickname regained by services))]
jinsun_ is now known as jinsun
lehmrob has joined #pypy
lehmrob has quit [Ping timeout: 246 seconds]
<komasa> Is there some API to get the values reported by `gc.get_stats()` ?
<cfbolz> komasa: `gc._get_stats()` maybe?
<komasa> cfbolz: ha, yeah, that seems like exactly what I'd need
lehmrob has joined #pypy
lehmrob has quit [Ping timeout: 252 seconds]
arigato has quit [Server closed connection]
arigato has joined #pypy
cahoots_ has joined #pypy
krono has quit [Server closed connection]
krono has joined #pypy
<hexology> thanks mattip. im glad its not just me
<hexology> i can try to rebuild and post the actual error if that's helpful
<hexology> i
<hexology> i'm not sure it's the same as in the conda-forge issue
<cahoots_> when i do [f(x) for x in array], where f(x) returns x['some_key'], it takes 15x the time of doing [x['some_key'] for x in array] (0.3s vs. 5s, measured repeatedly). is this expected?
<cahoots_> seems like the jit lacks a sort of inlining of f(x)
<nimaje> is that code run often? the jit first counts how often code paths get hit, to not spend time on optimizing code that never gets called again
<cahoots_> nimaje, each time i benchmarked, i ran each piece of code once. len(array) is 13 million
<hexology> cahoots_: i'd be curious of calling f(x) in a for-loop with .append gets optimized or inlined more effectively
<cfbolz> cahoots_: is there a way we can reproduce this?
<cahoots_> cfbolz, the json is ~1gb. but if you make a 13-million element array with like 5 keys with numbers/short strings for values (same data type always for each specific key), you can do just about what i did
<cfbolz> cahoots_: ok, then please paste us the script that is slow in a gist or something
<cfbolz> IndentationError
<arigato> Alex_Gaynor: your move to check cffi's alloca() against the particular vulnerability described. As far as I can tell it's only saying something like "-fstack-protector is supposed to make it more likely that bugs in alloca() would be found, but it doesn't achieve that on aarch64"
<cfbolz> cahoots_: anyway, yes, I would expect the function to be inlined
<cfbolz> cahoots_: but I cannot debug the problem without a runnable example that shows what's wrong
<arigato> Alex_Gaynor: I may be wrong though, but I won't know just by reading the first few lines of general explanation
<Alex_Gaynor> arigato: Yes, I think that's right. My question was really "does it use alloca", if yes then we'll probably do a release that rebuilds our wheels witht he fixed compiler.
<arigato> then yes
<cahoots_> cfbolz, i've updated it, just doesn't have the full array
<cahoots_> now it runs at least
<cahoots_> i don't have time to send over the array unfortunately
<cfbolz> cahoots_: ok. are the ticker entries floats?
<cahoots_> cfbolz, they are string of 1-5 letters
rwb has quit [Quit: ZNC -]
<arigato> cfbolz: note that if the dicts come from JSON, they may have a special representation
<cfbolz> yep
<cahoots_> yeah they come from json.load
<arigato> cahoots_: basically I'm saying I doubt the script will give the observed slow-down out of the box; it's likely to be tied to some of the details of the loop as it occurs in your program
<cfbolz> cahoots_: which pypy version are you running?
<cfbolz> indeed, for me the last two versions are always the same speed, no matter what I tried
<cahoots_> Python 3.10.12, PyPy 7.3.12 with GCC Apple LLVM 13.1.6
<arigato> I could only imagine a very bad case where the function mapo() happens to be marked as "don't inline" by some earlier unrelated code
<cfbolz> yeah, but it would have to be really weird, basically
<arigato> yes
<cfbolz> right, if I force the marking of mapo as non-inlinable I can get pretty weird effects
Alex_Gaynor has quit [Server closed connection]
Alex_Gaynor has joined #pypy
cahoots_ has quit [Ping timeout: 255 seconds]
cahoots_ has joined #pypy
rwb has joined #pypy
lehmrob has joined #pypy
otisolsen70 has joined #pypy
hpk has quit [Server closed connection]
hpk has joined #pypy
otisolsen70 has quit [Quit: Leaving]
ruth2345345 has quit [Ping timeout: 255 seconds]
<hexology> does anyone know if this pyproj/cython build failure is fixable to run in pypy? this is beyond my knowledge to debug
<hexology> or maybe it's a cython 3.x 0.x incompatibility unrelated to pypy, i know it has significant breaking changes
<hexology> aha yep this is just a cython issue / they aren't pinning their pep 517 build deps correctly
ruth2345345 has joined #pypy
lehmrob has quit [Remote host closed the connection]
eamanu has quit [Server closed connection]
eamanu has joined #pypy
jinsun has quit [Read error: Connection reset by peer]
jinsun has joined #pypy