On Wed, Feb 3, 2010 at 6:51 AM, M.-A. Lemburg <m...@egenix.com> wrote: > You lost me there :-) > > I am not familiar with how U-S actually implements the compilation > step and was thinking of it working at the functions/methods level > and based on input/output parameter type information.
Yes, but it's more like for every attribute lookup we ask "what was the type of the object we did the lookup on?" So, we simply take a reference to obj->ob_type and stuff it in our feedback record, which is limited to just three pointers. Then when we generate code, we may emit a guard that compares obj->ob_type in the compiled lookup to the pointer we recorded. We also need to place a weak reference to the code object on the type so that when the type is mutated or deleted, we invalidate the code, since its assumptions are invalid. > Most Python functions and methods have unique names (when > combined with the module and class name), so these could > be used for the referencing and feedback writing. Right, so when building the .so to load, you would probably want to take all the feedback data and find these dotted names for the pointers in the feedback data. If you find any pointers that can't be reliably identified, you could drop it from the feedback and flag that site as polymorphic (ie don't optimize this site). Then you generate machine code from the feedback and stuff it in a .so, with special relocation information. When you load the .so into a fresh Python process with a different address space layout, you try to recover the pointers to the PyObjects mentioned in the relocation information and patch up the machine code with the new pointers, which is very similar to the job of a linker. If you can't find the name or things don't look right, you just drop that piece of native code. > The only cases where this doesn't work too well is dynamic > programming of the sort done in namedtuples: where you > dynamically create a class and then instantiate it. It might actually work if the namedtuple is instantiated at module scope before loading the .so. > Type information for basic types and their subclasses can > be had dynamically (there's also a basic type bitmap for > faster lookup) or in a less robust way by name. If I understand you correctly, you're thinking about looking the types up by name or bitmap in the machine code. I think it would be best to just do the lookup once at load time and patch the native code. >> It sounds like a huge amount of work, and we haven't approached it. >> On the other hand, it sounds like it might be rewarding. > > Indeed. Perhaps this could be further investigated in a SoC > project ?! Or maybe a thesis. I'm really walking out on a limb, and this idea is quite hypothetical. :) Reid _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
