Don't generate guards when all arguments have fixed known types #981

undingen · 2015-10-23T11:32:15Z

Don't generate argument guards for callattr & runtimeCalls if we know that the classes can't change.
My first approach kept track of every individual arg and tracked if it needed a guard but this had a too large overhead - I could not archive a speedup. This approach now only supports the case where all args have fixed classes.

                                   upstream/master:  origin/guards_know:
           django_template3.py             2.2s (2)             2.2s (2)  +1.3%
                 pyxl_bench.py             1.8s (2)             1.8s (2)  -0.2%
     sqlalchemy_imperative2.py             2.3s (2)             2.3s (2)  +0.6%
                pyxl_bench2.py             1.3s (2)             1.3s (2)  -2.5%
       django_template3_10x.py            14.1s (2)            14.3s (2)  +1.6%
             pyxl_bench_10x.py            13.6s (2)            13.4s (2)  -1.6%
 sqlalchemy_imperative2_10x.py            17.8s (2)            17.6s (2)  -1.3%
            pyxl_bench2_10x.py            11.7s (2)            11.1s (2)  -5.6%
                       geomean                 5.1s                 5.1s  -1.0%

undingen · 2015-10-27T19:36:02Z

I fear that this commit is introducing random test failures :-(
I have been seeing lately already some but I think this commit is increasing the number of it. (There is this thread id assert we already know since a long time but there is now also a newer on inside the GC handler of generators)

undingen · 2016-01-25T13:58:49Z

So I restarted the travis ci several and could not see a problem with this patch but the perf improvement is now much smaller:

                                  upstream/master:  origin/guards_know:
           django_template3.py             2.1s (4)             2.1s (4)  +0.5%
                 pyxl_bench.py             1.8s (4)             1.8s (4)  +0.9%
     sqlalchemy_imperative2.py             2.2s (4)             2.2s (4)  +1.0%
                pyxl_bench2.py             1.1s (4)             1.0s (4)  -0.9%
       django_template3_10x.py            13.8s (4)            14.1s (4)  +1.9%
             pyxl_bench_10x.py            13.4s (4)            13.0s (4)  -3.2%
 sqlalchemy_imperative2_10x.py            16.9s (4)            16.8s (4)  -0.5%
            pyxl_bench2_10x.py             9.1s (4)             8.9s (4)  -1.8%
                       geomean                 4.7s                 4.7s  -0.3%

I think this adds some pretty heavy debugging that we might not always want, but turning this on is always my first debugging step.

I don't quite remember this but I think the goal was to ignore core/from_llvm, not all of core/

Ref nexedi fixing

Or rather, add some more refcount-related calls to it to help it get down to zero refs at the end.

Our underlying implementation still looks pretty different, but rather than implement some newly-needed APIs completely from scratch, I copied in some of CPython's implementation. The result is a bit messy (multiple ways of doing similar things), but I think it's a step in the right direction. Regardless, this commit adds "clean up thread-local storage when the local object dies" functionality, as well as better cleanup when there are multiple threads. I think this should help with the fork issues as well.

I wasn't sure what we would have to do in this case -- we don't really have any way of cleaning up the data referenced by those other threads. Fortunately(?), CPython doesn't do much cleanup of those threads (cleans up their metadata but doesn't try to clean up any references held by the thread), so we don't have to do much either. Just set a flag saying that this happened and that we should skip asserting that we got down to 0 refs.

that is just based off of pulling our latest release

PyObject_New: register the type if the type is not yet registered

The problem is that we emit an llvm "unreachable" instruction, and then continue to emit other code, which fails the verifier. endBlock(DEAD) is supposed to be the right way to handle that, but there is some more work that would need to be done there to get that working properly. So just do the easy thing for now -- create a new BB so that it's ok to emit more code.

We were doing a "call bumpUse() early" optimization to free up registers when we can, but as a side-effect it looked to the refcounter like the reference was done being used.

Not using it in this commit, just wanted to get the unmodified version in so it's easier to see the changes.

…ypes via their descrobject.c

This is for adding a guard on a non-immortal object, since we need to be safe against that object getting deallocated and a different object is allocated in its spot. We had support for this already, but it leaked memory. The biggest was that we never freed our runtimeICs, so if those ended up getting any GC references in them, then we would leak memory. So I started freeing those, but then that exposed the issue that the ICInvalidators expect that their dependent ICs never get freed. So I added back a mapping from ICSlotInfo-> ICInvalidators that reference them.

Create a simple Dockerfile

until I realize that it's because we were passing more tests than we expected.

The behavior changed in CPython 2.7.4, and Travis-CI runs 2.7.3.

Switch to CPython's descrobject.c

before we added a it as a module which made code fail which does something like __builtins__["unicode"]

Some packaging / distributing updates

Bump version numbers

update list of failing cpython tests

exec, input: if globals has no __builtins__ add it as a dictwrapper

…lasses can't change

undingen added the wip label Oct 23, 2015

undingen force-pushed the guards_known_cls branch 3 times, most recently from 9c8f88f to 329d617 Compare October 27, 2015 14:03

