>>>>> "SP" == Samuele Pedroni <pedroni@inf.ethz.ch> writes:
SP> Python is even less rigid than Self and there is not an explicit
SP> notion of the set of slots that goes with an object. So to
I agree that this is the key hurdle.
SP> achieve some improvement in slot access speed may be necessary
SP> to:
SP> - set more rigid rules on slots (but then that's not Python
SP> anymore)
Not allowed :-).
SP> - find a way to detect some conservative approximation of the
SP> set of slots of a concrete class
I think this can be done with better compiler support.
SP> - use customization (consumes memory) so you can exploit a fixed
SP> layout for the approximated slots
SP> - use plain dictionary lookup for the slots missed that way
Right.
SP> Not impossible, not trivial and surely a thing that will pollute
SP> code clarity, OTOH whith this kind of optimizations in place,
SP> even just at the interp level, effective native compilation is
SP> not that far ...
It is a lot of work for instances, so I've been considering it
separately from the module globals issue. But I think it is
possible. Short of native-code, I wonder if we can extend the Python
VM with opcodes that take advantage of slots. I'm not sure how
closely this idea is related to Pysco.
Imagine we didn't special case ints in BINARY_ADD. If you're doing
mostly string addition, it's just slowing you down anyway :-).
Instead, a function that expected to see ints would check the types of
the relevant args.
def f(x):
return 2*x
would become something like:
def f(x):
if isinstance(x, int):
return 2 * x_as_int
else:
return 2 * x
where the int branch could use opcodes that knew that x was an integer
and could call its __add__ method directly.
Jeremy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4