Miglioramenti del jitter C# nelle versioni future del framework

Question

Ho notato che il jitter C# produce codice più lento rispetto al compilatore C++, anche se non sono utilizzati costrutti "overhead gestiti" (come gli array con indicizzazione controllata).

Per quantificarlo, ho cronometrato il seguente semplice ciclo:

public static int count = 1000000000; 
public static int Main() 
{ 
    int j = 0; 
    for (int i = 0; i < count; ++i) 
    { 
     j += (i % 2 == 0) ? ((i + 7) >> 3) : (i * 7); 
    } 
    return j; 
} 

Questo ciclo prende 3.88s da eseguire (compilato con/o). Il ciclo equivalente compilato con VC 2010 (-O2) richiede 2,95 secondi.

Per verificare che il codice inferiore sia stato effettivamente generato, ho confrontato i codici macchina: creato un elenco (/ FA) dal compilatore VC e collegato un debugger al programma C# (dopo che il ciclo era completato).

Infatti, la versione C++ utilizza alcuni trucchi intelligenti. Ad esempio, per evitare costose moltiplicazioni per 7, esiste un registro separato che viene incrementato di 7 ogni numero di cicli. La versione C# esegue la moltiplicazione (imul) ogni volta. Ci sono anche altre differenze.

Comprendo che il jitter C# ha molto meno tempo per compilare il codice in fase di esecuzione rispetto a VC in fase di compilazione. Ma ad es. Il jitter Java sta ottimizzando dinamicamente i metodi usati frequentemente. C# non sembra farlo.

La mia domanda è: ci sono piani per migliorare il jitter C# nelle versioni future del framework?

Answer 1

ci sono piani per migliorare il jitter C# nelle future versioni del framework?

Stai chiedendo se ci fosse in realtà un incontro segreto il mese scorso tra Microsoft e Xamarin in cui si è convenuto che, mentre avevano sia trascorso l'ultimo decennio migliorare le loro rispettive nervosismi, che d'ora in poi erano malati di rendere le cose migliori e non darebbe più fastidio, e MS riassegnerebbe tutti mentre Xamarin rifiuterebbe ogni patch inviata che migliorasse il jitter?

Direi che questo è improbabile, e che come ogni altro progetto di software sviluppato attivamente nel mondo, ci sono piani per migliorarlo.

Inoltre, se volessi davvero eseguire il codice che avevi dato il più rapidamente possibile, lo ottimizzerei a mano in return 161315136;. Un codice del genere può dimostrare che l'implementazione A è più lenta dell'implementazione B in un determinato caso, ma non dice nulla su dove le persone che stanno dietro l'implementazione dovrebbero concentrare i loro sforzi. costruisce

Answer 2

uscita, VS2008SP1, .NET 3.5SP1, media di 10 prove:

.NET, x86: 2.646 seconds 
C++, x86: 2.652 seconds 
.NET, x64: 2.352 seconds 
C++, x64: 2.090 seconds 

errori classici sono supponendo che/o è significativo, la misurazione del tempo jitting, che esegue il build di debug, il test con il debugger quindi l'ottimizzatore jitter è disabilitato.

Il jitter x64 utilizza lo stesso trucco che lei ha citato, che non riguardano solo il generatore di codice C++:

00000030 xor   r9d,r9d 
... 
00000059 add   r9d,7 

Una nuova funzionalità per NET 4.5 è Profilo Ottimizzazione guidata.

I piani futuri non sono mai condivisi da un'azienda come Microsoft e non ha senso indovinarli.