These are chat archives for dropbox/pyston

9th
Jul 2015
let’s rewrite pyston in rust!!:D
andrewchambers
@andrewchambers
Jul 09 2015 04:45
Haha, I think with jit etc, half your code will be in unsafe blocks
Chris Toshok
@toshok
Jul 09 2015 05:41
Click says do it in Java :)
Travis Hance
@tjhance
Jul 09 2015 06:28
how are the numbers in investigate.py calculated?
like if I have 20 runs of each benchmark
does it use the latest? the average?
Chris Toshok
@toshok
Jul 09 2015 06:29
Minimum iirc
Travis Hance
@tjhance
Jul 09 2015 06:29
ooh
so that explains why I see the following trend: commit A has 20 runs, commit B has 0, commit A is initially a lot faster, and the difference steadily decreases with number of runs
Travis Hance
@tjhance
Jul 09 2015 06:35
also saved runs from an earlier day might jut be outliers
or like
different
Chris Toshok
@toshok
Jul 09 2015 06:44
yeah, i had problems with non-hash related variables, like my LD_PRELOAD=jemalloc stuff
but fixable
Travis Hance
@tjhance
Jul 09 2015 06:52
yeah I was considering throwing out this commit because it was +1% but then I cleared out everything and reran, and it ended up being no perf impact
Marius Wachtler
@undingen
Jul 09 2015 16:22
@toshok I noticed that the baseline JIT fails the test/tests/incremental_tb.py when enabled (one has to set REOPT_THRESHOLD_INTERPRETER to 1 to reproduce). It adds a lot of additional raise a, b, c traceback lines. Do you have an idea what I'm doing wrong? The exc handling support for the bjit is inside ASTInterpreter::executeInner
Marius Wachtler
@undingen
Jul 09 2015 16:50
ok I think I have found it. It's important that the try catch block is not inside the executeInner function
When I split it out into a method and make sure that it won't get inlined it prints the correct output
:-)
Rudi Chen
@rudi-c
Jul 09 2015 17:23
@tjhance happens to me a lot
Chris Toshok
@toshok
Jul 09 2015 17:45
This message was deleted
Rudi Chen
@rudi-c
Jul 09 2015 17:45
Woah it embeds a whole slideshow
Chris Toshok
@toshok
Jul 09 2015 17:45
there, that’s better
@undingen ah yeah. I meant to add a comment to that effect there (do not use try/catch in executeInner). is there a way to decorate a c++ method such that it will fail to compile if try/catch are used?
Marius Wachtler
@undingen
Jul 09 2015 17:47
thanks for the slides, sounds interesting
Chris Toshok
@toshok
Jul 09 2015 17:48
but that particular rule (no catch in executeInner) wasn’t really about duplicate frames, it was to keep from crashing while accessing the interpreter map (since the unwinding would resume after the cleanup handler removed the ASTInterpreter from the map, but the $rip was still in ::execute, so we’d try to look it up, etc
Marius Wachtler
@undingen
Jul 09 2015 17:49
I think all exception attributes are just about what happens when an exception escapes. So I don't think there is one for a try/catch block :-(
Chris Toshok
@toshok
Jul 09 2015 17:49
yeah :/
was the catch block you added in ::executeInner rethrowing the exception?
Marius Wachtler
@undingen
Jul 09 2015 17:50
It's already there on trunk :-D, yes it's in some cases rethrowing the exception
if it can't find an invoke
Chris Toshok
@toshok
Jul 09 2015 17:52
PR #642 has void throwReraise(ExcInfo e), which might just be a drop in replacement for that throw and might fix the duplicate frame problem
Marius Wachtler
@undingen
Jul 09 2015 17:54
man this conference sound interesting and wouldn't have been very far away from where I'm located.
Chris Toshok
@toshok
Jul 09 2015 17:54
yeah, i’m really bummed - I’d never even heard of it
ecoop yes, curry-on, no
Chris Toshok
@toshok
Jul 09 2015 18:03
also this Go GC talk looks interesting. wish they had video of both this and Click's: sourcegraph.com/blog/live/gophercon2015/123574706480
Chris Toshok
@toshok
Jul 09 2015 20:17
pretty sick of the small animals in my life :/
Travis Hance
@tjhance
Jul 09 2015 20:18
?
do you have a temperamental pet hamster, or something?
Chris Toshok
@toshok
Jul 09 2015 20:19
today has been an exercise in fitting work in between bouts of cleaning up the house (cats went on a minor rampage while I was away)
Travis Hance
@tjhance
Jul 09 2015 20:21
oh
I miss my cats back home in ohio, even though every time I visit they’re kinda mean to me (I don’t think they remember me) and I always have to kick them out of my room when I sleep, and I’m probably allergic to cats
but they’re really cute<3
Chris Toshok
@toshok
Jul 09 2015 20:24
yeah, they’ve been really attached to me today (really hard up for attention), and very cute, but.. ugh :)
Rudi Chen
@rudi-c
Jul 09 2015 20:25
are they trying to walk in front of your screen at this very moment by any chance :P?
Chris Toshok
@toshok
Jul 09 2015 20:28
not at the moment, but 30 minutes ago… http://imgur.com/R1SSUps
not at the moment, but 30 minutes ago… imgur.com/R1SSUps
Rudi Chen
@rudi-c
Jul 09 2015 20:29
The brown one is so fluffy
Travis Hance
@tjhance
Jul 09 2015 20:32
awww
wops permissions
My cat is really chubby
We've completely moved from freenode to gitter right? Or is the freenode still ocassionally used?
Marius Wachtler
@undingen
Jul 09 2015 20:39
I think your cat pics crashed gitter for me... :-D
Travis Hance
@tjhance
Jul 09 2015 20:40
we ever used freenode?
Rudi Chen
@rudi-c
Jul 09 2015 20:41
Cats > Internet
I'm making a pass to update some stuff though
I'll take that as a no :P
Travis Hance
@tjhance
Jul 09 2015 20:42
idk maybe there’s been a party on freenode and i’ve been missing out
Chris Toshok
@toshok
Jul 09 2015 20:42
wow, gitter is really having issues now :)
Travis Hance
@tjhance
Jul 09 2015 20:42
idk maybe there’s been a party on freenode this whole time and i’ve just been missing out
Chris Toshok
@toshok
Jul 09 2015 20:42
keeps losing messages and shifting current viewport
Rudi Chen
@rudi-c
Jul 09 2015 20:42
It still says that in the .md files
Chris Toshok
@toshok
Jul 09 2015 20:43
we still send travis-ci notifications there too, iirc
Travis Hance
@tjhance
Jul 09 2015 20:43
guess we should move back to freenode
Rudi Chen
@rudi-c
Jul 09 2015 20:43
weird
Chris Toshok
@toshok
Jul 09 2015 20:43
could have sworn I saw that in the .travis.yml file
oh, maybe we don't
Rudi Chen
@rudi-c
Jul 09 2015 20:44
just as I was talking about gitter...must be my fault :P
Marius Wachtler
@undingen
Jul 09 2015 20:45
gitter was before offline for me for about 2h
not offline. It never finished loading and just displayed a blank page
Chris Toshok
@toshok
Jul 09 2015 20:47
yeah I had that for sometime yesterday, and the mobile app is still doing that for me
Travis Hance
@tjhance
Jul 09 2015 20:48
but I usually don’t have problems with the desktop app
the mobile app does that sometimes
Kevin Modzelewski
@kmod
Jul 09 2015 21:29
I'm thinking it's worth committing changes that are clearly improvements even if they are negligible
A 0.5% improvement is below our ability to measure it reliably
but if we can accumulate 150 of those we are at cpython's speed :P
my feeling is that we just have a lot of small improvements we need to make
and we just need to chip away at them
Travis Hance
@tjhance
Jul 09 2015 21:37
right that makes sense
Marius Wachtler
@undingen
Jul 09 2015 22:00
I compared the stats between a normal django_template run and one with forced interpreter mode (which means that the interpreter + baseline jit are enabled):
4sec vs 6.5 (interpreter)
largest slowdowns are:
us_timer_gc_collection: 486876 --> 908714
us_timer_unwinding 391833 --> 601234
us_timer_slowpath_callattr: 74886 --> 161896
us_timer_slowpath_runtimecall: 112455 --> 152766
Chris Toshok
@toshok
Jul 09 2015 22:08
interesting. i wouldn’t have expected the first one to be so different
Marius Wachtler
@undingen
Jul 09 2015 22:15
you mean the overall time? yes I'm also surprised by this.
Chris Toshok
@toshok
Jul 09 2015 22:18
no, gc_collection
Marius Wachtler
@undingen
Jul 09 2015 22:24
yeah I think this caused by the ASTInterpreter Box object... it's quite large and get's created a very large number of times...
I had a patch which only allocated sizeof(void*). will try it with that change...
Chris Toshok
@toshok
Jul 09 2015 22:30
oh right, I saw that patch
another possibility is to use the root handler functions from toshok/pyston@4e66411. then you can keep ASTInterpreter’s as large as you want and not allocate them from the gc heap.
Marius Wachtler
@undingen
Jul 09 2015 22:31
just for fun: I ran pyxl_bench with -O (=force max opt don't use interpreter). if I pretend JITing won't take any time (subtract the time it took to JIT all the functions): we are at 2.6secs. Normal time: 4.0secs. cpython: 1.9secs
I'm not totally sure what this means. But I get somewhat encouraged that JIT is very important and that trying to get the baseline JIT to generate code with the nearly the same speed as LLVM but much faster code generation is very important
Chris Toshok
@toshok
Jul 09 2015 22:38
the ASTInterpreter Box object is on master, right?
Marius Wachtler
@undingen
Jul 09 2015 22:38
@toshok this is nearly what I need but not exactly: I GC allocate the interpreter because I want to get notified when the interpreter isn't reachable anymore in order to remove it from the interpreter map (this is afaik only important for generators normal stuff jsut goes out of scope).
yes
Chris Toshok
@toshok
Jul 09 2015 22:39
oh so the interpreter has a tp_dealloc/simple_destructor?
Marius Wachtler
@undingen
Jul 09 2015 22:39
yes
Chris Toshok
@toshok
Jul 09 2015 22:39
wow, yeah. #collections is 82 with -I, 51 without
hm, definitely need a different way to handle that if possible
Marius Wachtler
@undingen
Jul 09 2015 22:40
it's really ugly to have to allocate the whole interpreter instance with the GC just to clean up the mem in case a generator object is not reachable anymore but doen't have exited...
Chris Toshok
@toshok
Jul 09 2015 22:41
it’s still a map from rbp to ASTInterpreter, right? do we assert that there isn’t already an rbp key in the map?
(before adding it, that is)
Marius Wachtler
@undingen
Jul 09 2015 22:43
yes, but @rudi-c had a problem with duplicate entries a few weeks ago (sorry didn't look into that :-(). Did this problem resolve?
and no we don't assert...
Chris Toshok
@toshok
Jul 09 2015 22:51
might prove dangerous, since there’s no guarantee that a gc will be timely enough to clear it from the map before rbp is reused
Marius Wachtler
@undingen
Jul 09 2015 22:55
but we will always remove it if the RegisterHelper goes out of scope (which should happen in all normal cases)
Chris Toshok
@toshok
Jul 09 2015 22:57
right, was wondering about that - so the simple destructor is for generators where we lose references to them before they’ve resumed and exited the frame with the RegisterHelper
Marius Wachtler
@undingen
Jul 09 2015 22:59
There a two ways to remove the entry from the map: RegisterHelper goes out of scope: 1. this is the case which gets triggered nearly all of the time. In this case we would not have needed to allocate the Interpreter with the GC.
2. we are in an generator and execute some code and yield back... main code throws all references away. RegisterHelper will never go out of scope so we have to remove it with the simpleDestructor
Kevin Modzelewski
@kmod
Jul 09 2015 23:02
that's a pretty big difference between -O and -I
2.6s vs 6.5
a lot more than I would have expected... hopefully there's a silver lining that the differences are easy to spot?
Rudi Chen
@rudi-c
Jul 09 2015 23:04
@undingen Yes the problem was resolved. I don't quite remember what it was but I think the ASTInterpreter bug was not the root cause.
Travis Hance
@tjhance
Jul 09 2015 23:23
could you just allocate the ASTInterpreter on the stack?
Marius Wachtler
@undingen
Jul 09 2015 23:26
We did that, but this won't work for the unreachable generators because we will never unwind the stack / call the destructors for stack alloced mem
we just unmap the memory
Chris Toshok
@toshok
Jul 09 2015 23:26
yeah, the problem is the dtor
Marius Wachtler
@undingen
Jul 09 2015 23:29
mmh maybe we could traverse the interpreter map inside the generator simpleDestructor and remove all entries which are contained inside the current memory the current generator alloced?
Chris Toshok
@toshok
Jul 09 2015 23:29
once django_template.py reaches its steady state here’s before/after heap usage for a given gc (numbers show very small variation):
Collection #49
25482 heap stats: (p: 10.2M/144435, C: 1.8M/20676, Cp: 1.3M/3763, U: 1.6M/17752, h: 904.5K/4135, P: 486.2K/8803)
Collection #49 done
25482 heap stats: (p: 6.7M/73969, C: 694.9K/11447, Cp: 85.6K/591, U: 556.8K/5063, h: 885.7K/4049, P: 347.9K/4273)
p = python, C = conservative, Cp = conservative python, U = untracked, h = hcls, P = precise
Chris Toshok
@toshok
Jul 09 2015 23:44
that appears to be the working set for django_template too. even letting the gc tune allocBytesForNextCollection shows:
Collection #5
25539 heap stats: (p: 49.0M/898476, C: 14.0M/117667, Cp: 14.3M/37062, U: 13.1M/150643, h: 1.1M/5053, P: 1.9M/55725)
Collection #5 done
25539 heap stats: (p: 6.8M/74218, C: 693.7K/11430, Cp: 83.8K/590, U: 566.4K/4791, h: 885.7K/4049, P: 340.8K/4011)