Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

GH-115802: JIT "small" code for Windows#115964

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
brandtbucher merged 18 commits intopython:mainfrombrandtbucher:justin-relax-b
Feb 29, 2024

Conversation

brandtbucher
Copy link
Member

@brandtbucherbrandtbucher commentedFeb 26, 2024
edited
Loading

For 32-bit Windows, the small code model works fine out-of-the-box.

For 64-bit Windows, we don't have position-independent code with GOT relocations like Linux and macOS. Instead, we compile the stencils like aPy_BUILD_CORE_MODULE binary extension module, which creates a level of indirection similar to a GOT (__impl_Py_XXX holds the address ofPy_XXX). We process this just like the GOT on other platforms, and everything just works.

This does require addingPyAPI_FUNC andPyAPI_DATA to some symbols in internal headers to get the correct visibility, which is why this PR touches so many files.

Looks like this makes the Windows JIT~3-4% faster.

stonebig and ssweber reacted with heart emojinetwork-shark reacted with rocket emoji
@brandtbucherbrandtbucher added performancePerformance or resource usage skip news interpreter-core(Objects, Python, Grammar, and Parser dirs) labelsFeb 26, 2024
@brandtbucherbrandtbucher self-assigned thisFeb 26, 2024
@bedevere-appbedevere-appbot mentioned this pull requestFeb 26, 2024
13 tasks
Copy link
Member

@gvanrossumgvanrossum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I'm sorry, I realized halfway through the review that this touches upon several large blank spaces in my brain. So this is not a very useful review. I do think that_PyOptimize_Optimize() belongs in an internal header though.

assert(oparg >= FVC_STR && oparg <= FVC_ASCII);
conv_fn =CONVERSION_FUNCTIONS[oparg];
conv_fn =_PyEval_ConversionFuncs[oparg];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

We could makeinst(CONVERT_VALUEreplicate(4) inst(CONVERT_VALUE and rely on clang removing the lookup.

Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Is there a way to do that where a fifth generic version isn't generated too? Otherwise, it doesn't help, so we might as well stay with this?

Copy link
Member

@markshannonmarkshannon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Looks good, I've a few comments.

As a general comment regarding JIT development:
Don't be afraid to make small changes tobytecodes.c and other interpreter files to enable the JIT to work more smoothly.

brandtbucher reacted with thumbs up emoji
PyAPI_DATA(const binaryfunc) _PyEval_BinaryOps[];
PyAPI_DATA(const conversion_func) _PyEval_ConversionFuncs[];

PyAPI_FUNC(int) _PyEval_CheckExceptStarTypeValid(PyThreadState *tstate, PyObject* right);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Rather than exposing all these symbols, could we put the function pointers in a struct, and pass that to the JIT as an argument?

Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

The issue isn't finding symbols when jitting the code (jit.c is linked into the main executable and can find everything just fine).

The purpose of addingPyAPI_FUNC(...) andPyAPI_DATA(...) to the declarations is so they are declared with__declspec(dllimport) when compiling the templates. This makes Clang emit indirect memory accesses on Windows (similar to position-independent code on other platforms).

@brandtbucherbrandtbucher merged commitf0df35e intopython:mainFeb 29, 2024
@bedevere-bot
Copy link

⚠️⚠️⚠️ Buildbot failure⚠️⚠️⚠️

Hi! The buildbotAMD64 FreeBSD14 3.x has failed when building commitf0df35e.

What do you need to do:

  1. Don't panic.
  2. Checkthe buildbot page in the devguide if you don't know what the buildbots are or how they work.
  3. Go to the page of the buildbot that failed (https://buildbot.python.org/all/#builders/1232/builds/1515) and take a look at the build logs.
  4. Check if the failure is related to this commit (f0df35e) or if it is a false positive.
  5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/all/#builders/1232/builds/1515

Summary of the results of the build (if available):

==

Click to see traceback logs
Traceback (most recent call last):  File"<frozen getpath>", line352, in<module>ValueError:embedded null byteWarning -- Uncaught thread exception: RuntimeErrorException in thread Thread-60 (task):RuntimeError:error evaluating pathTraceback (most recent call last):  File"/home/buildbot/buildarea/3.x.opsec-fbsd14/build/Lib/threading.py", line1086, in_bootstrap_innerself.run()~~~~~~~~^^  File"/home/buildbot/buildarea/3.x.opsec-fbsd14/build/Lib/threading.py", line1023, inrunself._target(*self._args,**self._kwargs)~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  File"/home/buildbot/buildarea/3.x.opsec-fbsd14/build/Lib/test/test_interpreters/test_stress.py", line29, intask    interp= interpreters.create()~~~~~~~~~~~~~~~~~~~^^  File"/home/buildbot/buildarea/3.x.opsec-fbsd14/build/Lib/test/support/interpreters/__init__.py", line76, increateid= _interpreters.create(isolated=True)~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^RuntimeError:interpreter creation failedk

woodruffw pushed a commit to woodruffw-forks/cpython that referenced this pull requestMar 4, 2024
adorilson pushed a commit to adorilson/cpython that referenced this pull requestMar 25, 2024
diegorusso pushed a commit to diegorusso/cpython that referenced this pull requestApr 17, 2024
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@gvanrossumgvanrossumgvanrossum left review comments

@markshannonmarkshannonmarkshannon left review comments

Assignees

@brandtbucherbrandtbucher

Labels
interpreter-core(Objects, Python, Grammar, and Parser dirs)performancePerformance or resource usageskip newstopic-JIT
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

4 participants
@brandtbucher@bedevere-bot@gvanrossum@markshannon

[8]ページ先頭

©2009-2025 Movatter.jp