- 04 Sep, 2015 1 commit
-
-
Rudi Chen authored
We need to do this because the ICInvalidator pointers are stored inside Pyston heap objects.
-
- 02 Sep, 2015 10 commits
-
-
Rudi Chen authored
-
Kevin Modzelewski authored
Generate better module names to make the object cache more effective
-
Kevin Modzelewski authored
add tp_nextiter implementation for our iterators
-
Marius Wachtler authored
-
Marius Wachtler authored
-
Marius Wachtler authored
one of the problems were that depending on if all files were all ready parsed we JITed more or less functions, this changed the total number of jited functions which changed all the module names. This lead to the result that in order to have all entries inside the cache we needed at least 3runs if the pyc files were old. The whole name scheme should add some point get improved but for now it should be enough.
-
Kevin Modzelewski authored
Lower initial dict/set size from 64->8
-
Kevin Modzelewski authored
Support non-module-globals in the llvm tier
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
-
- 01 Sep, 2015 18 commits
-
-
Kevin Modzelewski authored
By switching to our DenseMap/Set fork with that allows parameterizing on this. This is the same number that CPython uses. We were previously using llvm's default of 64, which is pretty high -- probably fine for their use cases, but in Python programs with lots of sets/dicts we spend a lot of time doing malloc() for all those 1kB+ allocations. This also increases the time it takes to iterate over the dict/set, since there are more empty buckets that have to be read + skipped.
-
Kevin Modzelewski authored
The default is 64, which is quite a lot for our uses.
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
- add note + license - put in our namespace - change header guards - make it match our lint style - don't apply our formatting
-
Kevin Modzelewski authored
With no modificaions in this commit, so that we can track changes. Unmodified from llvm rev r230300.
-
Kevin Modzelewski authored
It does use the old parser, but it also forces the use of the llvm tier for everything which usually ends up being the more important part of the configuration.
-
Kevin Modzelewski authored
(motivated by namedtuple) This involves two main changes: - changing the calling convention to pass `globals` as an argument if needed (this only applies going into compiled code, it's already passed into the interpreter) - changing the llvm irgenerator to use the new globals object
-
Kevin Modzelewski authored
Notion of redundant visits to slowly move towards scanning everything
-
Kevin Modzelewski authored
Complex improment
-
Kevin Modzelewski authored
when calling a BoxedWrapperDescriptor don't create a BoxedWrapperObject
-
Rudi Chen authored
-
Rudi Chen authored
For marking collectors, the redudant visits no-op to avoid the performance hit.
-
Marius Wachtler authored
- use callattr directly instead of getattr+runtimeCall - compvar: teach it that None is never nonzero
-
Marius Wachtler authored
-
Marius Wachtler authored
BoxedWrapper optimizations
-
Marius Wachtler authored
In order to allow rewrites. I'm wondering if we can't enable this for more classes...
-
Marius Wachtler authored
Before we created a tuple just to pass 1 or 2 args and then immediately extracted them and destroyed the tuple again.
-
Kevin Modzelewski authored
Move closer towards exposing the public gc interface only in one file.
-
- 30 Aug, 2015 1 commit
-
-
Rudi Chen authored
-
- 29 Aug, 2015 10 commits
-
-
Boxiang Sun authored
-
Boxiang Sun authored
-
Boxiang Sun authored
-
Boxiang Sun authored
-
Kevin Modzelewski authored
Rewriter "aggressiveness" and backoff
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
We often have cases where the "attr" part of a callattr can be rewritten but the "call" part cannot. This change lets us be able to rewrite the getattr and then write out the call as a call just to runtimeCallInternal.
-
Kevin Modzelewski authored
Add a concept of rewriter "aggressiveness" that decreases over time. It starts off high and we will try to rewrite everything fully, but as we succeed too often (megamorphic) or fail to rewrite, we will decrease the aggressiveness and produce more generic rewrites. This means they are more likely to succeed both at the rewriting stage and at the execution stage.
-