> I think I was wrong, but now I understand. The inlining you want is > to get the nb_add body, not the opcode body. > Exactly. This would increase performace by quite a bit -- I will start experimentation with that stuff a.s.a.p.
> The example you've given brings up a correctness issue. It seems > you'd want to add checks that verify that the operands w and v are > both floats, and jump to BINARY_ADD if the guard fails. It would > require reshuffling the stack operations to defer the pop until after > the check, but it shouldn't be a problem. > That's usually the problem when you're doing something from the top of your head, especially when its already 9pm :) You're right, a simple way around this is either: TARGET(FLOAT_ADD): if (!(TOP()->ob_type == SECOND()->ob_type && TOP()->ob_type == &PyFloat_Type)) goto TARGET_BINARY_ADD_SKIP_DECODE; ...remains the same... Note: the skip_decode is necessary because otherwise it would advance the instruction pointer. Another, simple approach is to add another set of labels to denote inline cache misses, e.g.: TARGET(BINARY_ADD): w= POP(); v= TOP(); BINARY_ADD_CACHE_MISS: x= PyNumber_Add(v, w); ... TARGET(FLOAT_ADD): w= POP(); v= TOP(); if (v->ob_type != w->ob_type || v->ob_type != &PyFloat_Type) goto BINARY_ADD_CACHE_MISS; ... You could also call the PyNumber_Add function yourself instead of the goto, but I did not implement it this way... > I think you also record (via gdb) exactly the information that we > record. I now see three consumers of type feedback from the CPython > interpreter: you or any quickening approach, Cython, and Unladen > Swallow. It might be worth converging on a standard way to record > this information and serialize it so that it can be analyzed offline. > Indeed. Probably a bigger set of types of frequently used C extension modules would be useful as well. I am doing the simplest possible thing here: since the gdb pretty print already is pretty close to a Python data type definition, I just copied this and did a few search and replace commands to convert it to a valid Python data type. > Our feedback recording mechanism currently uses LLVM data structures, > but the point of quickening is to avoid that kind of dependency, so > we'd need to rewrite it before it would really be useful to you. > Ok. --stefan _______________________________________________ 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