FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

GH-113464: Speed up JIT builds by brandtbucher · Pull Request #122839 · python/cpython · GitHub

/ cpython Public

GH-113464: Speed up JIT builds - #122839

Merged
brandtbucher merged 2 commits into
python:mainfrom
brandtbucher:faster-jit-builds
Aug 14, 2024
Merged

GH-113464: Speed up JIT builds#122839
brandtbucher merged 2 commits into
python:mainfrom
brandtbucher:faster-jit-builds

Conversation

brandtbucher commented Aug 8, 2024
edited by bedevere-app Bot
Loading

Copy link
Copy Markdown
Member

The current JIT build includes the code for every instruction when compiling each stencil, even though only one of the cases is used.

This extracts the desired cases and compiles them each in isolation, which makes JIT builds almost twice as fast (except on Windows, where I suspect we're still bound by subprocess creation time).

brandtbucher added build The build process and cross-build topic-JIT labels Aug 8, 2024
brandtbucher self-assigned this Aug 8, 2024
bedevere-app Bot mentioned this pull request Aug 8, 2024

savannahostrowski left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

My only question is how, if at all, memory usage is impacted by this change, given the independent compilation.

Otherwise, this is just a tiny comment about adding a comment.

Comment thread Tools/jit/_targets.py
for opname in opnames:
coro = self._compile(opname, TOOLS_JIT_TEMPLATE_C, work)
template = TOOLS_JIT_TEMPLATE_C.read_text()
for case, opname in cases_and_opnames:

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Would it be good to add a comment here about why each of these is compiled independently (e.g., because of the performance benefit)? I'm not sure that would be abundantly clear if I just stumbled upon this code.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Good idea, I'll add a comment.

Copy link
Copy Markdown
Member Author

My only question is how, if at all, memory usage is impacted by this change, given the independent compilation.

The good news is that memory usage should go down, though temporary disk usage will go up.

We were always compiling each opcode independently, but all of the other C code for all of the opcodes not being compiled was part of the same file. Now we are writing out files to disk containing just the C code for each opcode.

As an example, before, we would compile this three times and extract the machine code of each opcode afterwards:

_Py_CODEUNIT *
_JIT_ENTRY(...)
{
    // ...
    switch (FOO) {
        case FOO: {
            // Code for FOO...
        }
        case BAR: {
            // Code for BAR (unused here)...
        }
        case BAZ: {
            // Code for BAZ (unused here)...
        }
    }
    // ...
}
_Py_CODEUNIT *
_JIT_ENTRY(...)
{
    // ...
    switch (BAR) {
        case FOO: {
            // Code for FOO (unused here)...
        }
        case BAR: {
            // Code for BAR...
        }
        case BAZ: {
            // Code for BAZ (unused here)...
        }
    }
    // ...
}
_Py_CODEUNIT *
_JIT_ENTRY(...)
{
    // ...
    switch (BAZ) {
        case FOO: {
            // Code for FOO (unused here)...
        }
        case BAR: {
            // Code for BAR (unused here)...
        }
        case BAZ: {
            // Code for BAZ...
        }
    }
    // ...
}

Now, we only include the necessary case each time, so the C compiler doesn't waste time parsing a bunch of dead C code for the other cases

_Py_CODEUNIT *
_JIT_ENTRY(...)
{
    // ...
    switch (FOO) {
        case FOO: {
            // Code for FOO...
        }
    }
    // ...
}
_Py_CODEUNIT *
_JIT_ENTRY(...)
{
    // ...
    switch (BAR) {
        case BAR: {
            // Code for BAR...
        }
    }
    // ...
}
_Py_CODEUNIT *
_JIT_ENTRY(...)
{
    // ...
    switch (BAZ) {
        case BAZ: {
            // Code for BAZ...
        }
    }
    // ...
}

Hopefully that helps explain what's going on here? It's a bit weird.

brandtbucher merged commit 5118592 into python:main Aug 14, 2024
blhsing pushed a commit to blhsing/cpython that referenced this pull request Aug 22, 2024
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

build The build process and cross-build skip news topic-JIT

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants


Back | FazBrowse Home | New Git URL