인라인 함수의 32 바이트 제한 ... 너무 작지 않습니까?

Question

인라인으로 표시된 매우 작은 C# 코드가 있지만 작동하지 않습니다. 가장 긴 함수가 32 바이트 이상의 IL 코드를 생성한다는 것을 보았습니다. 32 바이트 한계가 너무 짧습니까?

// inlined 
[MethodImpl(MethodImplOptions.AggressiveInlining)] 
static public bool INL_IsInRange (this byte pValue, byte pMin) { 
    return(pValue>=pMin); 
} 

// NOT inlined 
[MethodImpl(MethodImplOptions.AggressiveInlining)] 
static public bool INL_IsInRange (this byte pValue, byte pMin, byte pMax) { 
    return(pValue>=pMin&&pValue<=pMax); 
} 

한계를 변경할 수 있습니까?

Answer 1

인라인 함수 조건도 찾고 있습니다. 귀하의 경우에는 JIT 최적화가 두 번째 기능을 인라인하는 결정에 도달하기 전에 시간이 초과되었다고 생각합니다. JIT의 경우, 함수를 인라인하는 것이 우선 순위가 아니기 때문에 긴 코드를 분석하는 것이 바빴습니다. 그러나 내부 통화가 인라인 우선 순위를 얻음에 따라 긴밀한 루프에 전화를 걸면 JIT가 인라인 통화를 수행합니다. 이러한 유형의 마이크로 최적화에 정말로 관심이 있다면 C++로 전환 할 차례입니다. 당신이 탐험하고 개발할 수있는 완전히 새로운 용감한 세계입니다!

이 답변이 게시 된 직후에 질문이 편집되어 높은 수준의 상호 작용을 의미하는 것으로 나타났습니다. 글쎄, 왜 32 바이트의 한계가 있는지 모르겠지만, 그것은 정확히 CPU 캐시 블록의 크기 인 듯하다. 보수적으로 말해서. 이런 우연이! 어떤 경우 든 특정 하드웨어 구성을 사용하여 코드 최적화를 수행해야하며 어셈블리와 함께 추가 파일에 더 잘 저장해야합니다. 시간 제한 정책은 어리 석다. 최적화가 실행시에 완료되지 않아서 귀중한 코드 실행 시간과 경쟁하지 않기 때문이다. 최적화는 응용 프로그램로드 타임에 수행되어야합니다. 처음으로 시스템에서 실행될 때만, 한 번만 수행하면됩니다. 하드웨어 구성 변경이 감지되면 다시 트리거 될 수 있습니다. 다시 말하지만, 실제로 성능이 필요하다면 C/C++로 가십시오. C#은 성능을 위해 설계되지 않았으며 성능을 최우선 순위로 삼지 않습니다. Java와 마찬가지로 C#은 잠재적 인 부정적인 성능 영향에 대해 훨씬 더주의하여 안전을 위해 설계되었습니다.