These are chat archives for dropbox/pyston

2nd
Apr 2015
Travis Hance
@tjhance
Apr 02 2015 05:50
how common is sys._getframe?
Kevin Modzelewski
@kmod
Apr 02 2015 06:59
I'm running into it a lot trying to get metaserver running
I think it's common as in lots of things directly or indirectly use it
but uncommon as in it doesn't get called too many times?
at least that's my hope
I think the logging module calls it for every call to log()
Travis Hance
@tjhance
Apr 02 2015 07:24
That's worrying
I mean I assume log gets called a lot
Marius Wachtler
@undingen
Apr 02 2015 17:30
Arghhhh.. I made the check which determines if a cached object can get used safer (=more strict) now we only use the cache for about 2/3 functions on the second run of the tests. And the 1/3 where the hash determines a difference are the ones we actually want to use the cache because those are the large ones where jitting takes a long time...
while have to make sure the llvm IR we generate is deterministic
Kevin Modzelewski
@kmod
Apr 02 2015 18:32
:(
is it easy to see what's different about it?
Marius Wachtler
@undingen
Apr 02 2015 18:54
I have the difference now mostly eliminated
part of them are our "#%p" temp node name, the other ones are line numbers which are not set and therefore create slightly different debug data and phi nodes which get created in nondeterministic order (std::unordered_map with InternedString as key)
but it seams like test/tests/django_setup.py is working now witch cache
1st run: 2.5sec (empty cache - generating cache data)
2nd run: 1.5sec
Marius Wachtler
@undingen
Apr 02 2015 18:59
now I must hope that the test wasn't faster than 1.5sec before I added the object cache changes :-P
Kevin Modzelewski
@kmod
Apr 02 2015 18:59
oh nice!
Marius Wachtler
@undingen
Apr 02 2015 19:03
Sadly the compiling still takes 750ms using that approach with cache (JITting aka cache file loading takes 100ms form the 750ms) the remaining time is spend in our analysis passes irgen and opt... and this approach still requires to run them.. :-(
Kevin Modzelewski
@kmod
Apr 02 2015 19:04
hmm, well one thing at a time :)
it seemed like at least for some cases the LLVM JIT time was the large majority
ex I think for sre_parse.py:_parse
Marius Wachtler
@undingen
Apr 02 2015 19:07
I did not know we are always creating the JIT with default codegen optimization options (eg. -02)
but setting it to -O0 does not work because -O0 does not handle regalloc=basic and the fast one runs out of registers :-P
Marius Wachtler
@undingen
Apr 02 2015 19:34
ok running the django test without my changes takes 2.25secs -> the 1.5secs are not to bad
Chris Toshok
@toshok
Apr 02 2015 22:12
hm, re: _PyTuple_Resize, it seems that the only way we can guarantee what cpython guarantees is that we always create a new tuple
although I suppose we play fast and loose with the same constraints in PyString_Resize
Kevin Modzelewski
@kmod
Apr 02 2015 22:20
hmm shouldn't it be mostly the same thing?
Chris Toshok
@toshok
Apr 02 2015 22:23
yeah, it’s essentially the same piece of code