These are chat archives for dropbox/pyston

28th
Jan 2015
Kevin Modzelewski
@kmod
Jan 28 2015 00:03 UTC
Hmm I think you can do CC='clang' CXX='clang++' cmake -GNinja ~/pyston
when you first run cmake
Marius Wachtler
@undingen
Jan 28 2015 00:03 UTC
mmh will try tomorrow but sounds to easy... :-D
Kevin Modzelewski
@kmod
Jan 28 2015 00:04 UTC
(this is assuming you installed clang-3.5 globally)
or I guess 3.6 now
Marius Wachtler
@undingen
Jan 28 2015 00:05 UTC
yes I have the clang package installed just couldn't get cmake to use it
Chris Toshok
@toshok
Jan 28 2015 02:47 UTC
raytrace allocates something like 50mil BoxedFloats, so switching to something like PyValue would be pretty huge
escape analysis would likely also address that, since I’d wager most are local temporaries
Chris Toshok
@toshok
Jan 28 2015 02:53 UTC
oh fun clang:
pyston: Compiling src/gc/collector.release.o
make: *** [src/gc/collector.release.o] Error 1
Kevin Modzelewski
@kmod
Jan 28 2015 09:07 UTC
by PyValue do you mean something like nan-boxing so we don't have to heap-allocate floats?
I'm kind of wary of over-optimizing for raytrace.py, since I think it's especially float-heavy in what I think isn't a very representative way
Chris Toshok
@toshok
Jan 28 2015 16:37 UTC
agreed. the float interning was just an experiment to see how much effect reducing # of gc’s slightly had on aggregate time.
yeah, PyValue = nan/nun-boxing
Joris Vankerschaver
@jvkersch
Jan 28 2015 21:16 UTC
Hi guys, is there a recommended way to test the C api? I'm still working on pulling in unicodeobject.c, but I would like to write some unit test to make sure the fundamentals are OK before painting myself into a corner ;-)
Kevin Modzelewski
@kmod
Jan 28 2015 22:00 UTC
Sure, we have some test extension modules that do this kind of thing
in test/test_extension
You could create a new one of those, and then it will be accessible to python scripts in test/tests, so you can import it + run whatever code is in there
ex, test/tests/capi_slots.py imports and runs test/test_extension/slots_test.c
Joris Vankerschaver
@jvkersch
Jan 28 2015 22:02 UTC
That is really cool, thanks! (And sorry for not figuring out that the tests would be under, ehm, test/)
Kevin Modzelewski
@kmod
Jan 28 2015 22:03 UTC
np :)
how's the unicode stuff going?
Joris Vankerschaver
@jvkersch
Jan 28 2015 22:04 UTC
It's challenging ;-) I didn't have much time to work on this over the break, but I'm trying to get unicodeobject.c to run with minimal changes.
So far, that meant that I wrote a few wrappers for the low level stuff (_PyUnicode_New, _PyUnicode_Resize) and I'm trying to see how far I can get with that.
Right now, I've got PyUnicode_DecodeUTF8 more or less to work, and that's why I want to get a few unit tests in.
So, not much progress yet.
Kevin Modzelewski
@kmod
Jan 28 2015 22:08 UTC
cool, sounds like it's coming along :)
feel free to ask more questions as stuff comes up!
Joris Vankerschaver
@jvkersch
Jan 28 2015 22:09 UTC
I'll definitely do that --- gitter is pretty cool. I'll try to get something solid in a branch asap, even if it's just partial
Marius Wachtler
@undingen
Jan 28 2015 22:31 UTC
since the introduction of ENABLE_FRAME_INTROSPECTION we are no longer generating direct calls to things like g.funcs.unpackIntoArray, or runtime functions which we were able to type resolve e.g. intAddInt. Is this because the callee could throw an exception and we need additional info to print the full callstack or whats the reason for going the patchpoint way?
Kevin Modzelewski
@kmod
Jan 28 2015 22:34 UTC
yeah, we need the patchpoint in order to attach a stackmap for metadata about that stackframe
for stuff like tracebacks
I think it should end up getting lowered to the same assembly though?
because we don't ask for any extra nops
(at least, that was the intention)
It probably messes with our optimization passes since we haven't taught them about these kinds of callsites
so we won't be able to inline into them
Marius Wachtler
@undingen
Jan 28 2015 22:37 UTC
ah okay I see, I missed that the have no size and do not get rewritten...
I noticed it because I wanted to test if inlining the intAddInt would help and if we could replace chains with allocas instead of a GC allocations...
Kevin Modzelewski
@kmod
Jan 28 2015 22:39 UTC
yeah, that kind of stuff is tricky in the face of Python's frame introspection features :/
We might have to do things like rematerialize values on demand
or just reduce the amount of frame introspection that you are allowed to do :P
Marius Wachtler
@undingen
Jan 28 2015 22:45 UTC

are we allowed to replace temporary values with stack allocations and inlined math for a case like:

return 1.0 / (ij * (ij + 1) / 2 + i + 1)

when we speculate that that all types are ints and the results fit inside an int?

ore is there some way in python to inspect the temporary results?
Kevin Modzelewski
@kmod
Jan 28 2015 23:16 UTC
That should be safe
especially if we're operating on unboxed ints
We might have to have some way of saying that certain functions will never use frame introspection (ie mostly, will never throw an exception)
for the int stuff specifically, I think our goal should be to make sure we treat them as unboxed as much as we can
Marius Wachtler
@undingen
Jan 28 2015 23:27 UTC
:+1: