Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Requesting details #7

Open
etki opened this issue Nov 13, 2020 · 3 comments
Open

Requesting details #7

etki opened this issue Nov 13, 2020 · 3 comments

Comments

@etki
Copy link

etki commented Nov 13, 2020

Hey, this is more of curiosity question rather something else.

Currently plan is a bit vague. May I ask for more details of what is meant by:

  • Improved performance for integers of less than one machine word.
  • Improved performance for binary operators.

And why those things are considered slow / what's wrong with them, since i have no clue of current state of things inside CPython:

  • Faster calls and returns, through better handling of frames.
  • Better object memory layout and reduced memory management overhead.

And what feature makes superior machine code superior? It would be totally OK just to explain why all those key points are currently slow if you don't want to write your concrete ideas about speeding them up.

@ghost
Copy link

ghost commented Nov 20, 2020

Improved performance for integers of less than one machine word.

Python3 uses 30 bits chunks to represent an int value in 64-bit build, or 15 bits chunks in 32-bit build. The utilization of machine word is almost halved.

If an int's value does not exceed the range of one machine word, it may be use native machine word to represent it.

There was a discussion about it:
https://mail.python.org/archives/list/python-ideas@python.org/thread/L6BMMETVQYFGDIG7VIFICDSYVUXQAS52/

https://discuss.python.org/t/hybrid-implementation-for-pylongobject-performance/2129

And a very primitive prototype patch:
https://github.com/animalize/cpython/pull/7/files

I gave up because I thought it make the code complex, but IMHO further attempts may be worthwhile.

I guess Mark's idea is let the interpreter support native integer (outside of int class), then it's more worth to try.

@stonebig
Copy link

hi another small question. Is the "Step1"(adaptive, specializing interpreter):

@hlovatt
Copy link

hlovatt commented Feb 6, 2022

Hi, Adding to the small questions list. Did the Stage 1 improvements make it into 3.10? Thanks, Howard.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants