possible optimization: SHRINK_STACK(n)

[shrinkstack]

BPO

40974

Nosy

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state. Show more details GitHub fields: assignee = None closed_at = None created_at = <Date 2020-06-14.12:08:18.034> labels = [] title = 'possible optimization: SHRINK_STACK(n)' updated_at = <Date 2020-06-14.17:51:00.210> user = 'https://bugs.python.org/shrinkstack' bugs.python.org fields: activity = <Date 2020-06-14.17:51:00.210> actor = 'serhiy.storchaka' assignee = 'none' closed = False closed_date = None closer = None components = [] creation = <Date 2020-06-14.12:08:18.034> creator = 'shrink_stack' dependencies = [] files = [] hgrepos = [] issue_num = 40974 keywords = [] message_count = 3.0 messages = ['371501', '371511', '371512'] nosy_count = 5.0 nosy_names = ['rhettinger', 'Mark.Shannon', 'serhiy.storchaka', 'pablogsal', 'shrink_stack'] pr_nums = [] priority = 'normal' resolution = None stage = None status = 'open' superseder = None type = None url = 'https://bugs.python.org/issue40974' versions = []

[shrinkstack]

context managers and except blocks generates multiple POP_TOPS constantly and maybe other cases which might lead generation of multiple POP_TOPS. A SHRINK_STACK(n) opcode would make things better (improvement on pyc size, less opcodes = faster evaluation).

A possible patch:

(to peephole.c)
+
+ case POP_TOP:
+ h = i + 1;
+ while (h < codelen && _Py_OPCODE(codestr[h]) == POP_TOP) {
+ h++;
+ }
+ if (h > i + 1) {
+ codestr[i] = PACKOPARG(SHRINK_STACK, h - i);
+ fill_nops(codestr, i + 1, h);
+ nexti = h;
+ }
+ break;

(to ceval.c)

+ case TARGET(SHRINK_STACK): {
+ for (int i = 0; i < oparg; i++) {
+ PyObject *value = POP();
+ Py_DECREF(value);
+ }
+ FAST_DISPATCH();
+ }
+

and some other minor things for opcode.py and magic number

[pablogsal]

less opcodes = faster evaluation

Unfortunately, that is not always true as opcodes can have arbitrary complexity and there are very low-level effects that are relevant in the eval loop. Even if it is better, the improvement may not be worth burning another opcode, especially since the new opcode won't replace POP_TOP (so we need to deal with both).

Without evaluating the tradeoffs and how it plays into the current status quo I have some initial questions:

• What is the performance improvement of the patch that you propose? Could you run the pyperformance benchmark suite to have some numbers?

• How many opcodes less are we talking about? What is the size before and after the suggested change in the stdlib pyc files?

[serhiy-storchaka]

It increases the size of the eval loop. It can break optimizations which is performed by the C compiler only when the code size does not exceed some limits, and it can exceed the size of processor caches which can make execution less efficient. So there are possible negative effects. We should have evidence that this change actually improves performance.

[iritkatriel]

exceptions don't generate quite as many pops anymore now that we don't push and pop the whole exc_info.

Anyway, there was no followup from the OP re benchmarking the idea.