These are chat archives for dropbox/pyston

1st
Apr 2015
Travis Hance
@tjhance
Apr 01 2015 05:38
I think we should statically allocate our builtin objects and types. It would mean one less global variable lookup everytime we access a builtin object from our C++ code, which could be a big win. It might be a win elsewhere as well, although I’m not sure how this would interact with the GC.
Chris Toshok
@toshok
Apr 01 2015 05:38
the GC can be taught to scan whatever we want - what do you mean "statically allocate"?
Travis Hance
@tjhance
Apr 01 2015 05:39
oh like
don’t allocate it with new
like right now we have a BoxedClass* int_cls defined somewhere, and then somewhere else we allocate some memory for the boxed class and set int_cls to point to that
but we could also just have the BoxedClass allocated as a global variable somewhere
Chris Toshok
@toshok
Apr 01 2015 05:40
ah I see. so we’d have BoxedClass int_cls instead, and use &int_cls for Box->cls
Travis Hance
@tjhance
Apr 01 2015 05:40
something like that
Chris Toshok
@toshok
Apr 01 2015 05:48
yeah, a reloc instead of 2 loads
Kevin Modzelewski
@kmod
Apr 01 2015 06:42
that'd be cool :)
and the C API promises that those objects are static, and so usable as compile time constants
which is one of the things we don't match yet
Chris Toshok
@toshok
Apr 01 2015 06:43
yeah that would allow us to remove some differences in our extension headers
Marius Wachtler
@undingen
Apr 01 2015 07:26
mmh tryCallattrConstant is causing troubles with the MCJIT cache... it embeds a pointer dirrectly to the called functions...
I need a mechanism to relocate it on load. Something like giving it a unique but reproducible name and then on the next startup when I load the object code I have to know what function is meant by that name to replace it with the actual address...
Marius Wachtler
@undingen
Apr 01 2015 09:35
I hacked in a temporary workaround... We really have to find a good solution for all the caching problems because i really want to see this getting in :-P.
I have created an example function which takes 123ms to jit, jiting the function next time by loading the generated obj file reduces the time to 2ms
Kevin Modzelewski
@kmod
Apr 01 2015 10:06
on the non-initial attempts
when we try to load from the cache
do we go through the full irgen?
bc then we might not have to have the loader be able to resolve the names we generate
if during irgen we build up the map of names->pointers
ex something like
void* foo = constantToEmbed();
std::string name = nameToCallIt();
embed(name);
addLoaderName(name, foo);
and in the two compilations we'd get the same name but two different pointers
(this might have been what you were suggesting, not sure)
also, is there some kind of hashing mechanism to determine which code to load?
we might be able to avoid doing this relocation for pointers that we would expect to stay the same run-to-run
such as the pointers we would embed via tryCallattrConstant, which point to functions in the runtime :P
Marius Wachtler
@undingen
Apr 01 2015 10:21
Yes currently we go through the full irgen. My currently workaround works like you outlined. But I would have liked to get rid of the irgen because it's still takes quite a lot of time and I think we could get rid of it. There a few things which would have to change: e.g. the CLFunction* gets currently created during the irgen
on the other hand it may best comeup with a cache which requires irgen as a first step
and as a next than dependency on irgen. (which may also remove a bunch of analysis pass work when we find a cached object)
Marius Wachtler
@undingen
Apr 01 2015 10:28
and I haven't yet implemented any caching or removing of unnecessary relocations. My current plan is to get as much working as possible in order to figure out what are problematic areas and than come up with 1-2 cleaner solutions which hopefully resolve all the issues.
and as a next than dependency on irgen.
this should be: and as a next step then remove the dependency on running irgen when loading a cached object