cfbolz changed the topic of #pypy to: #pypy PyPy, the flexible snake https://pypy.org | IRC logs: https://quodlibet.duckdns.org/irc/pypy/latest.log.html#irc-end and https://libera.irclog.whitequark.org/pypy | Matti: I made a bit of progress, the tests now only segfault towards the end
tsraoien has quit [Ping timeout: 245 seconds]
tsraoien has joined #pypy
tsraoien has quit [Ping timeout: 252 seconds]
lritter has quit [Ping timeout: 240 seconds]
lritter has joined #pypy
jcea has quit [Ping timeout: 272 seconds]
j4at has quit [Ping timeout: 252 seconds]
j4at has joined #pypy
Techcable has quit [Remote host closed the connection]
Techcable has joined #pypy
Techcable has quit [Remote host closed the connection]
Techcable has joined #pypy
lritter has quit [Quit: Leaving]
<cfbolz> j4at: right, I get it now, nice!
<cfbolz> It's saves one list copy
j4at has quit []
j4at has joined #pypy
<j4at> cfbolz: yead, extend is very broken in PyPy other than that
<j4at> Also, enjoy your vacation :)
<cfbolz> j4at: well, "very broken". I am still not 100% convinced people use huge tuples in practice ;-)
<j4at> I used lists tho in the exemples
<j4at> tuples and lists
<cfbolz> the .extend(b) example is slow by necessity. it rewraps all the ints
<cfbolz> not much you can do, if you want to keep optimizing int lists
<j4at> ow makes sense
<cfbolz> j4at: btw, the thing you found, (tuple extend case in empty list), do you want to open a pull request for that?
<j4at> cfbolz: I do :)
<j4at> well, I don't know if I fixed correctly tho
<j4at> take a look
<cfbolz> j4at: I'm not completely sure. I would try first to even kill the W_AbstractTuple cases in EmptyListStrategy._extend_from_iterable completely
<cfbolz> because for small tuples there is a case in the caller of _extend_from_iterable, which is ListStrategy.extend
<cfbolz> and for long tuples, the generic code path, which ends up in _do_extend_from_iterable is better
<j4at> cgbolz: From what I remember, removing it completly makes extending tuples with object elements slower.
<j4at> sfbolz *
<cfbolz> right, plausible
<cfbolz> so yes, that means some more complex code is required (the unpackiterable_* and listview_* functions actually will return None for float
<cfbolz> )
<cfbolz> None for tuple I mean
<cfbolz> so moving the tuple case down is not gonna help
<fijal> cfbolz: I *think* that tuple is a way to say "this is an immutable list" too
<fijal> which means that people will use it for immutable stuff
<fijal> (how big you want your immutable things? I don't know)
<fijal> 1024 is not massive though
<cfbolz> fijal: all good, i'm not against improving some things around them. but before implementing tuple strategies, I'd like to see the benchmarks first ;-)
<fijal> yeah sure
<j4at> Well that's out of my league, good luck for whoever tries to fix this.
<j4at> Some benchmakrs
<cfbolz> j4at: heh, now I found a truly bad case: s = [1, 6, 3, 1, None]; s[:] = big_tuple_with_ints
<cfbolz> it's like 25x slower than cpy for me
<j4at> empty list is x90 slower than cpy :p
<cfbolz> not so great
<cfbolz> j4at: would you add it as a comment to your issue?
<j4at> I'm not sure! You can add it if you want! It's kinda of a duplicate issue because I opened another issue before it about how creating tuples/lists./sets is slower in PyPy.
<cfbolz> it's all the same pattern, really
<j4at> tuple(list_int) is O(n^2)
<j4at> Not important at all. because pypy becomes slower than cpy only after 2^11. Even if you have 2^18 list that's only 4 times slower than pypy
j4at has quit [Ping timeout: 245 seconds]
j4at has joined #pypy
jcea has joined #pypy
j4at has quit [Ping timeout: 245 seconds]
j4at has joined #pypy
Atque has quit [Ping timeout: 268 seconds]
Atque has joined #pypy
tsraoien has joined #pypy
Atque has quit [Remote host closed the connection]
Atque has joined #pypy
jcea has quit [Ping timeout: 272 seconds]
Atque has quit [Ping timeout: 268 seconds]
Atque has joined #pypy
<j4at> I think I found the actual problem :)
<LarstiQ> j4at: what is it?
<j4at> I should test it first. But basically it produces big traces.
<j4at> and retrace forever
<cfbolz> j4at: yeah, that's the 90x problem for sure
<cfbolz> I fixed infinite retracing last year, but seems this case isn't covered by the solution
Atque has quit [Ping timeout: 268 seconds]
Atque has joined #pypy
<j4at> What doesn't make sense to me is why its producing big traces? That shouldn't happen unless it's unrolling, right ?
<j4at> I also found out that PyPy doesn't optimize type-homogeneous list comparison unlike CPython!! PyPy is x20 slower than Cpython in list comparison
<j4at> Cpython is always faster even with tiny lists
<j4at> x20 with size 256
lritter has joined #pypy
j4at has quit [Ping timeout: 245 seconds]
j4at has joined #pypy
j4at has quit []
jcea has joined #pypy