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

Provide an "aggressive" specialization/JIT mode for debugging #129386

Open
Assignees
brandtbucher
Labels
interpreter-core(Objects, Python, Grammar, and Parser dirs)performancePerformance or resource usagetopic-JITtype-featureA feature request or enhancement
@brandtbucher

Description

@brandtbucher

@markshannon recently pointed out that our thresholds for JIT stuff are high enough that running the test suite isn't quite the stress test that it used to be. While these thresholds will probably come down with time, it might make sense to provide a mode where specialization and the JIT happen much more aggressively, for development purposes.

Our current values are:

  • ADAPTIVE_WARMUP_VALUE: 1 (specialize the2nd time an instruction is run)
  • ADAPTIVE_COOLDOWN_VALUE: 52 (re-specialize the53rd time a guard fails)
  • JUMP_BACKWARD_INITIAL_VALUE: 4095 (JIT a new "root" trace the4096th time we jump backwards)
  • SIDE_EXIT_INITIAL_VALUE: 4095 (JIT a new side-exit trace the4096th time a guard fails)

I propose that this new mode use the following values:

  • ADAPTIVE_WARMUP_VALUE: 1 (specialize the2nd time an instruction is run)
  • ADAPTIVE_COOLDOWN_VALUE: 1 (re-specialize the2nd time a guard fails)
  • JUMP_BACKWARD_INITIAL_VALUE: 15 (JIT a new "root" trace the16th time we jump backwards)
  • SIDE_EXIT_INITIAL_VALUE: 15 (JIT a new side-exit trace the16th time a guard fails)

A few notes:

  • Specializing the first time an instruction runs leads to weird situations (for example,STORE_ATTR can fail to specialize if storage for the new attribute doesn't exist yet), so it doesn't make sense to reduceADAPTIVE_WARMUP_VALUE further.
  • We fall into infinite loops ifADAPTIVE_COOLDOWN_VALUE is reduced to zero. This probably indicates a bug where we are specializing, then immediately deopting (because the specialization is incorrect somehow).
  • 16 was chosen for the JIT thresholds so that branch counters have time to stabilize.
  • We should probably make this a configure option, not a runtime-togglable value, since these counters are set and reset constantly using static inline functions and constant values, and we want to avoid introducing branching and indirection. Maybe it makes sense to just turn this on if configured--with-pydebug to keep things simple?

Before moving forward with this, we first need to update all tests that hardcode assumptions about these values (I already have a branch for this). This is worth doing anyways so the values can be tweaked in the future with minimal disruption.

Linked PRs

Metadata

Metadata

Assignees

Labels

interpreter-core(Objects, Python, Grammar, and Parser dirs)performancePerformance or resource usagetopic-JITtype-featureA feature request or enhancement

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions


    [8]ページ先頭

    ©2009-2025 Movatter.jp