Demur Rumed <junkm...@hotmail.com> added the comment: The seperation of COMPARE_OP into multiple opcodes shouldn't affect cache size since the opcodes are aliased. Spreading out the switch statement shouldn't cause issue from flattening, since GCC would inline the single use of cmp_outcome. Thus the only bloat is the wrapper overhead, which I believe the C code is relatively large with respect to the macros. As for DUP_TOP_TWO, that's smaller than DUP_TOPX
It may be suitable to benchmark on other systems besides my own due to the subversive nature of caches; I've seen improvement in any code that uses comparisons. To consider, however, is that ceval.o dropped from 268592B to 267448B. This is reflected in that the interpreter's executable dropped from 6721842B to 6719866B Raymond, what do you mean with respect to the peepholer? I believe my changes there have shown it to be a simplification of the code ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9155> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
