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
oberstet has quit [Quit: Leaving]
fijal has quit [Ping timeout: 268 seconds]
fijal has joined #pypy
jcea has quit [Quit: jcea]
lazka0 has joined #pypy
lazka has quit [Quit: Ping timeout (120 seconds)]
lazka0 is now known as lazka
raekye has quit [Ping timeout: 260 seconds]
raekye has joined #pypy
_whitelogger has joined #pypy
_whitelogger has joined #pypy
isidentical has joined #pypy
isidentical has quit [Read error: Connection reset by peer]
isidentical has joined #pypy
<fijal> does ujson ever work on pypy?
<fijal> we don't have wheels for OS X/numpy/pypy combo right?
oberstet has joined #pypy
<cfbolz> fijal: it used to work at some point I think
<fijal> wheels?
<fijal> or used to compile?
<cfbolz> Used to compile
<antocuni> fijal: ujson works but pypy's our json should be faster
<antocuni> at some point I heavily optimized the rpython code to do json parsing based on ujson's code
<antocuni> see _pypyjson
<cfbolz> And I then tried to steal the best V8 ideas
<fijal> antocuni: I can't compile it
<fijal> on OS X
<antocuni> you can't compile ujson?
<antocuni> ah no wait
<antocuni> it might be that it never worked
<antocuni> sorry, I don't remember :)
<cfbolz> ok, we have a translating (but still rather broken) 3.8
<antocuni> cfbolz: good job
<cfbolz> next step: implementing enough things to get unittest to work :-(
pmp-p has quit [Ping timeout: 240 seconds]
pmp-p has joined #pypy
jcea has joined #pypy
phoe6 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
andi- has quit [Ping timeout: 258 seconds]
Dejan has joined #pypy
<Dejan> Happy New Year
Guest80090 is now known as ronan
andi- has joined #pypy
<cfbolz> Dejan: same!
lukasa has left #pypy [#pypy]
<Dejan> Any ETA on when will there be a semi-working 3.8 branch?
<Dejan> My company moved entirely to 3.8, that is why I wonder that
<cfbolz> Dejan: we started
<cfbolz> Working is still a bit away
<mattip> trying to figure out why the jit cannot make the pure python pickle faster
<mattip> it seems there is an "optimization" to write values via a frame into a io.BytesIO() stream
<mattip> turning that off makes the benchmark ~30% faster
<mattip> but now the FRAME opcode is missing
<mattip> maybe I can swap out the BytesIO for a BytesBuilder ?
<ebarrett> hey folks
<cfbolz> mattip: what's the input data in the test?
<cfbolz> ebarrett: hey edd!
<ebarrett> hey cfbolz
<ebarrett> I hope life is OK given... the world right now!
<ebarrett> I was hoping I could ask some questions about blackholing
<ebarrett> What do you do when you exit a trace via a guard failure, and the branch you start interpreting relies on a computation that was optimised out of the trace on account of being dead code in the context of the trace?
<ebarrett> do you a) not optimise those computations out, or b) stash enough info to perform the computations later?
<cfbolz> dead code in which sense?
<cfbolz> we do both, I think
<ebarrett> is there any info on this somewhere? or can you point me at code?
<ebarrett> i've followed the reference trail to the trace trees paper, but it doesn't go into enough detail
<cfbolz> ebarrett: do you know the guards paper by david schneider and me?
* ebarrett looks it up
<ebarrett> "The Efficient Handling of Guards in the Design of RPython’s Tracing JIT"
<ebarrett> I'll give it a gander, thanks
<cfbolz> yes
panosl[m] has joined #pypy
<cfbolz> ebarrett: but my counter-question is still "dead code in which sense" ;-)
<ebarrett> we had a minimal example before xmas -- let me see if i can find it, or if it's lost to the sands of time
<ebarrett> cfbolz: suppose we trace the true branch of this: https://gist.github.com/vext01/cc538135175d232bf0b03297bbd29258
<ebarrett> the trace optimiser might reasonable remove `let b = ...`
<ebarrett> but if we blackhole into the false branch, that means `b` is non-existant
<ebarrett> *reasonably
<cfbolz> and what is the b = ...
<cfbolz> ?
<cfbolz> that's what I mean with my "it depends"
<cfbolz> if b = new IntObject, then we remove the new, and materialize it only on guard failure (see the paper)
<cfbolz> if b = int_add(a, 12), then we always just do the operation
<ebarrett> so if it already exists, you may aswell do the operation?
<cfbolz> is your question "why not also remove int_adds?"?
<ebarrett> i should read the paper :)
<cfbolz> we focus on boxing, since that is often expensive
<cfbolz> integer operations often aren't
<ebarrett> thanks, i'll come and bug you more if there are still outstanding questions :)
<cfbolz> and delaying them till later guards has downsides, for example it extends the lifetime of a, which might lead to register pressure
<mattip> cfbolz: the input data is various dicts, lists, and tuples, each composed of various objects
<ebarrett> cfbolz: ok, so the end of section 3.2 is the nugget i was after
<mattip> with no custom classes
lritter has joined #pypy
<ebarrett> cfbolz: having an ssa bytecode allows you to replay any missing computations...
<cfbolz> ebarrett: hm?
<cfbolz> We don't have a full ssa based bytecode
<ebarrett> so at the end of the section you say an as-yet unfabricated value could be a "rereferece" to an SSA variable
<ebarrett> i wonder how you deal with the case where the value could change if it isn't fully SSA?
<cfbolz> the trace is SSA
<cfbolz> but the bytecode in section 3.2 is the per-guard bytecode
<cfbolz> mattip: maybe we can narrow it down to which of the data types is slow
<fijal> cfbolz: does that paper contain my space optimization work?
<fijal> might be harder to read the code if it doesn't
<cfbolz> fijal: it does not
<cfbolz> fijal: is there a detailed blog post about that?
<fijal> I'm not sure
<cfbolz> fijal: note however that the paper mainly talks about virtuals, and they remained the same
<mattip> cfbolz: pypy3.7 relative to CPython3.7:
<mattip> pickle is ~3.5x slower, pickle_dict ~7.5x, pickle_list ~2.5x, unpickle ~2.5x, unpickle_list ~2.1x
<mattip> there doesn't seem to be a unpickle_dict benchmark
<cfbolz> Right (kind of expected dicts to worst)
<cfbolz> *be
<mattip> the pickle_dict one tests this
<mattip> MICRO_DICT = dict((key, dict.fromkeys(range(10))) for key in xrange(100))
<fijal> ok
<cfbolz> yay, so now unittest runs
<bbot2> Started: http://buildbot.pypy.org/builders/own-win-x86-64/builds/137 [Carl Friedrich Bolz-Tereick: force build, py3.8]
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-lib-python-linux-x86-64/builds/62 [Carl Friedrich Bolz-Tereick: force build, py3.8]
<cfbolz> grmble, of course I should actually push first
<bbot2> Exception: http://buildbot.pypy.org/builders/pypy-c-lib-python-linux-x86-64/builds/62 [Carl Friedrich Bolz-Tereick: force build, py3.8]
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-lib-python-linux-x86-64/builds/63 [Carl Friedrich Bolz-Tereick: force build, py3.8]
<cfbolz> panosl[m]: just accpted your request
<bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-lib-python-linux-x86-64/builds/63 [Carl Friedrich Bolz-Tereick: force build, py3.8]
<bbot2> Failure: http://buildbot.pypy.org/builders/own-win-x86-64/builds/137 [Carl Friedrich Bolz-Tereick: force build, py3.8]
<mattip> swapping BytesBuilder for io.BytesIO reducese pickle_dict from ~1.25 to ~1.00
sven has quit [Quit: ZNC 1.7.4 - https://znc.in]
<mattip> but it did not move the pickle_list and pickle_dict benchmarks
<mattip> weird
<mattip> let's see what happens in benchmarks
sven has joined #pypy
sven has quit [Read error: Connection reset by peer]
sven has joined #pypy
isidentical has quit [Remote host closed the connection]
Cheery_ has quit [Quit: leaving]
Cheery has joined #pypy
oberstet has quit [Quit: Leaving]
lritter has quit [Quit: Leaving]