➜
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2010-07-11 18:49 by serprex, last changed 2022-04-11 14:57 by admin. This issue is now closed.
| Files | ||||
|---|---|---|---|---|
| File name | Uploaded | Description | Edit | |
| duptoptwo.patch | serprex, 2010-07-11 18:49 | |||
| Messages (3) | |||
|---|---|---|---|
| msg110035 - (view) | Author: Demur Rumed (serprex) | Date: 2010-07-11 18:49 | |
DUP_TOPX(3) is never used, nor is ROT_FOUR. This patch removes the opcodes, replacing DUP_TOPX with DUP_TOP_TWO Oddly, at least with pybench, use of PREDICT(BINARY_SUBSCR) in DUP_TOP_TWO seems to show an always right PREDICT as slower than FAST_DISPATCH |
|||
| msg110082 - (view) | Author: Antoine Pitrou (pitrou) *  |
Date: 2010-07-12 11:33 | |
> Oddly, at least with pybench, use of PREDICT(BINARY_SUBSCR) in > DUP_TOP_TWO seems to show an always right PREDICT as slower than > FAST_DISPATCH The main point of computed gotos is to allow the CPU's branch predictor to predict opcode pairs by itself. So, yes, adding a manual PREDICT() might actually slow down the code (probably depending on the CPU model). By the way, when you modify the bytecode, you have to change the magic number in Python/import.c. |
|||
| msg115603 - (view) | Author: Antoine Pitrou (pitrou) * |
Date: 2010-09-04 18:44 | |
Modified patch committed in r84501. Thanks! |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:57:03 | admin | set | github: 53471 |
| 2010-09-04 18:44:18 | pitrou | set | status: open -> closed type: performance -> resource usage messages: + msg115603 resolution: fixed stage: resolved |
| 2010-07-12 11:33:16 | pitrou | set | nosy:
+ pitrou messages: + msg110082 |
| 2010-07-11 21:20:57 | serprex | set | versions: + Python 3.2 |
| 2010-07-11 18:49:39 | serprex | create | |