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

JIT: enable aggressive inline policy for Tier1 #15046

Closed
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
3 participants
@AndyAyersMS
Member

AndyAyersMS commented Nov 15, 2017

Some preliminary work to address the impact of tiering on steady-state
performance. When the jit is asked to rejit a method, use a much more
aggressive inlinling policy than we use for normal jitting.

This version of jit codgen can also be tested explicitly by setting

COMPlus_JitOptimizeType=2

or in debug/chk by setting

COMPlus_JitInlinePolicyFull=1

It is not otherwise reachable.

This policy is quite likely too aggressive and we will likely adjust things
as we get more experience looking at steady-state perf under tiering.

The remainder of the jit's behavior is not impacted, though it might be
reasonable to increase some of the thresholds and alter some of the cost
models used in other phases.

Also modify jitbench to be a bit more explicit about which mode it thinks it
is running, as a way to double-check that we're measuring what we think we are.

JIT: enable aggressive inline policy for Tier1
Some preliminary work to address the impact of tiering on steady-state
performance. When the jit is asked to rejit a method, use a much more
aggressive inlinling policy than we use for normal jitting.

This version of jit codgen can also be tested explicitly by setting

  `COMPlus_JitOptimizeType=2`

or in debug/chk by setting

  `COMPlus_JitInlinePolicyFull=1`

It is not otherwise reachable.

This policy is quite likely *too* aggressive and we will likely adjust things
as we get more experience looking at steady-state perf under tiering.

The remainder of the jit's behavior is not impacted, though it might be
reasonable to increase some of the thresholds and alter some of the cost
models used in other phases.

Also modify jitbench to be a bit more explicit about which mode it thinks it
is running, as a way to double-check that we're measuring what we think we are.
@AndyAyersMS

This comment has been minimized.

Show comment
Hide comment
@AndyAyersMS

AndyAyersMS Nov 15, 2017

Member

@noahfalk PTAL
cc @dotnet/jit-contrib

Still evaluating perf impact. Wanted to put this up so Noah could try it out as well.

Member

AndyAyersMS commented Nov 15, 2017

@noahfalk PTAL
cc @dotnet/jit-contrib

Still evaluating perf impact. Wanted to put this up so Noah could try it out as well.

@jkotas jkotas added the area-CodeGen label Dec 28, 2017

@AndyAyersMS

This comment has been minimized.

Show comment
Hide comment
@AndyAyersMS

AndyAyersMS Jan 5, 2018

Member

Probably going to have to shelve this for now ... the policy is likely too aggressive and we don't have adequate scenario coverage, so soundly evaluating changes that lead to potentially large increases in jit time is not possible.

Member

AndyAyersMS commented Jan 5, 2018

Probably going to have to shelve this for now ... the policy is likely too aggressive and we don't have adequate scenario coverage, so soundly evaluating changes that lead to potentially large increases in jit time is not possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment