Posso controllare se il compilatore C# ha delineato una chiamata al metodo?

Question

Sto scrivendo un gioco XNA in cui eseguo controlli di collisione per pixel. Il ciclo che verifica ciò avviene spostando un ORing bitonale e int e generalmente è difficile da leggere e capire.

Vorrei aggiungere metodi privati ​​come private bool IsTransparent(int pixelColorValue) per rendere il ciclo più leggibile, ma non voglio il sovraccarico delle chiamate ai metodi poiché questo è un codice molto sensibile alle prestazioni.

C'è un modo per forzare il compilatore a incorporare questa chiamata o lo farò? Spero solo che il compilatore faccia questa ottimizzazione?

Se non c'è un modo per forzare questo, c'è un modo per verificare se il metodo è stato inarcato, a meno di leggere lo smontaggio? Il metodo verrà visualizzato in riflessione se è stato allineato e nessun altro chiamante esiste?

Modifica: Non riesco a forzarlo, quindi posso rilevarlo?

Answer 1

No non si può. Ancor più, colui che decide di inlining non è il compilatore VS che ti porta il codice e lo converte in IL, ma il compilatore JIT che prende IL e lo converte in codice macchina. Questo perché solo il compilatore JIT conosce abbastanza l'architettura del processore per decidere se mettere un metodo in linea sia appropriato in quanto è un compromesso tra il pipelining dell'istruzione e la dimensione della cache.

Quindi anche cercare in .NET Reflector non ti aiuterà.

Answer 2

No, non è possibile.

Fondamentalmente, non è possibile farlo nella maggior parte dei compilatori C++ moderni. inline è solo un'offerta al compilatore. È libero di prenderlo o no.

Il compilatore C# non esegue alcuna inlining speciale a livello IL. L'ottimizzatore JIT è quello che lo farà.

Answer 3

"È possibile controllare System.Reflection.MethodBase.GetCurrentMethod(). Name. Se il metodo è inline, verrà restituire il nome del chiamante invece."

- Joel Coehoorn

Answer 4

È possibile rilevarlo in fase di esecuzione con la chiamata GetCurrentMethod di cui sopra. Ma sembrerebbe un po 'uno spreco [1]. La cosa più semplice da fare sarebbe solo ILDASM il MSIL e controllare lì.

Nota che questo è specifico per il compilatore inlining della chiamata ed è coperto nei vari documenti Reflection su MSDN.

Se il metodo che chiama il metodo GetCallingAssembly viene espanso in linea dal compilatore (cioè, se il compilatore inserisce il corpo funzione nella lingua intermedia Microsoft emessa (MSIL), piuttosto che emettendo una chiamata di funzione), allora l'assembly restituito dal metodo GetCallingAssembly è l'assembly che contiene il codice inline. Questo potrebbe essere diverso dall'assembly che contiene il metodo originale. Per garantire che un metodo che richiama il metodo GetCallingAssembly non sia delineato dal compilatore, è possibile applicare l'attributo MethodImplAttribute con MethodImplOptions.NoInlining.

Tuttavia, il JITter è anche libero da chiamate in linea, ma penso che un disassemblatore sarebbe l'unico modo per verificare ciò che è e non è fatto a quel livello.

Modifica: solo per chiarire un po 'di confusione in questa discussione, csc.exe will inline MSIL calls - sebbene JITter sia (probabilmente) più aggressivo al suo interno.

[1] E, per rifiuto, intendo che (a) che sconfigge lo scopo dell'inlining (prestazioni migliori) a causa della ricerca di Reflection. E (b), probabilmente cambierebbe il comportamento in linea in modo che non fosse più in linea comunque. E, prima di pensare di poterlo solo accendere con build di Debug con un Assert o qualcosa del genere, renditi conto che non sarà inserito durante Debug, ma potrebbe essere in Release.

Answer 5

perché non utilizzare codice non sicuro (inline c come è noto) e utilizzare i puntatori di stile c/C++, questo è sicuro dal GC (cioè non influenzato dalla raccolta) ma ha le sue implicazioni sulla sicurezza (non può essere usato per app di zona internet), ma è eccellente per il tipo di cosa che si sta cercando di ottenere soprattutto con le prestazioni e ancora di più con gli array e le operazioni bit a bit?

per riepilogare, vuoi prestazioni per una piccola parte della tua app? utilizzare codice non sicuro e utilizzare i puntatori, ecc sembra l'opzione migliore per me

EDIT: un po 'di un antipasto? http://msdn.microsoft.com/en-us/library/aa288474(VS.71).aspx

Answer 6

C'è un modo per forzare il compilatore a inline questa chiamata o farò Spero solo che il compilatore farà questa ottimizzazione?

Se è meno costoso integrare la funzione, lo farà. Quindi non preoccuparti a meno che il tuo profiler non dica che in realtà è un problema.

Per ulteriori informazioni

JIT Enhancements in .NET 3.5 SP1

Answer 7

essere consapevoli del fatto che la Xbox funziona diverso.

Google alzato questa:

"Il metodo inline che mitiga il sovraccarico di una chiamata di un metodo forme JIT in una linea quanto soddisfa le seguenti condizioni

• Il codice IL.. dimensione è di 16 byte o meno.
• Il comando ramo non viene utilizzato (se frase ecc).
• La variabile locale non viene utilizzato.
• La gestione delle eccezioni non è stata effettuata a (try, catch, ecc.).
• float non viene utilizzato come argomento o valore di ritorno di un metodo (probabilmente da Xbox 360, non applicato).
• Quando due o più argomenti sono in un metodo , vengono utilizzati per il turno dichiarato .

Tuttavia, una funzione virtuale non è formata in linea."

http://xnafever.blogspot.com/2008/07/inline-method-by-xna-on-xbox360.html

ho idea se è corretta. Chiunque?

Answer 8

L'unico modo per verificare questo è quello di ottenere o scrivere un profiler, e agganciare sui fatti JIT, è necessario anche fare assicurarsi inlining non si spegne come lo è di default a profilare

Answer 9

C'è un nuovo modo per incoraggiare più aggressivo di espansione in .net 4.5 che è descritto qui:. http://blogs.microsoft.co.il/blogs/sasha/archive/2012/01/20/aggressive-inlining-in-the-clr-4-5-jit.aspx

Fondamentalmente si tratta solo di una bandiera per TE Se il compilatore è in linea, se possibile. Sfortunatamente, non è disponibile nella versione corrente di XNA (Game Studio 4.0), ma dovrebbe essere disponibile quando XNA raggiungerà VS 2012 quest'anno. È già disponibile se in qualche modo stai girando su Mono.

[MethodImpl(MethodImplOptions.AggressiveInlining)] 
public static int LargeMethod(int i, int j) 
{ 
    if (i + 14 > j) 
    { 
     return i + j; 
    } 
    else if (j * 12 < i) 
    { 
     return 42 + i - j * 7; 
    } 
    else 
    { 
     return i % 14 - j; 
    } 
}