An error occurred fetching the project authors.
- 19 Feb, 2015 1 commit
-
-
Chris Toshok authored
-
- 18 Feb, 2015 2 commits
-
-
Marius Wachtler authored
-15% for fasta.py
-
Kevin Modzelewski authored
-
- 13 Feb, 2015 3 commits
-
-
Kevin Modzelewski authored
Previously it was: tier 0: ast interpreter tier 1: llvm, no speculations, no llvm opts tier 2: llvm, w/ speculations, no llvm opts tier 3: llvm, w/ speculations, w/ llvm opts tier 2 seemed pretty useless, and very little would stay in it. Also, OSR would always skip from tier 1 to tier 3. Separately, add configurable OSR/reopt thresholds. This is mostly for the sake of tests, where we can set lower limits and force OSR/reopts to happen.
-
Chris Toshok authored
-
Chris Toshok authored
-
- 12 Feb, 2015 4 commits
-
-
Kevin Modzelewski authored
We were having problems with spawning subprocesses from threads, since the children would inherit the "wait for another thread to acquire the gil" flag, but would not inherit the thread that would actually try to acquire the gil; this would make the child hang.
-
Kevin Modzelewski authored
And fix a bunch of places that they weren't.
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
Before, we tried to do it based on whether the rewrite we were adding was "compatible" with whatever was already in there. But we weren't really doing this and there were a lot of limitations with this method anyway.
-
- 11 Feb, 2015 1 commit
-
-
Kevin Modzelewski authored
We weren't scanning it as part of the gc handler, so eventually it would get collected and then __name__ would break. (un)fortunately, in the cases that would use it, it looks like it would always get replaced by another string (the only thing being allocated out of that size bin?), so it would look like the __name__ was just wrong. Anyway, this should fix interp2.py
-
- 10 Feb, 2015 1 commit
-
-
Kevin Modzelewski authored
Also, improve rewriting to still be able to rewrite object construction. For now, be able to rewrite the case that a function takes kwargs but the kwargs is empty. Also, add an even faster path to typeCallInternal. This is partially obviated by the improved rewriting, but we might as well keep it.
-
- 07 Feb, 2015 3 commits
-
-
Travis Hance authored
-
Kevin Modzelewski authored
-
Travis Hance authored
-
- 06 Feb, 2015 3 commits
-
-
Kevin Modzelewski authored
Previously we were just passing around a vector<> of LineInfos; now, they get encapsulated in a BoxedTraceback object. This has a couple benefits: 1) they can participate in the existing sys.exc_info passing+handling 2) we can enable a basic form of the traceback module. 2 means that we can finally test our tracebacks support, since I was constantly fixing one issue only to break it in another place. 1 means that we now generate the right traceback for the current exception! Before this change, the traceback we would generate was determined using a different system than the exc_info-based exception raising, so sometimes they would diverge and be horribly confusing. There's a pretty big limitation with the current implementation: our tracebacks don't span the right stack frames. In CPython, a traceback spans the stack frames between the raise and the catch, but in Pyston the traceback includes all stack frames. It's not easy to provide this behavior, since the tracebacks are supposed to get updated as they get rethrown through each stack frame. We could do some complicated stuff in irgen to make sure this happens. I think the better but more complicated approach is for us to create the custom exception unwinder we've been wanting. This would let us add custom traceback-handling support as we unwound the stack. Another limitation is that tracebacks are supposed to automatically include a reference to the entire frame stack (tb.tb_frame.f_back.f_back.f_back....). In Pyston, we're not automatically generating those frame objects, so we would either need to do that and take a perf hit, or (more likely?) generate the frame objects on-demand when they're needed. It's not really clear that they're actually needed for traceback objects, so I implemented a different traceback object API and changed the traceback.py library, under the assumption that almost-noone actually deals with the traceback object internals.
-
Travis Hance authored
-
Kevin Modzelewski authored
Trying to patch up our file support so that we match CPython's behavior and functionality more closely; this is the first step.
-
- 05 Feb, 2015 3 commits
-
-
Travis Hance authored
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
The 'internal callable' (bad name, sorry) is what defines how the arguments get mapped to the parameters, and potentially also does rewriting. By providing a custom internal callable, we can make use of special knowledge about how C API functions work. In particular, we can skip the allocation of the args + kwargs objects when we are calling an object with the METH_O signature. This patch includes rewriting support, though we don't currently allow rewriting CAPI functions as part of callattrs.
-
- 04 Feb, 2015 1 commit
-
-
Kevin Modzelewski authored
Most importantly, intern all the strings we put into the AST* nodes. (the AST_Module* owns them) This should save us some memory, but it also improves performance pretty substantially since now we can do string comparisons very cheaply. Performance of the interpreter tier is up by something like 30%, and JIT-compilation times are down as well (though not by as much as I was hoping). The overall effect on perf is more muted since we tier out of the interpreter pretty quickly; to see more benefit, we'll have to retune the OSR/reopt thresholds. For better or worse (mostly better IMO), the interned-ness is encoded in the type system, and things will not automatically convert between an InternedString and a std::string. It means that this diff is quite large, but it also makes it a lot more clear where we are making our string copies or have other room for optimization.
-
- 02 Feb, 2015 2 commits
-
-
Kevin Modzelewski authored
The goal is to not continually call functions that deopt every time, since the deopt is expensive. Right now the threshold is simple: if a function deopts 4 (configurable) times, then mark that function version as invalid and force a recompilation on the next call.
-
Kevin Modzelewski authored
Old deopt worked by compiling two copies of every BB, one with speculations and one without, and stitching the two together. This has a number of issues: - doubles the amount of code LLVM has to jit - can't ever get back on the optimized path - doesn't support 'deopt if branch taken' - horrifically complex - doesn't support deopt from within try blocks We actually ran into that last issue (see test from previous commit). So rather than wade in and try to fix old-deopt, just start switching to new-deopt. (new) deopt works by using the frame introspection features, gathering up all the locals, and passing them to the interpreter.
-
- 29 Jan, 2015 1 commit
-
-
Kevin Modzelewski authored
-
- 27 Jan, 2015 1 commit
-
-
Marius Wachtler authored
Reduces slowpath_typecall from 40000 to 30 for spectral_norm
-
- 24 Jan, 2015 1 commit
-
-
Kevin Modzelewski authored
ie names that begin with two underscores but don't end in two underscores have the classname added to them. Do this early on in the pipeline so that all the analyses operate post-mangling. The implementation is kind of hacky and I couldn't think of a good way to make it super systematic; there may be more cases I missed.
-
- 22 Jan, 2015 7 commits
-
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
Doesn't support continue/break/return yet
-
- 21 Jan, 2015 1 commit
-
-
Kevin Modzelewski authored
ExcInfo is a triple of exc_type, exc_value, exc_traceback - analogous to Python's sys.exc_info(). Previously, we were just throwing exc_value. I still don't understand all the rules for when type(exc_value) is not necessarily exc_type. But this also makes it easier to pass exc_traceback around, and should make it possible to make our handling more consistent. This commit just changes the runtime; the generated code currently still expects a Box* to be thrown and will crash.
-
- 11 Jan, 2015 2 commits
-
-
Kevin Modzelewski authored
Sometimes you want the wrapping behavior or not -- the builtin iter() function was calling getiter, but shouldn't be doing this wrapping.
-
Kevin Modzelewski authored
At runtime, we can detect if something supports the new Pyston iteration protocol (__hasnext__) or not. Statically, when we lower a for loop, we assume that the iterator supports the new protocol, and we can't check it This commit adds a check to getiter() which wraps a Python-style iterator with an IterWrapper which adds the __hasnext__ method.
-
- 10 Jan, 2015 3 commits
-
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
I think there are a couple ways we can go about this. It looks like extensions just specify tp_dictoffset if they want their instances to have instance attributes, but don't usually actually look at the dict or really make use of the fact that it's a real dict. So possibly, we have the ability to stuff a non-dict into the slot they reserved for us. Seems risky though. Instead, the approach in this commit is to create an actual dict and put it in like they expect. All the attribute-accessing paths have been updated to look at both the fast Pyston HCAttrs method, and the CAPI dict method.
-