Introduction

Fabien Cellier?

WebCL(security+firefox),modélisation 3d,SIG...

HPC, définition, histoire....

• grille, superordinateur(avec problème intrinsèque: chaleur, énérgie...)
• lien avec le calcul parallèle et évolution vers le MPI
• Pour parler de navigateur? -> L'approche "opportunist + patterns" -> partie code efficace

Efficacité du code, pourquoi?

• Simulation (astres, catastrophes, météo)
• Statistiques,
• Vidéos (3d, reconnaissance)....

Il y a deux types de besoins: la base latence qui repose sur du code efficace principalement et le traitement de big data qui repose sur le partitionnement

PAS BESOIN de PERFORMANCE PARTOUT!!! (IHM)

Informations utiles

Optimisation du code

L'optimisation reste complexe (scheduling, "cache miss"...) et parfois peu portable (CUDA/OpenCL utilise souvent un code pour CPU et un autre pour GPU etc...)

mais toujours comparer de facon honnete: CPU intel xeon octo-core c'est 256 unités de calcul si on comptabilise les unités pour la vectorisation donc comparable à un GPU milieu de gamme

Parallèlisme

• SIMD
• MIMD
• MPI
• ...

Le parallélisme est souvent le chemin le plus simple pour augmenter les performances

Javascript efficace? problèmes

• le design
• le design
• le design
• ...

Javascript efficace? problèmes [2]

• le boxing
• manière de gérer la sécurité
• le GC
• l'absence d'information bas niveau pour le compilateur (comparé au C++)
• manque de parallélisme de données
• ...

quelques chiffres

Une simulation sur 2 millions de particules (32 itérations), utilise intensivement des arbres et tableaux

• Javascript naif: 100 secondes (pour 10 minutes de dev)
• Javascript optimisé: 31 secondes (2 heures de dev,emscripten)
• asm.js naif: 8.2 secondes (pour 2h de dev)
• GPGPU sur GPU(webCL like, sécurisé): 120 ms (pour 3h de dev)
• GPGPU sur CPU(webCL like, sécurisé): 110 ms (pour 5h de dev)

intel core i5 3320M et intel hd graphic 3k

Les évolutions

PJS (javascript next...)

SIMD pour js?

result = pa.mapPar(function(val){return val;});
                       

PJS (javascript next...)

Celui qui me fache

Pour:

• API simple et intégré au JS

Contre:

• Impossible de gérer finement la mémoire
• Reprends tous les problèmes de js et le code optimisé
• Sous la coupe d'intel (avec la meme ressource, on aurait terminé toutes les autres solutions :)

DPS

Quand Opera s'y met...

void   add (Float32Array dst, Float32Array x, double y);               

Pour:

• peu intrusif et s'adapte bien à l'existant

Contre:

• encore une API plutot qu'une solution générique...

A regarder surtout avec la Geometry API qui arrive

Dart

Le non choix...

Pour:

• C'est du java like

Contre:

• c'est du java like...
• demande une nouvelle VM complète, nouveau langage
• Google only

Personnellement, je préfère l'idée de prendre un typeScript

asm.js

function DiagModule(stdlib,foreign,heap) {
   "use asm";
    var sqrt = stdlib.Math.sqrt;
    function square(x) {
        x = +x;
        return +(x*x);
    }
    function diag(x, y) {
        x = +x;
        y = +y;
        return +sqrt(square(x) + square(y));
    }
    return { diag: diag };
}
                        

asm.js

Le moche qui marche...

Pour:

• équivalent llvm-IR
• fallback sur toute VM javascript classique

Contre:

• pas de SIMD,type ou info avancé etc...
• nécessite un compilateur (emscripten)
• mozilla only
• intéraction avec le JS très lent

Dans la pratique c'est relativement proche de l'idée de pNaCl mais avec du javascript en bytecode