Skip to content

Conversation

@kmod
Copy link
Collaborator

@kmod kmod commented Jun 2, 2015

              pyston django_migrate.py                  :    2.1s baseline: 2.2 (-0.5%)
              pyston virtualenv_bench.py                :    5.7s baseline: 5.7 (-0.1%)
              pyston django-template.py                 :   10.8s baseline: 11.1 (-2.4%)
              pyston interp2.py                         :    5.1s baseline: 5.2 (-3.2%)
              pyston raytrace.py                        :    6.3s baseline: 6.3 (-1.1%)
              pyston nbody.py                           :    8.6s baseline: 8.3 (+3.8%)
              pyston fannkuch.py                        :    7.3s baseline: 7.2 (+2.0%)
              pyston chaos.py                           :   18.9s baseline: 20.0 (-5.6%)
              pyston fasta.py                           :    5.3s baseline: 5.2 (+0.6%)
              pyston pidigits.py                        :    5.6s baseline: 5.6 (+0.3%)
              pyston richards.py                        :    2.4s baseline: 2.4 (+2.6%)
              pyston deltablue.py                       :    1.7s baseline: 1.8 (-6.7%)
              pyston (geomean-1a6f)                     :    5.4s baseline: 5.4 (-0.9%)

I wasn't able to reproduce the nbody regression on my local machine so I'm going to chalk it up to benchmark behavior.

@kmod kmod self-assigned this Jun 2, 2015
@kmod kmod force-pushed the tp_richcompare branch from 941cb7d to 328ef48 Compare June 3, 2015 08:13
The notable places that are changed are PyEq, PyLt, and
compare/compareInternal.

The old codepaths are still in there (though thankfully
now with reduced duplication with cpython), since for anything
that defines a Python-level __lt__, it's better to call that
with our rewriting support, rather than calling it through
slot_tp_richcompare.

The control flow is kind of messy, since I don't think we
know what the right long-term organization is for these kinds of
things.  But basically, it's:
- if we can't rewrite, just call the C slot
- if we can rewrite, and we think calling tp_richcompare is profitable
  (ie it's not slot_tp_richcompare), we call that and emit a call to
  it in the patchpoint
- otherwise, we try calling the python attribute

Actual conversion of our attributes to tp_richcompare in the next commit.
@kmod kmod force-pushed the tp_richcompare branch from 328ef48 to e24eab4 Compare June 3, 2015 08:31
kmod added 2 commits June 3, 2015 01:44
int, long, str, tuple, type

int and long are implemented using tp_compare in CPython,
which is the old-style comparison method.  I don't really understand
its semantics which rely on type coercion, and we don't have the
methods it needs, so just implement it as tp_richcompare for now.
I think this is still an overall compatibility improvement.

str_richcompare is very odd where we have to do some weird things
to convince the compiler to produce the best code it can.
@kmod kmod force-pushed the tp_richcompare branch from e24eab4 to f97bfec Compare June 3, 2015 08:45
kmod added a commit that referenced this pull request Jun 3, 2015
@kmod kmod merged commit b8cd6e6 into pyston:master Jun 3, 2015
@kmod kmod deleted the tp_richcompare branch June 16, 2015 04:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant