Improve ExecutionContext fast-paths

[benaadams]

Improve some of the ThreadPool fast-paths, reduce indirect calls for AsyncValueTaskMethodBuilder<T>; AsyncTaskMethodBuilder<T> and Timer; by calling .MoveNext() directly call rather via the indirect chain EC.Run -> delegate -> .MoveNext() which should help with the CPU's instruction cache and indirect branch prediction (Intel only tries to predict one indirect call, not chains?).

Split merged methods switched on if into their respective callers:

• Remove extra call for AsyncValueTaskMethodBuilder<T> and AsyncTaskMethodBuilder<T> for MoveNext() and IThreadPoolWorkItem.Execute() (since they are top level virtual/interface and their callee is too big to inline into them)

Optimize invocations from ThreadPoolWorkQueue.Dispatch:

• AsyncValueTaskMethodBuilder<T>; AsyncTaskMethodBuilder<T> and Timer can call .MoveNext() directly if Default context and called from ThreadPoolWorkQueue.Dispatch.
• AsyncValueTaskMethodBuilder<T>; AsyncTaskMethodBuilder<T> and Timer don't need to touch ThreadStatic CurrentThread called from ThreadPoolWorkQueue.Dispatch.
• AsyncValueTaskMethodBuilder<T>; AsyncTaskMethodBuilder<T> and Timer can use simpler EC run when not-Default context and called from ThreadPoolWorkQueue.Dispatch.

Optimize invocations for Default context:

• AsyncValueTaskMethodBuilder<T>; AsyncTaskMethodBuilder<T> and Timer can call .MoveNext() directly if Default context and thread currently on Default context.

Json callers (on Default context; which become extra fast-pathed)

Fortunes callers (on Default context; which become extra fast-pathed)

[benaadams]

@stephentoub issues resolved?

[stephentoub]

@stephentoub issues resolved?

Functionally it looks ok to me. Does it have a measurable perf impact?

[benaadams]

Does it have a measurable perf impact?

Is peanut butter; at least 0.5% of ThreadPool.Dispatch for Json

Though it does also fix an existing issue with EC restore for legacyUnhandledExceptionPolicy / host policy; that you highlighted in #36538 (comment)

[benaadams]

Downside is it doesn't effect IOQueue callbacks; which do the full EC Run since they aren't directly run from the ThreadPool; which is also where some of the interface casting callbacks come from (since it isn't cast away on queue to ThreadPool)

[stephentoub]

Is peanut butter; at least 0.5% of ThreadPool.Dispatch for Json

Does that mean we see this change improving json TE throughout by 10K RPS? Can we run the benchmarks with it?

[kouvel]

Will long lived Action variables that are early captures point at their Tier0 methods rather than Tier1 due to when they were captured?

I'm not seeing this comment anymore, but the delegate would call the method through a precode and the precode target would be updated to point to the Tier1 code once it's ready. Currently when tiering is enabled, direct calls also call through a precode. When a method is jitted before a callee is jitted, the call would go through a precode (when tiering is disabled too). If the callee is already Tier1 it may be possible to avoid calling through the precode, I'll have to look into this, the same would apply to delegates as well.

[benaadams]

Just curious... Are the precodes jmp blocks (like a trampoline or tailcall, as it were) or does it end up being a double call?

Currently when tiering is enabled, direct calls also call through a precode. When a method is jitted before a callee is jitted, the call would go through a precode (when tiering is disabled too).

So they always called this way rather direct calls going directly to method; making inlining having an additional effectiveness of eliminating the indirection? (aside from the other advantages of inlining)

[kouvel]

Are the precodes jmp blocks (like a trampoline or tailcall, as it were)

Yea they are jmp blocks

So they always called this way rather direct calls going directly to method; making inlining having an additional effectiveness of eliminating the indirection?

Possibly, I had done a bit of prototyping on this before and didn't see much improvement in steady-state from fixing direct calls but some noticeable startup improvement as there would be more calls involved. May also depend on arch/processor, as prefetching helps to avoid the overhead. Delegate calls may be more expensive though, curious to see.

[benaadams]

Delegate calls may be more expensive though, curious to see.

If I was to go all in; it would be something like this https://github.com/dotnet/runtime/compare/master...benaadams:EC-all-in?expand=1

To turn all the Default context => Default context runs into direct calls rather than the triple: call => delegate => call; so it would also pick up all these in for example the Fortunes benchmark:

Since they are chains of async only the first couple are picked up by this change as they run directly on ThreadPool, the follow on inlines don't get picked up.

[benaadams]

Hmm, might be able to do that, but in better way

[benaadams]

Does that mean we see this change improving json TE throughout by 10K RPS? Can we run the benchmarks with it?

@adamsitnik can you help here?

[adamsitnik]

can you help here?

Sure! Is there any chance that you could send me a Release copy of your System.Private.CoreLib.dll built for Unix?

[adamsitnik]

@benaadams I've run them twice (after #1 and after #2)

You can find the trace files in traces/36538_ExecutionContext

[benaadams]

Get faster; get more contention, go slower? :-/

[stephentoub]

@benaadams, seems like this should be closed, since for whatever reason we see things getting worse with it?

[benaadams]

seems like this should be closed

Would like to revisit when EH write through is on by default

[stephentoub]

Sounds good. Let's close it until then. Thanks.