These are chat archives for dropbox/pyston

10th
Jul 2015
Kevin Modzelewski
@kmod
Jul 10 2015 00:28
oh man, I forgot that we used to have an llvm interpreter
we have a bunch of old code for handling that :P
Travis Hance
@tjhance
Jul 10 2015 00:28
this was before we had the ast interpretter?
Kevin Modzelewski
@kmod
Jul 10 2015 00:29
yeah
Travis Hance
@tjhance
Jul 10 2015 00:29
oh, right...
you considered having a bad llvm -> assembly generator as an alternative to the ast interpreter
Kevin Modzelewski
@kmod
Jul 10 2015 00:32
yeah that too
(and does weird things when we deopt)
I'm going back through and cleaning this up so that we can reenable deopt + speculation, and I'm not surprised it broke
given the amount of code that we still have that deals with interpreting llvm
Travis Hance
@tjhance
Jul 10 2015 06:32
Chris Toshok
@toshok
Jul 10 2015 17:11
Here's that per-bb compilation paper from ecoop I mentioned a while back (pycon maybe?) http://drops.dagstuhl.de/opus/volltexte/2015/5219/pdf/9.pdf
Looks like all the published work is about primitive types. She mentions shapes in her slides as a future direction.
Rudi Chen
@rudi-c
Jul 10 2015 17:45
I wrote a bunch of docs and development tips in #687
I mostly wrote about common issues that I myself ran into - if there's anything knowledge you think could save new contributors a lot of time, it would be nice to add them on top of my changes :)
Marius Wachtler
@undingen
Jul 10 2015 18:04
thanks for writing/updating the docs :-)
Travis Hance
@tjhance
Jul 10 2015 18:11
yeah this is awesome
Marius Wachtler
@undingen
Jul 10 2015 19:32
wow... I changed to baseline jit to directly emit patchpoints (instead of using runtime ICs) in order to reduce number of allocation, and EH tables and hopefully reduce unwind time by reducing the nesting... now the first results are available:
pyston pyxl_bench.py : 4.6s base_3: 3.6 (+26.6%)
etc... I hope there is some bug...
Kevin Modzelewski
@kmod
Jul 10 2015 19:40
heh :)
Chris Toshok
@toshok
Jul 10 2015 19:59
is there a way to get gcc to tell you whether a variable is held in a register or stack slot at a given IP
?
taking the address of it gives me a stack address, but I can’t seem to get anything to not give me a stack address
r
Marius Wachtler
@undingen
Jul 10 2015 20:08
maybe: info address <sym_name>
Chris Toshok
@toshok
Jul 10 2015 20:08
ah nice, just what I was hoping for
Symbol "arg1" is a complex DWARF expression:
     0: DW_OP_fbreg -72
Marius Wachtler
@undingen
Jul 10 2015 20:11
:-D
Marius Wachtler
@undingen
Jul 10 2015 20:28
nice slowdown: nbody.py: 30.2s base_3: 6.7 (+354.4%)
Chris Toshok
@toshok
Jul 10 2015 20:29
Ship it
That gcc stack problem was/is pretty insidious. I don't understand how it hasn't been biting us forever.
Kevin Modzelewski
@kmod
Jul 10 2015 20:40
I think it's specifically with the way that bindObjIntoArgs works
where it writes to the function parameter by reference
Chris Toshok
@toshok
Jul 10 2015 21:05
Yeah exactly
Marius Wachtler
@undingen
Jul 10 2015 21:28
cool I found the bug which made the baseline jit inline patchpoints slow.
With the current thresholds it only gives us a small improvement but with -I django_template improves from 6.5secs to 5.7secs.
Travis Hance
@tjhance
Jul 10 2015 21:29
what’s -l?
Interpretter only?
-I?
Marius Wachtler
@undingen
Jul 10 2015 21:29
it means force interpreter, but in fact it just disables the llvm tiers
Travis Hance
@tjhance
Jul 10 2015 21:30
so interpretter + baseline jit
Marius Wachtler
@undingen
Jul 10 2015 21:30
so it means interpreter + baseline jit
mmh gitter mixes up messages....
Marius Wachtler
@undingen
Jul 10 2015 22:26
I have never seen this SmallDenseMap before
Chris Toshok
@toshok
Jul 10 2015 22:27
yeah, same
@undingen hm, did your traceback fix go in?
Marius Wachtler
@undingen
Jul 10 2015 22:28
yes it's in: dropbox/pyston@bb4092a
but because your asking... I would probably prefer if it's not yet in :D.
Whats the problem?
Chris Toshok
@toshok
Jul 10 2015 22:30
heh, I didn’t run quick_check before opening #692 (oops), and now that I am, it has traceback differences
oh:
-  File "/mnt/toshok/pyston/test/tests/incremental_tb_bjit.py", line 22, in <module>
+  File "/mnt/toshok/pyston/./test/tests/incremental_tb_bjit.py", line 22, in <module>
toshok @toshok blows away expected caches
Marius Wachtler
@undingen
Jul 10 2015 22:37
concerning the rewriter allocs: I have a local change laying around which switches the RewriterVars to use a bumpptr alloc. I will submit it soon. just in case you plan todo the same.
Chris Toshok
@toshok
Jul 10 2015 22:38
awesome. I have no plans to, but that should help a lot
hm, we have some expected cache files checked in. do we actually need those in git?
sorry, not expected cache files, .expected files
Chris Toshok
@toshok
Jul 10 2015 22:58
was watching this talk www.youtube.com/watch?v=pK2E63mhRxI while working today, and happened to look over at it at 32:20, and I see @rntz in the foreground
Travis Hance
@tjhance
Jul 10 2015 23:13
I also have a local change like that, although I remember noting it didn’t help that much
Chris Toshok
@toshok
Jul 10 2015 23:14
It might be that there just aren't many rewritervars for a given rewriter
Travis Hance
@tjhance
Jul 10 2015 23:15
but I also probably didn’t know the right ways to do perf measurement at the time
my understanding has increased a lot over the past couple of weeks:P
Marius Wachtler
@undingen
Jul 10 2015 23:23
I retested my change: it also does'nt change anything. But could be because I'm using a llvm::SpecificBumpPtrAllocator and it looks like the implementation is not optimized for uniform sized elements...
Travis Hance
@tjhance
Jul 10 2015 23:24
oh, for mine I just added an array of RewriterVars to the Rewriter object
Chris Toshok
@toshok
Jul 10 2015 23:28
We should be able to conservatively estimate vars/uses/actions and preallocate everything (using Small* if we want stl container apis, so it's all inline) right?
Travis Hance
@tjhance
Jul 10 2015 23:29
yeah that sounds like a good idea
Chris Toshok
@toshok
Jul 10 2015 23:29
I'd love to stack allocate rewriters but I don't know if that would help
Marius Wachtler
@undingen
Jul 10 2015 23:29
yeah in the worst case we would fail to jit a block if it contains to much vars but we would just continue interpreting it
Travis Hance
@tjhance
Jul 10 2015 23:29
oh, we don’t?
oh yeah i guess we don't
yeah but they’d become fairly large when we add all the RewriterVars to it
uhh
is there a word for that? I almost said ‘inline’ but that doesn’t sound right
inplace?
colocated?
Chris Toshok
@toshok
Jul 10 2015 23:37
inplace sounds right for the llvm::Small* types