undingen removed the wip label Oct 27, 2015

undingen force-pushed the guards_known_cls branch 2 times, most recently from 457f6ec to d88a295 Compare November 2, 2015 20:12

undingen force-pushed the guards_known_cls branch from 2f274c0 to c861dbf Compare November 11, 2015 02:02

undingen force-pushed the guards_known_cls branch from c861dbf to 7d2eb0c Compare December 8, 2015 15:47

undingen force-pushed the guards_known_cls branch from 7d2eb0c to 95dd9b8 Compare January 15, 2016 13:15

undingen force-pushed the guards_known_cls branch from 95dd9b8 to e14338c Compare January 25, 2016 10:48

undingen added the pending review label Feb 3, 2016

undingen force-pushed the guards_known_cls branch from e14338c to d8e5265 Compare February 4, 2016 10:10

undingen force-pushed the guards_known_cls branch from d8e5265 to 2b40b60 Compare February 13, 2016 14:05

kmod and others added 14 commits April 13, 2016 21:19

Get basic_test.c working

ec120d0

Get builtin_type_not_subclassable.py working

369121e

Copy in CPython's code for changing __class__

3f9490a

Turn on Py_TRACE_REFS in debug builds

b701479

I think this adds some pretty heavy debugging that we might not always want, but turning this on is always my first debugging step.

Format src/core/ again

7bf5943

I don't quite remember this but I think the goal was to ignore core/from_llvm, not all of core/

decref val when attribute is not writable

d29e352

Merge pull request pyston#1134 from Daetalus/ref_nexedi_fixing

72f351d

Ref nexedi fixing

Get cPickle working

1a223d5

Or rather, add some more refcount-related calls to it to help it get down to zero refs at the end.

Print a full stacktrace in _printStacktrace

d4831ad

A few misc test updates / fixes

e6b7d6c

Add our annotations to _multiprocessing

c4a4b01

member_descriptor_ics.py

c4804fe

kmod and others added 25 commits May 25, 2016 00:42

Create a simple Dockerfile

bf20355

that is just based off of pulling our latest release

Merge pull request pyston#1207 from undingen/register_types

61ac7b5

PyObject_New: register the type if the type is not yet registered

Fix a rewriter bug

a994ec0

We were doing a "call bumpUse() early" optimization to free up registers when we can, but as a side-effect it looked to the refcounter like the reference was done being used.

Copy in CPython's descrobject.c

8e8c9a8

Not using it in this commit, just wanted to get the unmodified version in so it's easier to see the changes.

Switch to using CPython's getset, member, wrapperdescr, and wrapper t…

4c3c693

…ypes via their descrobject.c

Reenable our tpp_call rewriting for these types

75d0050

Use CPython's PyMethodDescr_Type

0751c27

Reenable rewriting for method-descriptors

7f84725

Merge pull request pyston#1211 from kmod/docker2

c9cab0e

Create a simple Dockerfile

Get rid of the numpy patch

04f4515

cffi failures scare me

6dd62f7

until I realize that it's because we were passing more tests than we expected.

Manually specify the output of methoddescr.py

a11ffa7

The behavior changed in CPython 2.7.4, and Travis-CI runs 2.7.3.

Merge pull request pyston#1209 from kmod/cpython_descr2

7974eb8

Switch to CPython's descrobject.c

Some packaging / distributing updates

499c4c0

exec, input: if globals has no __builtins__ add it as a dictwrapper

f4f3d39

before we added a it as a module which made code fail which does something like __builtins__["unicode"]

Add a pyston/pyston-numpy docker image as well

865f7ba

Merge pull request pyston#1212 from kmod/packaging

f788cfa

Some packaging / distributing updates

update list of failing cpython tests

c4384c6

Bump version numbers

970ed60

Merge pull request pyston#1226 from kmod/packaging

c6d8021

Bump version numbers

Merge pull request pyston#1223 from undingen/cpython_tests2

08d75e5

update list of failing cpython tests

Merge pull request pyston#1221 from undingen/exec_builtins

e37660e

exec, input: if globals has no __builtins__ add it as a dictwrapper

callattr runtimeCall: don't generate arg guards if we know that the c…

93a65a7

…lasses can't change

undingen force-pushed the guards_known_cls branch from 2b40b60 to 93a65a7 Compare May 30, 2016 19:19

undingen added wip and removed pending review labels Jun 13, 2016

kmod force-pushed the master branch 2 times, most recently from 352fd89 to 6488a3e Compare October 28, 2020 21:01

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Don't generate guards when all arguments have fixed known types #981

Don't generate guards when all arguments have fixed known types #981

undingen commented Oct 23, 2015

undingen commented Oct 27, 2015

undingen commented Jan 25, 2016

Don't generate guards when all arguments have fixed known types #981

Are you sure you want to change the base?

Don't generate guards when all arguments have fixed known types #981

Conversation

undingen commented Oct 23, 2015

undingen commented Oct 27, 2015

undingen commented Jan 25, 2016