<fijal>
cfbolz: ok, so the first issue I think is that HTTPResponse is inheriting from io.BufferedIOBase
<fijal>
in lib-python/3/http/client.py
<cfbolz>
fijal: right
<cfbolz>
fijal: I am wondering whether we can do some kind of quick experiment whether we are thinking about the correct things
<cfbolz>
fijal: and one thing to try might be to quickly run benchmarks with "import _pyio as io" in all these places
<fijal>
I've done some quick experiment (quick and dirty "readline" implementation)( and it's very fast
<cfbolz>
ok, good
<cfbolz>
so then the next question is which level to optimize this on. we can improve the io module
<cfbolz>
or stop using it
<fijal>
I wonder if io module is improvable with the whole abstraction craze
<fijal>
in a way HTTPResponse is using it exactly as advertised (and possibly really bad for the JIT) by abusing all those space.call_method("read") overloads
<fijal>
s/abusing/using/ pick your words
glyph has quit [Quit: End of line.]
glyph has joined #pypy
<cfbolz>
fijal: yes
<cfbolz>
fijal: the pure python version would probably really be better
<fijal>
yes
<fijal>
let me try it
<cfbolz>
or we add careful jit drivers to the io module
<fijal>
I'm quite worried that it's a lipstick on a pig
<cfbolz>
the "systematic" way to do this is to optimize call_method(<some constant>)
<fijal>
it kinda does not help because it's still a call from an arb rpyhton code
<fijal>
(so not a loop)
<cfbolz>
fijal: "it" being what?
<fijal>
adding jit driver
<cfbolz>
right
<cfbolz>
anyway, it's a warmup problem, partly, right?
<cfbolz>
so jitdriver doesn't help
<fijal>
partly, yes
<fijal>
but warming functions from the start is both more effort and works less well
<fijal>
(but a factor is more like 2x than 200x)
<cfbolz>
yeah
<cfbolz>
anyway, let's try pyio?
<fijal>
HTTP/1.1 client library
<fijal>
<fijal>
<intro stuff goes here>
<fijal>
<other stuff, too>
<fijal>
nothing like high quality standard library heh
<fijal>
AttributeError: module 'pyio' has no attribute 'RawIOBase'
<fijal>
cfbolz: ^^^
<cfbolz>
:-(
<cfbolz>
it's _pyio I think?
<cfbolz>
yes
<fijal>
more or less the same
<cfbolz>
hmpf
<cfbolz>
fijal: what happens if you still inherit from io.BufferedIOBase but add your own readline implementation?
<fijal>
good question!
<fijal>
cfbolz: I think I need better benchmarks, more synthetic
<cfbolz>
ok
<cfbolz>
fijal: fwiw, I have a weird idea how to make call_method faster in the interpreter
<cfbolz>
we can add local lookup caches for each call site quite easily
<fijal>
hm
<fijal>
maybe worth doing?
<cfbolz>
fijal: I want to finish the dict stuff I am doing now first (want to try to have that ready for the release)
<cfbolz>
but then I am happy to try it (it's been on my list since a while)
<fijal>
ok cool
<fijal>
cfbolz: I think disregard my answers - it's mostly about the streaming (or not) of the http queries
<fijal>
so establishing new socket takes a while, but I
<fijal>
need to try to streamline that (seems like all http servers/clients can do that anyway)
<cfbolz>
ok
vext01_ has joined #pypy
vext01_ is now known as ebarrett
<ebarrett>
hi #pypy
<ebarrett>
I'm looking to your test suite for inspiration
<ebarrett>
do you have a style of test where you specify IR and a trace through it, and then check the output of the trace compiler?
<cfbolz>
ebarrett: oh hi edd!
<cfbolz>
I'll answer your question in a bit, but also had been meaning to tell you that I put the unipycation branches from the (now dead) fork of pypy that used to live on bitbucket into the main repo
<ebarrett>
so any tests where you say: here's a CFG and suppose the trace took the path 'X -> Y -> Z', the optimised trace should look like <blah>?
<cfbolz>
no, we test that as two steps usually
<cfbolz>
"this code leads to that trace" one test
<cfbolz>
"this trace is optimized like that" other test
<ebarrett>
ok
<cfbolz>
note also that our traces are made out of operations, not control flow edges (?)
<ebarrett>
yep
<ebarrett>
ok, thanks
<cfbolz>
this is the C tracing right? not the hardware tracer?
<ebarrett>
yeah
<ebarrett>
i want tests where i present an LLVM IR module, and a list of blocks a trace passed through, and then test the trace compiler did the right thing
<ebarrett>
it's complicated by our LLVM passes which will change the block structure of the IR
<cfbolz>
right
<cfbolz>
make it as nice as you can, you'll do that a lot :-P
<ebarrett>
yup :)
<Cheery>
There is this old problem that pushes through as I'm thinking about modules. What to do about operators?
<Cheery>
I could introduce typeclasses, but it'd leave a certain kind of a language behind.
<Cheery>
another thing I could do is to just introduce things in different modules and let user choose how they're named.
Atque is now known as hammond
hammond is now known as Atque
Dejan has joined #pypy
Julian has joined #pypy
otisolsen70 has joined #pypy
Julian has quit [Quit: leaving]
<mattip>
cfbolz: the failing app_main tests seem to be checking that