These are chat archives for dropbox/pyston

18th
Apr 2015
Ian Kronquist
@iankronquist
Apr 18 2015 00:26
Is Pyston a tracing JIT or a whole method JIT?
Travis Hance
@tjhance
Apr 18 2015 00:27
whole method JIT
for the most part
Ian Kronquist
@iankronquist
Apr 18 2015 00:29
@tjhance thanks. Where can I find more docs about its architecture?
Travis Hance
@tjhance
Apr 18 2015 00:30
ah hm, we don’t have much unfortunately
oh
there are some blog posts
Ian Kronquist
@iankronquist
Apr 18 2015 00:33
Thanks! You should put together some architecture documents, I'd be really curious to know what differentiates you from PyPy.
andrewchambers
@andrewchambers
Apr 18 2015 00:41
One is implemented in rpython, one is in C++, one is a tracing jit, the other is a method jit, one is by dropbox, the other is run on donations
one uses llvm, the other uses a custom code gen
Chris Toshok
@toshok
Apr 18 2015 01:26
@undingen do you mean how many frames in a given unwind?
oh I need to revert the reuse of exception objects. for the top three exception raising sites (in c++) i was caching a single exception instance and reusing it :)
Travis Hance
@tjhance
Apr 18 2015 01:28
how to do you tell that it’s safe to re-use?
Chris Toshok
@toshok
Apr 18 2015 01:29
oh i don't
Travis Hance
@tjhance
Apr 18 2015 01:29
so… that’s why you need to revert it?
Chris Toshok
@toshok
Apr 18 2015 01:29
yeah :)
there was another rather low level breakage (list eq was returning NotImplemented for list == list_subclass) that was causing django’s lru_caches to miss 100% of the time
Travis Hance
@tjhance
Apr 18 2015 01:31
ouch
Chris Toshok
@toshok
Apr 18 2015 01:48
hm.. looks like commenting out the reuse costs us quite a bit though :( from ~70ms to ~400ms
oh, another thing I’d done wrt exceptions was never calling getTraceback()
Travis Hance
@tjhance
Apr 18 2015 02:30
just from the allocations?
Chris Toshok
@toshok
Apr 18 2015 02:31
And libunwind there
Marius Wachtler
@undingen
Apr 18 2015 14:50
@toshok sorry for being unclear: I meant about how many of these function EH frame tables are registered when the performance is so slow. (the ones which you are now looking up with using a binary search)
Chris Toshok
@toshok
Apr 18 2015 18:41
oh oh, let me check
it’s made complicated somewhat by the way libgcc lazily decodes/registers the ehframe info
anything that’s registered goes into an “unseen” list. those aren’t looked at unless there’s an IP that isn’t within the “seen” list
the code pops one at a time off the unseen list until the object is found that has the ip
Chris Toshok
@toshok
Apr 18 2015 18:57
after django startup and 100 requests:
there are 914 seen objects
 did 10 comparisons to find object
some are worse (27 comparisons for one here)
not sure how many of those objects are things we should have unregistered, unfortunately
i also think the linear lookup portion could be fixed. but the initial version from that bug report has definite problems
Marius Wachtler
@undingen
Apr 18 2015 20:05
thanks for taking the time to measure it. The numbers aren't as high as I feared. (Suspected that because of the RuntimeICs there may be much more)...
Chris Toshok
@toshok
Apr 18 2015 20:25
wow. but the linear search does much, much worse. that’s pretty interesting
for the 914 seen objects + 10 comparisons above, the linear search shows:
there are 913 seen objects
 did 913 linear comparisons
Marius Wachtler
@undingen
Apr 18 2015 20:47
should search in reverse order :-P