Dichiarazione di più array con 64 elementi 1000 volte più veloce rispetto alla dichiarazione di array di 65 elementi

Recentemente ho notato che dichiarare un array contenente 64 elementi è molto più veloce (> 1000 volte) rispetto a dichiarare lo stesso tipo di array con 65 elementi.

Ecco il codice che ho usato per testarlo:

public class Tests{
    public static void main(String args[]){
        double start = System.nanoTime();
        int job = 100000000;//100 million
        for(int i = 0; i < job; i++){
            double[] test = new double[64];
        }
        double end = System.nanoTime();
        System.out.println("Total runtime = " + (end-start)/1000000 + " ms");
    }
}

Questo viene eseguito in circa 6 ms, se sostituisco new double[64]con new double[65]ci vogliono circa 7 secondi. Questo problema diventa esponenzialmente più grave se il lavoro viene distribuito su un numero sempre maggiore di thread, da cui ha origine il mio problema.

Questo problema si verifica anche con diversi tipi di matrici come int[65]o String[65]. Questo problema non si verifica con stringhe di grandi dimensioni:, String test = "many characters";ma inizia a verificarsi quando viene modificato inString test = i + "";

Mi chiedevo perché è così e se è possibile aggirare questo problema.

Stai osservando un comportamento causato dalle ottimizzazioni eseguite dal compilatore JIT della tua Java VM. Questo comportamento è riproducibile attivato con matrici scalari fino a 64 elementi e non viene attivato con matrici più grandi di 64.

Prima di entrare nei dettagli, diamo un'occhiata più da vicino al corpo del loop:

double[] test = new double[64];

Il corpo non ha alcun effetto (comportamento osservabile) . Ciò significa che non fa differenza al di fuori dell'esecuzione del programma se questa istruzione viene eseguita o meno. Lo stesso vale per l'intero ciclo. Quindi potrebbe accadere che l'ottimizzatore del codice traduca il ciclo in qualcosa (o niente) con lo stesso comportamento di temporizzazione funzionale e diverso.

Per i benchmark dovresti almeno aderire alle seguenti due linee guida. Se lo avessi fatto, la differenza sarebbe stata notevolmente inferiore.

• Riscaldare il compilatore (e l'ottimizzatore) JIT eseguendo più volte il benchmark.
• Usa il risultato di ogni espressione e stampalo alla fine del benchmark.

Adesso entriamo nei dettagli. Non sorprende che ci sia un'ottimizzazione che viene attivata per array scalari non più grandi di 64 elementi. L'ottimizzazione fa parte dell'analisi Escape . Mette piccoli oggetti e piccoli array nello stack invece di allocarli nell'heap, o meglio ancora ottimizzarli del tutto. Puoi trovare alcune informazioni a riguardo nel seguente articolo di Brian Goetz scritto nel 2005:

• Leggende delle prestazioni urbane, rivisitate: l'allocazione è più veloce di quanto pensi e sta diventando sempre più veloce

L'ottimizzazione può essere disabilitata con l'opzione della riga di comando -XX:-DoEscapeAnalysis. Il valore magico 64 per gli array scalari può anche essere modificato dalla riga di comando. Se esegui il programma come segue, non ci saranno differenze tra gli array con 64 e 65 elementi:

java -XX:EliminateAllocationArraySizeLimit=65 Tests

Detto questo, sconsiglio vivamente di utilizzare tali opzioni della riga di comando. Dubito che faccia un'enorme differenza in un'applicazione realistica. Lo userei solo se fossi assolutamente convinto della necessità - e non basandomi sui risultati di alcuni pseudo benchmark.

Ci sono molti modi in cui ci può essere una differenza, in base alle dimensioni di un oggetto.

Come affermato da nosid, il JITC potrebbe (molto probabilmente) allocare piccoli oggetti "locali" sullo stack, e il limite di dimensione per array "piccoli" può essere a 64 elementi.

L'allocazione sullo stack è notevolmente più veloce dell'allocazione nell'heap e, soprattutto, lo stack non deve essere sottoposto a garbage collection, quindi l'overhead GC viene notevolmente ridotto. (E per questo caso di test il sovraccarico GC è probabilmente l'80-90% del tempo di esecuzione totale.)

Inoltre, una volta che il valore è stato allocato nello stack, JITC può eseguire l '"eliminazione del codice inattivo", determinare che il risultato di newnon viene mai utilizzato da nessuna parte e, dopo essersi assicurati che non ci siano effetti collaterali che andrebbero persi, eliminare l'intera newoperazione, e poi il ciclo (ora vuoto) stesso.

Anche se JITC non esegue l'allocazione dello stack, è del tutto possibile che oggetti più piccoli di una certa dimensione vengano allocati in un heap in modo diverso (ad esempio, da uno "spazio" diverso) rispetto a oggetti più grandi. (Normalmente questo non produrrebbe differenze temporali così drammatiche, però.)