Hmm I think you can do
CC='clang' CXX='clang++' cmake -GNinja ~/pyston
when you first run cmake
mmh will try tomorrow but sounds to easy... :-D
(this is assuming you installed clang-3.5 globally)
or I guess 3.6 now
yes I have the clang package installed just couldn't get cmake to use it
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
oh fun clang:
pyston: Compiling src/gc/collector.release.o
make: *** [src/gc/collector.release.o] Error 1
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
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
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 ;-)
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
That is really cool, thanks! (And sorry for not figuring out that the tests would be under, ehm, test/)
np :)
how's the unicode stuff going?
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.
cool, sounds like it's coming along :)
feel free to ask more questions as stuff comes up!
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
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?
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
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...
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
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?
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
:+1: