These are chat archives for dropbox/pyston

1st
Dec 2015
Kevin Modzelewski
@kmod
Dec 01 2015 05:02
yeah, we usually just check if optimizations broke by looking at the overall perf impact of a change
and the other option is to create a stat and then have the tester make sure that the stat was sufficiently low/high after your test
@Daetalus refcounting is coming along
I have a decent part of the runtime+interpreter+baseline jit all working with reference counting
now I need to add it to the tracing jit stuff
and then hopefully we can get some early performance numbers
Sun
@Daetalus
Dec 01 2015 05:04
This message was deleted
Kevin Modzelewski
@kmod
Dec 01 2015 05:04
I think it will still be a fair amount of work to get it checked in
Sun
@Daetalus
Dec 01 2015 05:04
:smile:
Kevin Modzelewski
@kmod
Dec 01 2015 05:05
@gnprice I think yeah ValuedCompilerVariable is the only subclass of CompilerVariable
I forget exactly why it is set up that way -- there might have been another class in the past, or maybe it's so that we can treat all the different template instantiations of ValuedCompilerVariable as a single base type
Marius Wachtler
@undingen
Dec 01 2015 11:11
yeah I finally found what's breaking our inliner pass (the problem does not currently show up because of all the patchpoints we generate...)
The problem is that in our stdlib.bc are two different definitions of class.pyston::BoxedClass and class.pyston::Box. The only difference is that one replaces all %"class.pyston::Box"* (%"class.pyston::Box"*)* with {}* the inliner than complains that we ware passing the wrong types...

And I found now what is causing the type change: it's

// force instantiation:
template Box* listiterNext<CAPI>(Box*) noexcept;
template Box* listiterNext<CXX>(Box*);

inside runtime/inline/list.cpp. Moving the to the not inline file resolves the problem...

Sun
@Daetalus
Dec 01 2015 14:06
I commented some code in NumPy, then get this result of NumPy tests(some of them disabled due to our numpy patch).
Ran 2253 tests in 62.619s  FAILED (KNOWNFAIL=2, SKIP=6, errors=348, failures=59)
However, CPython run more tests but take shorter time:
Ran 4955 tests in 32.632s

OK (KNOWNFAIL=5, SKIP=6)
I will focus on solve existed problems first. Make the tests could pass. Not deal with performance right now.
Sun
@Daetalus
Dec 01 2015 14:11
Just let you know the NumPy may slow in Pyston.
PyPy seems want to use their C API to support NumPy. Not sure how they handle NumPyPy. They want to drop the NumPy compatibility( which I think is a bad idea), and provide fast array iteration(good idea!).
Marius Wachtler
@undingen
Dec 01 2015 15:22
All this errors could also cause slowdown because of the additional exceptions / frame introspection etc...
So I don't think we can take a perf conclusions from this
Marius Wachtler
@undingen
Dec 01 2015 15:28
But than I would not be surprised if it's 2x as slow currently because no one took yet a look at the perf... :-D
[PATCH] D15124: Use @llvm.invariant.start/end intrinsics to extend the meaning of basic AA's pointsToConstantMemory(), for GVN-based load elimination purposes
I think this could be useful for us in the future to mark some stuff as const... (e.g. ->cls field....)