Forzare il compilatore JIT .NET per generare il codice più ottimizzato durante l'applicazione di start-up

Question

Sto scrivendo una domanda di DSP in C # (in pratica un editor multitraccia). Ho Profiling per un bel po 'di tempo su macchine diverse e ho notato alcune cose 'curiosi'.

Sulla mia macchina a casa, la prima esecuzione del ciclo di riproduzione occupa circa il 50% -60% del tempo a disposizione, (presumo che sia a causa del JIT facendo il suo lavoro), poi per i cicli successivi scende a una costante consumo 5%. Il problema è, se corro l'applicazione su un computer più lento, la prima esecuzione assorbe oltre il tempo a disposizione, causando la riproduzione viene interrotta e rovinare l'uscita audio, che è inaccettabile. Dopo di che, si scende ad un 8% di consumo -10%.

Anche dopo la prima manche, l'applicazione continua a chiamare alcune routine in termini di tempo di volta in volta (ogni 2 secondi più o meno), che causa la costante consumo di 5% per sperimentare picchi molto brevi del 20% -25%. Ho notato che se lascio la corsa domanda di un po 'di questi picchi anche scendere al 7% -10%. (Io non sono sicuro se è dovuto alla ricompilazione JIT queste porzioni di codice).

Quindi, ho un problema serio con il JIT. Mentre l'applicazione si comporterà bene anche su macchine molto lente, queste 'tempeste di compilazione' stanno per essere un grosso problema. Sto cercando di capire come risolvere questo problema e mi è venuta in mente un'idea, che è quello di segnare tutte le routine 'sensibili' con un attributo che vi dirà l'applicazione di spremere 'loro in anticipo durante l'avviamento , in modo da essere completamente ottimizzato quando sono veramente necessari. Ma questa è solo un'idea (e non mi piace troppo neanche) e mi chiedo se c'è una soluzione migliore per l'intero problema.

Mi piacerebbe sentire cosa pensate voi ragazzi.

(NGEN l'applicazione non è un'opzione, mi piace e voglio tutte le ottimizzazioni JIT posso ottenere.)

EDIT:

il consumo di memoria e di raccolta dei rifiuti calci non sono un problema, sto usando piscine oggetto e il picco massimo della memoria durante la riproduzione è 304 Kb.

Answer 1

È possibile attivare il compilatore JIT per compilare l'intera serie di assemblee durante la routine di inizializzazione dell'applicazione utilizzando il metodo di PrepareMethod ... (senza dover utilizzare NGen).

Questa soluzione è descritta in dettaglio qui: Forzare la compilazione JIT durante il runtime .

Answer 2

La velocità iniziale suona effettivamente come Fusion + JIT, che sarebbe aiutato da ILMerge (per fusione) e NGEN (per JIT); si può sempre riprodurre un brano silenzioso attraverso il sistema in fase di avvio in modo che questo fa tutto il duro lavoro senza che l'utente ne accorga alcuna distorsione?

NGEN è una buona opzione; c'è una ragione non si può utilizzare?

I problemi si menzionano dopo il caricamento iniziale fare non suono come sono legati a JIT. Forse la raccolta dei rifiuti.

Hai provato profiling? Sia CPU e della memoria (collezioni)?

Answer 3

Come Marc accennato, le punte in corso non suonano come le questioni JIT. Altre cose da cercare:

• Garbage Collection - stai allocazione di memoria durante il processamento audio? Se si sta creando un sacco di immondizia, o anche oggetti che sopravvivono una raccolta Gen 0, questo potrebbe causare picchi noticible. Sembra che si sta facendo una sorta di pre-assegnazione, ma fai attenzione alle assegnazioni nascosti nel codice della libreria (anche un ciclo foreach può allocare!)

• Denormals. V'è un problema con alcuni tipi di processori quando si tratta di molto piccoli numeri in virgola mobile che possono causare picchi di CPU. Vedere http://www.musicdsp.org/files/denormal.pdf per i dettagli .

Modifica:

Anche se non si desidera utilizzare NGen, almeno confrontare una versione NGen'd modo da poter vedere che cosa JITing differenza fa

Answer 4

Se si ritiene di essere state minaccia per il JIT, poi precompilare la tua app con NGEN ed eseguire nuovamente il test. Non v'è alcun sovraccarico JIT in codice che è stato compilato da NGEN. Se si vede ancora picchi in app NGEN'd, poi si sa che non sono causati da JIT.