Les compilateurs JIT de JVM génèrent-ils du code qui utilise des instructions en virgule flottante vectorisées?

Disons que le goulot d'étranglement de mon programme Java est vraiment quelques boucles serrées pour calculer un tas de produits scalaires vectoriels. Oui j'ai profilé, oui c'est le goulot d'étranglement, oui c'est significatif, oui c'est juste comme ça que l'algorithme est, oui j'ai exécuté Proguard pour optimiser le byte code, etc.

Le travail consiste essentiellement en des produits scalaires. Comme dans, j'en ai deux float[50]et je dois calculer la somme des produits par paire. Je sais que des jeux d'instructions de processeur existent pour effectuer ce genre d'opérations rapidement et en masse, comme SSE ou MMX.

Oui, je peux probablement y accéder en écrivant du code natif dans JNI. L'appel JNI s'avère assez cher.

Je sais que vous ne pouvez pas garantir ce qu'un JIT compilera ou non. Quelqu'un a-t-il déjà entendu parler d'un code de génération JIT utilisant ces instructions? et si oui, y a-t-il quelque chose dans le code Java qui aide à le rendre compilable de cette façon?

Probablement un "non"; vaut la peine de demander.

Donc, fondamentalement, vous voulez que votre code s'exécute plus rapidement. JNI est la réponse. Je sais que vous avez dit que cela n'a pas fonctionné pour vous, mais laissez-moi vous montrer que vous vous trompez.

Voici Dot.java:

import java.nio.FloatBuffer;
import org.bytedeco.javacpp.*;
import org.bytedeco.javacpp.annotation.*;

@Platform(include = "Dot.h", compiler = "fastfpu")
public class Dot {
    static { Loader.load(); }

    static float[] a = new float[50], b = new float[50];
    static float dot() {
        float sum = 0;
        for (int i = 0; i < 50; i++) {
            sum += a[i]*b[i];
        }
        return sum;
    }
    static native @MemberGetter FloatPointer ac();
    static native @MemberGetter FloatPointer bc();
    static native @NoException float dotc();

    public static void main(String[] args) {
        FloatBuffer ab = ac().capacity(50).asBuffer();
        FloatBuffer bb = bc().capacity(50).asBuffer();

        for (int i = 0; i < 10000000; i++) {
            a[i%50] = b[i%50] = dot();
            float sum = dotc();
            ab.put(i%50, sum);
            bb.put(i%50, sum);
        }
        long t1 = System.nanoTime();
        for (int i = 0; i < 10000000; i++) {
            a[i%50] = b[i%50] = dot();
        }
        long t2 = System.nanoTime();
        for (int i = 0; i < 10000000; i++) {
            float sum = dotc();
            ab.put(i%50, sum);
            bb.put(i%50, sum);
        }
        long t3 = System.nanoTime();
        System.out.println("dot(): " + (t2 - t1)/10000000 + " ns");
        System.out.println("dotc(): "  + (t3 - t2)/10000000 + " ns");
    }
}

et Dot.h:

float ac[50], bc[50];

inline float dotc() {
    float sum = 0;
    for (int i = 0; i < 50; i++) {
        sum += ac[i]*bc[i];
    }
    return sum;
}

Nous pouvons compiler et exécuter cela avec JavaCPP en utilisant cette commande:

$ java -jar javacpp.jar Dot.java -exec

Avec un processeur Intel (R) Core (TM) i7-7700HQ à 2,80 GHz, Fedora 30, GCC 9.1.1 et OpenJDK 8 ou 11, j'obtiens ce type de sortie:

dot(): 39 ns
dotc(): 16 ns

Ou environ 2,4 fois plus rapide. Nous devons utiliser des tampons NIO directs au lieu de baies, mais HotSpot peut accéder aux tampons NIO directs aussi rapidement que des baies . En revanche, le déroulement manuel de la boucle n'apporte pas une amélioration mesurable des performances, dans ce cas.

Pour répondre à une partie du scepticisme exprimé par d'autres ici, je suggère à quiconque souhaite se prouver à lui-même ou à d'autres d'utiliser la méthode suivante:

• Créer un projet JMH
• Écrivez un petit extrait de mathématiques vectorisables.
• Exécutez leur benchmark en basculant entre -XX: -UseSuperWord et -XX: + UseSuperWord (par défaut)
• Si aucune différence de performances n'est observée, votre code n'a probablement pas été vectorisé
• Pour vous en assurer, exécutez votre benchmark de sorte qu'il imprime l'assemblage. Sous Linux, vous pouvez profiter du profileur de perfasm ('- prof perfasm'), jeter un œil et voir si les instructions que vous attendez sont générées.

Exemple:

