[issue45152] Prepare for splitting LOAD_CONST into several opcodes

2021-09-15 Thread Irit Katriel
Change by Irit Katriel : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue45152] Prepare for splitting LOAD_CONST into several opcodes

2021-09-15 Thread Irit Katriel
Irit Katriel added the comment: New changeset 40d2ac92f9a28a486156dafdbb613016bb1f6b98 by Irit Katriel in branch 'main': bpo-45152: refactor the dis module to make handling of hasconst opcodes more generic (GH-28258)

[issue45152] Prepare for splitting LOAD_CONST into several opcodes

2021-09-14 Thread Mark Shannon
Mark Shannon added the comment: New changeset c2f1e953371c25f6c42b599ba3d8797effbb503e by Irit Katriel in branch 'main': bpo-45152: Add HAS_CONST macro and get_const_value() function and use… (#28262) https://github.com/python/cpython/commit/c2f1e953371c25f6c42b599ba3d8797effbb503e

[issue45152] Prepare for splitting LOAD_CONST into several opcodes

2021-09-10 Thread Brandt Bucher
Change by Brandt Bucher : -- nosy: +brandtbucher ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45152] Prepare for splitting LOAD_CONST into several opcodes

2021-09-10 Thread Guido van Rossum
Guido van Rossum added the comment: We're not (yet) trying to optimize the code being executed (we should perhaps add an issue about class creation to https://github.com/faster-cpython/ideas). I agree that marshal is very fast already; I doubt the extra cost of wordcode would pay off since

[issue45152] Prepare for splitting LOAD_CONST into several opcodes

2021-09-10 Thread Irit Katriel
Irit Katriel added the comment: > (b) the allocation and initialization of a large number of objects Yes, when I profiled import GC showed up as 20-30%. -- ___ Python tracker

[issue45152] Prepare for splitting LOAD_CONST into several opcodes

2021-09-10 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: >From my experience, the largest cost in importing module (after I/O) is for >creating classes, especially classes with complex creation code: enums and >dataclasses (and namedtuples in past, but they were significanly optimized >since). For I/O, would

[issue45152] Prepare for splitting LOAD_CONST into several opcodes

2021-09-09 Thread Guido van Rossum
Guido van Rossum added the comment: Raymond, I am super grateful that you are showing us the assembly language. That's the kind of thing we need to do more of if we want to be successful. (In this case I'm not surprised by the outcome, but I have never studied x86 assembly and this was a

[issue45152] Prepare for splitting LOAD_CONST into several opcodes

2021-09-09 Thread Raymond Hettinger
Raymond Hettinger added the comment: Idea for improving unmarshalling speed: Since reading PYCs is I/O bound, it may be worthwhile to compress them. When the idea came up previously, Antoine suggested choosing an algorithm with the fastest possible decompression speed (iirc, it was lzma4

[issue45152] Prepare for splitting LOAD_CONST into several opcodes

2021-09-09 Thread Irit Katriel
Irit Katriel added the comment: I’m not sure we’re hoping this to be faster, just reduce the code object size and not be slower. (Smaller code object could be faster to unmarshal). -- ___ Python tracker

[issue45152] Prepare for splitting LOAD_CONST into several opcodes

2021-09-09 Thread Raymond Hettinger
Raymond Hettinger added the comment: Thanks for the link. This is a worthwhile experiment. However, the potential gains will be hard to come by. The workload of LOAD_CONST is very small. After paying for the usual dispatch logic overhead, all it does is an index into a struct member and

[issue45152] Prepare for splitting LOAD_CONST into several opcodes

2021-09-09 Thread Irit Katriel
Irit Katriel added the comment: It's related to this work: https://github.com/faster-cpython/ideas/issues/65 -- ___ Python tracker ___

[issue45152] Prepare for splitting LOAD_CONST into several opcodes

2021-09-09 Thread Raymond Hettinger
Raymond Hettinger added the comment: I didn't know this was in the works. Can you point me to the relevant discussion about why LOAD_CONST would be split? -- nosy: +rhettinger ___ Python tracker

[issue45152] Prepare for splitting LOAD_CONST into several opcodes

2021-09-09 Thread Irit Katriel
Change by Irit Katriel : -- pull_requests: +26682 pull_request: https://github.com/python/cpython/pull/28262 ___ Python tracker ___

[issue45152] Prepare for splitting LOAD_CONST into several opcodes

2021-09-09 Thread Irit Katriel
Change by Irit Katriel : -- keywords: +patch pull_requests: +26678 stage: -> patch review pull_request: https://github.com/python/cpython/pull/28258 ___ Python tracker ___

[issue45152] Prepare for splitting LOAD_CONST into several opcodes

2021-09-09 Thread Irit Katriel
Change by Irit Katriel : -- nosy: +gvanrossum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45152] Prepare for splitting LOAD_CONST into several opcodes

2021-09-09 Thread Irit Katriel
New submission from Irit Katriel : This issue is to prepare the code for splitting LOAD_CONST to several opcodes. There are a number of places in the code where an opcode is compared to LOAD_CONST (such as dis, the compiler, and the peephole optimizer). These need to be refactored to make