@Benchmark
@CompilerControl(CompilerControl.Mode.DONT_INLINE) //makes looking at assembly easier
public void inc() {
    for (int i=0;i<a.length;i++)
        a[i]++;// a is an int[], I benchmarked with size 32K
}

Le résultat avec et sans le drapeau (sur un ordinateur portable récent Haswell, Oracle JDK 8u60): -XX: + UseSuperWord: 475,073 ± 44,579 ns / op (nanosecondes par opération) -XX: -UseSuperWord: 3376,364 ± 233,211 ns / op

L'assemblage pour la boucle chaude est un peu difficile à formater et à coller ici, mais voici un extrait (hsdis.so ne parvient pas à formater certaines des instructions vectorielles AVX2, j'ai donc exécuté avec -XX: UseAVX = 1): -XX: + UseSuperWord (avec '-prof perfasm: intelSyntax = true')

  9.15%   10.90%  │││ │↗    0x00007fc09d1ece60: vmovdqu xmm1,XMMWORD PTR [r10+r9*4+0x18]
 10.63%    9.78%  │││ ││    0x00007fc09d1ece67: vpaddd xmm1,xmm1,xmm0
 12.47%   12.67%  │││ ││    0x00007fc09d1ece6b: movsxd r11,r9d
  8.54%    7.82%  │││ ││    0x00007fc09d1ece6e: vmovdqu xmm2,XMMWORD PTR [r10+r11*4+0x28]
                  │││ ││                                                  ;*iaload
                  │││ ││                                                  ; - psy.lob.saw.VectorMath::inc@17 (line 45)
 10.68%   10.36%  │││ ││    0x00007fc09d1ece75: vmovdqu XMMWORD PTR [r10+r9*4+0x18],xmm1
 10.65%   10.44%  │││ ││    0x00007fc09d1ece7c: vpaddd xmm1,xmm2,xmm0
 10.11%   11.94%  │││ ││    0x00007fc09d1ece80: vmovdqu XMMWORD PTR [r10+r11*4+0x28],xmm1
                  │││ ││                                                  ;*iastore
                  │││ ││                                                  ; - psy.lob.saw.VectorMath::inc@20 (line 45)
 11.19%   12.65%  │││ ││    0x00007fc09d1ece87: add    r9d,0x8            ;*iinc
                  │││ ││                                                  ; - psy.lob.saw.VectorMath::inc@21 (line 44)
  8.38%    9.50%  │││ ││    0x00007fc09d1ece8b: cmp    r9d,ecx
                  │││ │╰    0x00007fc09d1ece8e: jl     0x00007fc09d1ece60  ;*if_icmpge

Amusez-vous à prendre d'assaut le château!

Dans les versions HotSpot commençant par Java 7u40, le compilateur de serveur prend en charge la vectorisation automatique. Selon JDK-6340864

Cependant, cela ne semble vrai que pour les «boucles simples» - du moins pour le moment. Par exemple, l'accumulation d'un tableau ne peut pas encore être vectorisée JDK-7192383

Voici un bel article sur l'expérimentation des instructions Java et SIMD écrites par mon ami: http://prestodb.rocks/code/simd/

Son résultat général est que vous pouvez vous attendre à ce que JIT utilise certaines opérations SSE en 1.8 (et d'autres en 1.9). Bien que vous ne devriez pas vous attendre à grand-chose et que vous devez être prudent.

Vous pouvez écrire le noyau OpenCl pour faire le calcul et l'exécuter à partir de java http://www.jocl.org/ .

Le code peut être exécuté sur le CPU et / ou le GPU et le langage OpenCL prend également en charge les types vectoriels, vous devriez donc être en mesure de tirer explicitement parti des instructions SSE3 / 4, par exemple.

Jetez un œil à la comparaison des performances entre Java et JNI pour une implémentation optimale des micro-noyaux de calcul . Ils montrent que le compilateur de serveur Java HotSpot VM prend en charge la vectorisation automatique à l'aide du parallélisme de niveau super-mot, qui est limité à de simples cas de parallélisme à l'intérieur de la boucle. Cet article vous indiquera également si la taille de vos données est suffisamment grande pour justifier une route JNI.

Je suppose que vous avez écrit cette question avant de découvrir netlib-java ;-) il fournit exactement l'API native dont vous avez besoin, avec des implémentations optimisées pour la machine, et n'a aucun coût à la limite native grâce à l'épinglage de la mémoire.

Je ne pense pas que la plupart des machines virtuelles soient suffisamment intelligentes pour ce type d'optimisation. Pour être juste, la plupart des optimisations sont beaucoup plus simples, comme le décalage au lieu de la multiplication quand une puissance de deux. Le projet mono a introduit son propre vecteur et d'autres méthodes avec des supports natifs pour améliorer les performances.