System.Numerics.Vector is a library provided by .Net (as a nuget package), which tries to leverage SIMD instruction on target hardware. It exposes a few value types, such as Vector<T>, which are recognized by RyuJIT as intrinsics.
Supported intrinsics are listed in the core-clr github repository.
This allows C# SIMD acceleration, as long as code is modified to use these intrinsic types, instead of scalar floating point elements.

On the other hand, Hybridizer aims to provide those benefits without being intrusive in the code (only metadata is required).

We naturally wanted to test if System.Numerics.Vector delivers good performance, compared to Hybridizer.

We wrote and ran two benchmarks, and for each of them we have four versions:

• Simple C# scalar code
• Numerics.Vector
• Simple C# scalar code, hybridized
• Numerics.Vector, hybridized

Processor is a core i7-4770S @ 3.1GHz (max measured turbo in AVX mode being 3.5GHz). Peak flops is 224 GFlop/s, or 112 GCFlop/s, if we count FMA as one (since our processor supports it).

Compute bound benchmark

This is a compute-intensive benchmark. For each element of a large double precision array (8 millions elements: 67MBytes), we iterate twelve times the computation of an exponential’s Taylor expansion (expm1). This is largely enough to enter the compute-bound world, by hiding memory operations latency behind a full bunch of floatin point operations.
Scalar code is simply:

 [MethodImpl(MethodImplOptions.AggressiveInlining)]
 public static double expm1(double x)
 {
   return ((((((((((((((15.0 + x)
     * x + 210.0)
     * x + 2730.0)
     * x + 32760.0)
     * x + 360360.0)
     * x + 3603600.0)
     * x + 32432400.0)
     * x + 259459200.0)
     * x + 1816214400.0)
     * x + 10897286400.0)
     * x + 54486432000.0)
     * x + 217945728000.0)
     * x + 653837184000.0)
     * x + 1307674368000.0)
     * x * 7.6471637318198164759011319857881e-13;
 }
 [MethodImpl(MethodImplOptions.AggressiveInlining)]
 public static double twelve(double x)
 {
   return expm1(expm1(expm1(expm1(expm1(expm1(expm1(expm1(expm1(expm1(expm1(x)))))))))));
 } 

on which we added the AggressiveInlining attribute to help RyuJit to merge operations at JIT time.

The Numerics.Vector version of the code is quite the same:

 [MethodImpl(MethodImplOptions.AggressiveInlining)]
 public static Vector<double> expm1(Vector<double> x)
 {
   return ((((((((((((((new Vector<double>(15.0) + x)
     * x + new Vector<double>(210.0))
     * x + new Vector<double>(2730.0))
     * x + new Vector<double>(32760.0))
     * x + new Vector<double>(360360.0))
     * x + new Vector<double>(3603600.0))
     * x + new Vector<double>(32432400.0))
     * x + new Vector<double>(259459200.0))
     * x + new Vector<double>(1816214400.0))
     * x + new Vector<double>(10897286400.0))
     * x + new Vector<double>(54486432000.0))
     * x + new Vector<double>(217945728000.0))
     * x + new Vector<double>(653837184000.0))
     * x + new Vector<double>(1307674368000.0))
     * x * new Vector<double>(7.6471637318198164759011319857881e-13);
} 

The four versions of this code give the following performance results:

As stated, Numerics.Vector delivers a close to 4x speedup from scalar. However, performance is far from what we reach with the Hybridizer. If we look at generated assembly, it’s quite clear why:

 vbroadcastsd ymm0,mmword ptr [7FF7C2255B48h]
 vbroadcastsd ymm1,mmword ptr [7FF7C2255B50h]
 vbroadcastsd ymm2,mmword ptr [7FF7C2255B58h]
 vbroadcastsd ymm3,mmword ptr [7FF7C2255B60h]
 vbroadcastsd ymm4,mmword ptr [7FF7C2255B68h]
 vbroadcastsd ymm5,mmword ptr [7FF7C2255B70h]
 vbroadcastsd ymm7,mmword ptr [7FF7C2255B78h]
 vbroadcastsd ymm8,mmword ptr [7FF7C2255B80h]
 vaddpd ymm0,ymm0,ymm6 
 vmulpd ymm0,ymm0,ymm6
 vaddpd ymm0,ymm0,ymm1
 vmulpd ymm0,ymm0,ymm6
 vaddpd ymm0,ymm0,ymm2
 vmulpd ymm0,ymm0,ymm6
 vaddpd ymm0,ymm0,ymm3
 vmulpd ymm0,ymm0,ymm6
 vaddpd ymm0,ymm0,ymm4
 vmulpd ymm0,ymm0,ymm6
 vaddpd ymm0,ymm0,ymm5
 vmulpd ymm0,ymm0,ymm6
 vaddpd ymm0,ymm0,ymm7
 vmulpd ymm0,ymm0,ymm6
 vaddpd ymm0,ymm0,ymm8
 vmulpd ymm0,ymm0,ymm6
 ; repeated 

Fused multiply add are not reconstructed, and constant operands are reloaded from constant pool at each expm1 invokation. This leads to high registry pressure (for constants), where memory operands could save some.

Here is what the Hybridizer generates from scalar code:

 vaddpd ymm1,ymm0,ymmword ptr []
 vfmadd213pd ymm1,ymm0,ymmword ptr []
 vfmadd213pd ymm1,ymm0,ymmword ptr []
 vfmadd213pd ymm1,ymm0,ymmword ptr []
 vfmadd213pd ymm1,ymm0,ymmword ptr []
 vfmadd213pd ymm1,ymm0,ymmword ptr []
 vfmadd213pd ymm1,ymm0,ymmword ptr []
 vfmadd213pd ymm1,ymm0,ymmword ptr []
 vfmadd213pd ymm1,ymm0,ymmword ptr []
 vfmadd213pd ymm1,ymm0,ymmword ptr []
 vfmadd213pd ymm1,ymm0,ymmword ptr []
 vfmadd213pd ymm1,ymm0,ymmword ptr []
 vfmadd213pd ymm1,ymm0,ymmword ptr []
 vfmadd213pd ymm1,ymm0,ymmword ptr []
 vmulpd ymm0,ymm0,ymm1<br />
 vmulpd ymm0,ymm0,ymmword ptr []
 vmovapd ymmword ptr [rsp+0A20h],ymm0
 ; repeated 

This reconstructs fused multiply-add, and leverages memory operands to save registers.

Why are we not to peak performance (112GCFlops)? That is because Haswell has two pipelines for FMA, and a latency of 5 (see intel intrinsic guide. To reach peak performance, we would need to interleave 2 independant FMA instruction at each cycle. This could be done by reordering instructions, since reorder buffer is not long enough to execute instructions too far in the pipeline. LLVM, our backend compiler, is not capable of such reordering. To get better performance, we unfortunately have to write assembly by hand (which is not exactly what a C# programmer expects to do in the morning).

Invoke transcendentals

In this second benchmark, we need to compute the exponential of all the components of a vector. To do that, we invoke Math.Exp.
Scalar code is:

 [EntryPoint]
 public static void Apply_scal(double[] d, double[] a, double[] b, double[] c, int start, int stop)
 {
   int sstart = start + threadIdx.x + blockDim.x * blockIdx.x;
   int step = blockDim.x * gridDim.x;
   for (int i = sstart; i < stop; i += step)
   {
     d[i] = a[i] * Math.Exp(b[i]) * Math.Exp(c[i]);
   }
 } 

This function is later called in a Parallel.For construct.

However, Numerics.Vector does not provide a vectorized exponential function. Therefore, we have to write our own:

 [IntrinsicFunction("hybridizer::exp")]
 [MethodImpl(MethodImplOptions.AggressiveInlining)]
 public static Vector<double> Exp(Vector<double> x)
 {
   double[] tmp = new double[Vector<double>.Count];
   for(int k = 0; k < Vector<double>.Count; ++k)
   {
     tmp[k] = Math.Exp(x[k]);
   }
   return new Vector<double>(tmp);
 } 

As a glance, we can see the problems: each exponential will first break the AVX context (which cost tens of cycles), and trigger 4 function calls instead of one.

With no surprise, this code performs really badly:

If we look at the generated assembly, it confirms what we suspected (context switched, and ymm register splitting):

 vextractf128 xmm9,ymm6,1
 vextractf128 xmm10,ymm7,1
 vextractf128 xmm11,ymm8,1
 call 00007FF8127C6B80 // exp
 vinsertf128 ymm8,ymm8,xmm11,1
 vinsertf128 ymm7,ymm7,xmm10,1
 vinsertf128 ymm6,ymm6,xmm9,1 

Branching

Branch are expressed using if or ternary operators in scalar code. However, those are not available in Numerics.Vector, since the code is manually vectorized.
Branches must be expressed using ConditionalSelect, which leads to code:

 public static Vector<double> func(Vector<double> x)
 {
   Vector<long> mask = Vector.GreaterThan(x, one);
   Vector<double> result = Vector.ConditionalSelect(mask, x, one);
   return result;
 } 

As we can see, expressing conditions with Numerics.Vector is not intuitive, intrusive, and bug prone. It’s actually the same as writing AVX compiler intrinsics in C++. On the other hand, Hybridizer supports conditions, which allow you to write the above code this way:

 [Kernel]
 public static double func(double x)
 {
   if (x > 1.0)
     return x;
   return 1.0;
 } 

Conclusion

Numerics.Vector gives easily reasonable performances on simple code (no branches, no function calls). Speed-up is what we expect (vector unit width) on simple code. However, it’s time-consuming and error-prone to express conditions, and performance is completely broken as soon as some Jitter Intrinsic is missing (such as exponential).

The post From C# to SIMD : Numerics.Vector and Hybridizer first appeared on In Fine - Le Blog.

Dans son produit, Microsoft propose une utilisation sous la forme d’un cluster d’hôtes permettant ainsi une montée en charge facile d’installation. Parmi les fonctionnalités proposées :

• Support d’un nombre de serveurs allant de 2 à plus d’une centaine
• Redimensionnement dynamique du cluster (ajout/suppression de noeuds) sans interruption de service
• Load-balancing automatique : le service distribue de manière autonome les travaux aux différents noeuds du cluster
• Haute disponibilité : les données sont répliquées sur les hôtes du cluster
• Intégration des sessions ASP.NET

L’API permettant la consommation du cache AppFabric se veut extrêmement épurée. Il en résulte une prise en main rapide et une mise en place peu coûteuse en temps.

Enfin, le serveur ainsi que l’API client sont disponibles gratuitement au téléchargement. Vous pouvez suivre les liens présents dans la suite de l’article.

Installation

Serveur

Pour commencer, il faudra télécharger l’installer disponible sur le site de téléchargement de Microsoft à cette adresse : http://www.microsoft.com/fr-fr/download/details.aspx?id=27115

L’installer fait environ 30 Mo, et la version utilisé dans cet article est la 1.1.0.0

Voici le premier écran d’installation :

Passez les étapes et effectuez une installation complète, afin d’éviter de devoir relancer l’installer dans le futur.

Une fois installé, l’outil de configuration de AppFabric Server se lance. Passez les étapes jusqu’à cet écran:

Sans oublier de configurer la base de données en cliquant sur le bouton “Configure”. Veillez à ne pas donner un nom de base de données déjà existant, l’outil se charge de la créer et de la remplir.

Notez également qu’il vous est offert la possibilité de sauvegarder la configuration du serveur dans un fichier XML,  selon vos préférences.

Laissez les pots de communication par défaut, sauf nécessité réseau particulière.

Une fois l’installation terminée, vous pourrez constater la présence de 3 nouveaux services Windows dans le gestionnaire de services :

Ainsi qu’une nouvelle section dans le IIS Manager permettant de monitorer le serveur AppFabric:

Outil d’administration du cache

Il n’y a pas d’outil d’administration fourni avec le serveur, mais vous pouvez télécharger par exemple AppFabric Caching Admin Tool (http://mdcadmintool.codeplex.com/).

L’outil est à copier dans un dossier, il suffit de lancer le .exe :

Une fois l’outil lancé, sur notre serveur AppFabric nouvellement installé, vous pourrez constater la présence de l’hôte principal (sur la machine locale) ainsi que la liste des caches qu’il contient :

Nous allons créer un cache autre que celui créé par défaut pour les besoins des exemples d’utilisation du cache qui vont suivre.

Notez bien que j’ai volontairement activé les notifications, afin de pouvoir utiliser ce mécanisme dans la dernière démonstration.

Créez également 2 régions dans ce cache : “RegionA” (sans eviction) et “RegionB” (avec éviction). Nous reviendrons plus tard sur ce paramètre.

Si vous rencontrez des difficultés lors de la création de nouveaux caches ou bien de régions, vérifiez que le service “Remote Registry” sur votre machine (celle où se trouve le serveur AppFabric) est lancé.

Définissons désormais les droits d’accès au cache pour l’utilisateur qui consommera ce dernier. Pour ce faire, cliquez sur le noeud racine “Cluster : AppFabric” puis sur le bouton “Security” en haut à droite. Dans la fenêtre de saisie, entrez le nom de l’utilisateur sous la forme : “DOMAIN\user”, c’est tout.

Client

La plus simple façon d’installer les assemblies client pour AppFabric est de passer par le gestionnaire de packages NuGet. Si vous ne l’avez pas installé, c’est simple :

Dans la capture d’écran ci-dessus, NuGet est déjà installé, le cas contraire un bouton “Install” est disponible.

Une fois cet outil installé, il suffit de taper dans la console NuGet la ligne de commande d’installation du client AppFabric (http://nuget.org/packages/ServerAppFabric.Client) :

Pour afficher cette console :

Utilisation

Nous allons pour ce faire créer une application Console. Si vous avez utilisé NuGet pour obtenir votre package AppFabric client, les références aux assemblies d’AppFabric sont déjà rajoutées à la solution, dans le cas contraire, ajoutez manuellement ces dernières, comme sur cet exemple :

Placez ensuite un fichier App.config à la racine du projet contenant au minimum ceci :

<?xml version="1.0"?>
<configuration>
  <configSections>
    <section
        name="dataCacheClient"
        type="Microsoft.ApplicationServer.Caching.DataCacheClientSection, Microsoft.ApplicationServer.Caching.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
        allowLocation="true"
        allowDefinition="Everywhere" />
  </configSections>
  <dataCacheClient>
    <hosts>
      <host name="localhost" cachePort="22233"/>
    </hosts>
    <clientNotification pollInterval="1" />
  </dataCacheClient>
  <startup><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/></startup>
</configuration>

Remplacez bien entendu “localhost” par le nom d’hôte qui correspond à votre installation et le port par celui que vous avez configuré (22233 est le port par défaut). J’ai également défini le “pollInterval” (délai entre deux notifications) à 1 seconde au lieu de 300s par défaut. Attention ici il s’agit bien ici de secondes et non de millisecondes.

Premiers pas

L’exemple ci-dessous illustre la durée de rétention du cache appliquée aux objets stockés :

static void TestBasicExpiration()
{
    var factory = new DataCacheFactory();
    var cache = factory.GetDefaultCache();

    cache.Put("obj", new object(), TimeSpan.FromSeconds(5));

    var timer = new Timer(new TimerCallback(o =>
    {
        Console.WriteLine("obj : {0}", cache.Get("obj"));
    }), null, 0, 1000);
}

La sortie console est la suivante :

Une fois passées les 5 secondes définies comme durée de persistance pour l’objet portant la clé “obj”, ce dernier est détruit et l’appel la clé “obj” ne renvoie plus rien.

Les deux ligne suivantes peuvent être isolées afin de ne pas avoir à redemander ces informations statiques à chaque requête d’objets du cache :

var factory = new DataCacheFactory();
var cache = factory.GetDefaultCache();

GetDefaultCache renvoie, comme son nom l’indique, le cache par défaut de l’hôte AppFabric. Pour accéder à un cache nommé, il suffit de remplacer cet appel par GetCache(“InfineCache”) par exemple.

Utilisation des régions

Il est possible de stocker des objets dans le cache sous différentes régions :

static void TestRegion()
{
    var factory = new DataCacheFactory();
    var cache = factory.GetCache("InfineGroup");

    cache.Put("int", 5);
    cache.Put("int", 6, "RegionA");
    cache.Put("int", 7, "RegionB");

    Console.WriteLine("int(no region) : {0}", cache.Get("int"));
    Console.WriteLine("int(RegionA) : {0}", cache.Get("int", "RegionA"));
    Console.WriteLine("int(RegionB) : {0}", cache.Get("int", "RegionB"));
}

Les notifications

Le système de notification de AppFabric est basé sur l’attachement d’un delegate à un ensemble de filtres d’opérations. Il est possible de s’attacher au cache, à une région du cache ou bien à une clé d’objet précise.

Voici l’exemple :

static void CacheUpdated(string cacheName, string region, string key,
DataCacheItemVersion version, DataCacheOperations operation,
DataCacheNotificationDescriptor descriptor)
{
    //display some of the delegate parameters
    Console.WriteLine("A cache-level notification was triggered!");
    Console.WriteLine("    Cache: " + cacheName);
    Console.WriteLine("    Region: " + region);
    Console.WriteLine("    Key: " + key);
    Console.WriteLine("    Operation: " + operation);
    Console.WriteLine("======================================================");
}

static void TestNotifications()
{
    var factory = new DataCacheFactory();
    var cache = factory.GetCache("InfineGroup");

    var rnd = new Random();
    cache.Put("int", rnd.Next());

    var allCacheOperations = DataCacheOperations.AddItem | DataCacheOperations.ReplaceItem |
        DataCacheOperations.RemoveItem | DataCacheOperations.CreateRegion |
        DataCacheOperations.ClearRegion | DataCacheOperations.RemoveRegion;

    cache.AddCacheLevelCallback(allCacheOperations,
            new DataCacheNotificationCallback(CacheUpdated));

    cache.Remove("int");
    cache.Put("int", rnd.Next());
    cache.Put("int", rnd.Next());
}

Et la sortie résultante :

Opérations Bulk

Les opérations de type “Bulk” dans AppFabric se limitent à la lecture, il n’y a pour le moment aucun moyen d’effectuer des écritures de masse dans le cache.

La lecture se fait grâce à l’instruction BulkGet de l’objet DataCache :

static void TestBulkGet()
{
    var factory = new DataCacheFactory();
    var cache = factory.GetCache("InfineGroup");

    cache.CreateRegion("Desk");

    var rnd = new Random();
    for (var i = 0; i < 1000; i++)
    {
        cache.Put("int-" + i, rnd.Next(), "Desk");
    }

    var gets = cache.BulkGet(new[] { "int-6", "int-14", "int-578", "int-988" }, "Desk");
    foreach (var value in gets)
    {
        Console.WriteLine("{0} = {1}", value.Key, value.Value);
    }
}

Résultat :

Lock / Unlock

Il est possible de vérouiller une donnée du cache pour une durée spécifique au moment où on la récupère via l’instruction GetAndLock de l’objet DataCache . Attention cependant, un appel Put sur la clé de l’objet réinitialisera le verrou. De même, un appel à Get ne générera pas d’exception, car ce dernier ne demande pas d’autorisation sur la clé comme le fait GetAndLock.

L’utilisation de GetAndLock combiné avec PutAndUnlock peut s’apparenter à l’utilisation de verrou dans un système multithreading, à la différence que les verrous persistent sur le cache distribué et non sur la machine exécutant le code. Les verrous sont donc communs à tous les utilisateurs du cache.

Illustration :

static void TestLock()
{
    var factory = new DataCacheFactory();
    var cache = factory.GetCache("InfineGroup");

    cache.Put("int", 5);

    DataCacheLockHandle lockHandle;
    var value = cache.GetAndLock("int", TimeSpan.FromSeconds(5), out lockHandle);
    Console.WriteLine("GetAndLock: int = {0}", value);

    try
    {
        value = cache.GetAndLock("int", TimeSpan.FromSeconds(5), out lockHandle);
        Console.WriteLine("GetAndLock: int = {0}", value);
    }
    catch (DataCacheException ex)
    {
        if (ex.ErrorCode == DataCacheErrorCode.ObjectLocked)
            Console.WriteLine("GetAndLock failed, object already locked.");
        else
            throw ex;
    }

    var timer = new Timer(new TimerCallback(o =>
    {
        Console.WriteLine("GetAndLock(after 6s): int = {0}", cache.GetAndLock("int", TimeSpan.FromSeconds(5), out lockHandle));
    }), null, 6000, Timeout.Infinite);
}

Sortie :

Information sur un objet du cache

La fonction GetCacheItem de la classe DataCache renvoie une instance de DataCacheItem regroupant quelques informations sur l’objet mis en cache.

static void TestCacheItem()
{
    var factory = new DataCacheFactory();
    var cache = factory.GetCache("InfineGroup");

    cache.Put("int", 5, TimeSpan.FromSeconds(15));

    var item = cache.GetCacheItem("int");
    Console.WriteLine("CacheItem informations :");

    foreach (var prop in item.GetType().GetProperties())
    {
        Console.WriteLine("{0} = {1}", prop.Name, prop.GetValue(item, null));
    }
}

Sortie :

Recherche dans le cache

La recherche dans le cache peut se faire grâce aux méthodes GetObjectsByTag, GetObjectsByAllTags, GetObjectsByAnyTag et GetObjectsInRegion.

Exemple :

static void TestSearch()
{
    var factory = new DataCacheFactory();
    var cache = factory.GetCache("InfineGroup");

    cache.CreateRegion("Desk");
    var rnd = new Random();

    for (var i = 0; i < 1000; i++)
    {
        var tagParite = new DataCacheTag(i % 2 == 0 ? "Paire" : "Impaire");
        var tagRandom = new DataCacheTag(rnd.Next(100).ToString());

        cache.Put("int-" + i, i, new[] { tagParite, tagRandom }, "Desk");
    }

    foreach (var pair in cache.GetObjectsByTag(new DataCacheTag("67"), "Desk"))
    {
        var item = cache.GetCacheItem(pair.Key, "Desk");
        Console.WriteLine("{0} : {1} [Tag: {2}]", pair.Key, pair.Value, string.Join(",", item.Tags));
    }
}

Sortie :

Ressources

Examples C# : AppFabricTests.zip

Liens MSDN :

• Developing a Cache Client
• Managing Security

The post Prise en main du cache distribué Microsoft AppFabric first appeared on In Fine - Le Blog.

Initialement dénommé “Project Natal”, le Kinect possède désormais une place d’honneur dans le World Guiness Book comme étant l'”accessoire High-Tech le plus vendu dans un court laps de temps” (dixit. World Guiness Book). Initialement conçu pour la console de Microsoft, la Xbox 360, le Kinect s’est voulu être une nouvelle façon de jouer aux jeux vidéos sans manettes appelé également Motion Gaming. Il a rapidement réussi à attiser la sympathie du public avec son concept de commande à la fois ludique et innovante et offrant alors de nouvelles possibilités en terme d’intéractions. Disposant de deux caméras, un capteur de champ par infra-rouge et d’un microphone, le Kinect fonctionne par reconnaissance spatiale d’un corps en mouvement.

Mais les curieux n’avaient pas attendu cette sortie pour mettre au point un pilote compatible Windows pour faire leurs premiers essais. C’est ainsi que le kit CL-NUI Platform a sévi sur internet et proposait déjà de prendre le contrôle sur les capteurs vidéos de l’appareil. On a pu voir apparaître quelques démos techniques (des exemples sur http://kinecthacks.net/) prenant en compte la détection de mouvements qui laisse présager d’autres innovations dans la conception d’interfaces interractives différentes du mythique combo clavier/souris ou plus récemment écran tactile : robotique, réalité augmenté, … Minority Report, ça vous rappelle des souvenirs ?

Prérequis:
Matériel

• Dispositif Kinect pour Xbox 360
• PC avec processeur dual-core, 2.66-GHz ou plus
• Windows 7–carte graphique compatible DirectX® 9.0c
• 2-Go RAM (4-Go RAM recommandé)

Logiciel

• Windows 7 (x86 ou x64)
• Visual Studio 2010 Express (ou autre édition 2010)
• Microsoft .NET Framework 4.0

Et pour bien commencer…

En C#

Avec votre Visual Studio préféré, ajouter la référence “Microsoft.Research.Kinect” depuis la GAC (Global Assembly Cache) et appeler l’assembly dans vos codes projets.

Pour l’API NUI
using Microsoft.Research.Kinect.Nui

Pour l’API Audio
using Microsoft.Research.Kinect.Audio

En C++

• Ne pas compiler vos projets C++ avec w_char comme type de séparateur.
• Pour utiliser l’API NUI, faire un include de MSR_NuiApi.h.
  Localisation : Program Files\Microsoft Research KinectSDK\inc
• Pour utiliser l’API Kinect Audio, faire un include de MSRKinectAudio.h.
  Localisation : Program Files\Microsoft Research KinectSDK\inc
• Faire le lien vers MSRKinectNUI.lib.
  Localisation :  Program Files\Microsoft Research KinectSDK\lib
• Enfin, s’assurer que les dlls du SDK de Kinect sont présents dans le bon répertoire lors de l’exécution du projet.
  Localisation: Program Files\Microsoft Research KinectSD

Pour plus de détails, je vous recommande de lire la documentation fournie avec le kit de développement (disponible ici) ainsi que de vous appuyer sur les différentes applications démos présentes dans le répertoire “Mes documents\Microsoft Research KinectSDK Samples”.

Have fun

Télécharger le SDK Kinect for Windows

The post Kinect for Windows SDK: Released! first appeared on In Fine - Le Blog.

Après une première partie qui s’est concentrée sur l’organisation d’un projet WPF/Silverlight, attaquons-nous à quelque chose de plus compliqué avec les techniques avancées…

Silverlight et WPF en entreprise : retours d’expérience, bonnes pratiques et techniques avancées par Luc Vo Van (Microsoft Services) et Thomas Lebrun (Access-IT)

Architecture type

WPF et Silverlight nous offrent la possibilité de développer des applications composites. Le pattern Models-Views-ViewModels dit MVVM est favorisé.

Principes fondamentaux

Composition

Développer une application par composition c’est créer une coquille vide à laquelle vient se greffer différents modules applicatifs  indépendants qui interagissent ensemble pour les besoins de notre application. Le principal intérêt de ce type d’application est qu’il est possible de paralléliser les développements. En effet, puisque chaque module est indépendant, il est simple de regrouper les équipes en unités fonctionnelles. Ces unités fournissent alors aux autres équipes l’interface de leur implémentation ce qui permet d’exécuter toute l’application même si le développement d’un module n’est pas totalement finalisé.

Avec ce mécanisme, il est alors très aisé d’activer ou de désactiver une fonctionnalité. La maintenabilité de l’application est également largement revue à la hausse grâce au découpage par modules. Chaque module étant cloisonné et hiérarchisé, l’évolution d’un module ne sera visible de l’extérieur qu’à travers son interface. L’impact sur les autres modules est donc fortement limité.

Généralement, on observe deux approches d’architecture de développement par composition

• Régions + Services, c’est le cas avec le Framework Prism
• Services

Inversion of control

Plus communément appelé Ioc, l’Inversion of Control est un pattern utilisé pour l’injection de dépendance. On l’appelle  également parfois injection de code car en favorisant un découplage fort entre l’interface (UI) et l’implémentation (UI logic), il facilite la substitution des composants par des mocks lorsqu’un module n’est pas encore disponible.

Diverses implémentations sont possibles via Unity, Spring .NET, Ninject…

Commanding

Le système de commande est un mécanisme qui permet l’exécution d’actions déclenchées par des contrôles de l’IHM. Par exemple, sur un contrôle de type Button, habituellement, les actions qui suivent le clic sur celui-ci sont codés dans l’événement Click du code behind. Avec le système de commande, on écrit les actions dans la commande et il suffit alors de préciser au bouton le nom de cette commande à exécuter.

Ce mécanisme permet donc de découpler la source de l’action car les actions ne dépendent plus de l’événement Click. Il y a donc peu d’adhérence à l’interface graphique. Autre point fort, une commande peut également être affectée à plusieurs contrôles à la fois.

L’objectif du système de commande est de découpler l’interface graphique du code appelé lors de l’exécution d’une action. Un événement CanExecute intervient dans la définition d’une règle d’activation de la commande. Cette règle, lorsqu’elle est satisfaite active alors les contrôles de l’IHM affectés par cette commande.

Exemple :

//Création de la commande MyCommand
public static RoutedUICommand MyCommand { get; set; }

//Execute : Actions de la commande
private void ShowMessage_Executed(object sender, ExecutedRoutedEventArgs e)
{
MessageBox.Show(“Hello world”);
}

//CanExecute : Condition d’activation de la commande
private void ShowMessage_CanExecute(object sender, CanExecuteRoutedEventArgs e)
{
if(condition)
e.CanExecute = true;
}

//Dans le construteur, on enregistre les événements Executed et CanExecute
CommandBinding myBinding = new CommandBinding(MyCommand);
myBinding.CanExecute += ShowMessage_CanExecute;
myBinding.Executed += ShowMessage_Executed;
CommandBindings.Add(myBinding);

MVVM :

<!-- Après avoir inscrit la commande MyCommand au ViewModel et enregistré dans le ViewModel dans le DataContext de la View, on affecte la commande par Binding-->
<Button x:Name="MyButton" Command="{Binding MyCommand}" />

Non MVVM :

//Dans le constructeur, on affecte au bouton MyButton la commande MyCommand
myButton.Command = MyCommand;

Messaging

Par messaging, on entend l’implémentation d’un mécanisme permettant le dialogue entre les modules. Ce mécanisme, appelé Messenger, doit permettre aux modules de publier un événement et de notifier le ou les modules qui y sont abonnés. On parle alors de communication inter-ViewModels. Il est également possible de notifier un service du Shell par cette méthode pour par exemple faire appel au log, etc…

On distingue généralement les différents types d’implémentations suivantes :

• Event agregattor (Framework Prism)
• Messenger
• Queue

Services du Shell

Les services du Shell regroupent tous les composants qui permettent aux Views, Viewmodels et Controls de communiquer avec l’hôte. Ce sont les services transverses  tels que les Popups Messages, Ribbon Menu, Logging, Workspaces, etc …, et qui peuvent être utilisés à tout instant.

Approches par patterns:

Avec le pattern MVVM, nous avons vu qu’il existe une séparation forte entre le View et le ViewModel. Cette séparation permet 2 approches :

• ViewModelFirst : Dans cette configuration, le ViewModel s’occupe de créer les différents Views et de définir les bindings associés.
• ViewFirst : Dans cette configuration, la View utilise le ViewModel comme ressource. Le binding est alors défini dans la vue. Ce pattern est celui qui est utilisé par le Framework Prism.

Pour des applications implémentant des formulaires, l’utilisation du ViewState permet de définir l’état d’un formulaire avec des changements d’états plus simples et plus légers. En effet, il suffit de ne créer qu’une seule View qui contient alors les différents états du formulaire. Introduit par Silverlight et désormais présent dans WPF 4.0, le ViewState ajoute également des animations de transitions issues du Blend SDK à travers l’utilisation de behaviours.

Parfois, il arrive qu’on ait besoin de créer une fonctionnalité supplémentaire pour un contrôle existant. Dans ce cas de figure, nous utilisons alors les Attached Property qui permettent d’étendre un contrôle existant avec notre fonctionnalité, sans avoir à procéder à un héritage.

Blend SDK:

Ce SDK fournit entre autre des behaviours qui permettent de greffer des  fonctionnalités sur des contrôles pour avoir des comportements supplémentaires.

• InvokeCommandAction : Permet de lier un événement à une commande sans envoyer de paramètre.
• DataStateBehaviour : Sélectionne un VisualState en fonction d’une propriété
• CallMethodAction : Permet à un événement d’exécuter une méthode.

Pour utiliser ces behaviours, il faut au préalable charger l’assembly System.Window.Interactivity (2 dlls). Il est également possible d’écrire ses propres extensions.

Testing

Le pattern MVVM d’une manière générale est le pattern de prédilection pour mettre en place des tests unitaires automatisés pour les applications WPF et Silverlight. Nous avons vu auparavant que la mise en place d’un pattern d’IoC facilitait l’écriture de Mocks. Et bien, c’est avec cette même facilité qu’on pourra également mettre en place une série de tests automatisés car l’UI et l’UI logic sont complètement décorrélés dans cette architecture.

Pour réaliser vos tests selon le type d’application :

Liens externes

MVVM : Framework Prism, Microsoft Enterprise Library

Inversion of Control : Unity, Framework Spring .NET, Ninject

Behaviour : Blend SDK

Testing : Silverlight Toolkit (Silverlight Unit Test Framework)

The post WPF & Silverlight : L’état de l’art au Microsoft TechDays 2011 (partie 2) first appeared on In Fine - Le Blog.

A travers une série d’articles, nous ferons le point sur les principales conférences autour de WPF & Silverlight…

Changer la vie de vos utilisateurs en intégrant du design et de l’ergonomie par Olivier Courtois (Bewise)

De nos jours, nous avons affaire à des “superutilisateurs” qui ont des attentes surdéveloppées. Bien plus que par le passé, les applications doivent se soucier davantage du confort d’utilisation : on parle alors d’ergonomie. Pour pallier à des surcoûts postproduction, cette réflexion doit être posée en amont.

Le travail général de l’ergonomie s’effectue dans le cadre d’une réflexion centrée autour de l’utilisateur. Cette réflexion, auprès d’utilisateurs réels -dans le meilleur des cas- ou auprès d’utilisateurs fictifs, donne naissance aux exigences ergonomiques.

Avec la technologie SilverLight/WPF, la chaîne de travail est occupée autour de 4 postes d’exécutions clés :

• Ergonomie
• Graphisme
• Intégration graphique
• Développement

Nous allons ici nous intéresser plus particulièrement aux 3 premières étapes de cette chaîne.

Ergonomie

L’ergonomie c’est l’art de faire s’adapter l’outil à l’homme à travers une interface. Le rôle de cette étape est de constituer le document de spécification ergonomique.

Le travail sur l’ergonomie est constitué des phases d’exécutions suivantes :

1)      Recueil du besoin : on itère auprès des utilisateurs pour déterminer le fonctionnement général de l’application

2)      Etude de l’existant (s’il existe !)

3)      Création de croquis

• Croquis papier : permet d’être plus créatif
• Application d’UI Design Pattern

4)      Proposition statique

• Croquis numérique : toujours à l’état de croquis, cette étape permet d’être clair lors de la confrontation avec les utilisateurs.

5)      Proposition dynamique

• Maquette dynamique : avec la mise en place d’interactions dans les croquis numériques, les utilisateurs perçoivent de manière plus évidente le fonctionnement que pourrait donner l’ergonomie de l’application.
• Permet de tester auprès des utilisateurs
• Permet de valider l’ergonomie

6)      Spécification ergonomique

• Recommandations ergonomiques
• Typologie des utilisateurs
• Croquis des principaux écrans
• Rationalisation des choix

Le travail sur l’ergonomie produit le document de spécification ergonomique, document qui sera par la suite réutilisé au cours de l’intégration graphique.

Graphisme

Le graphisme -ou design d’application- doit à travers son esthétisme communiquer visuellement la même information à tous les utilisateurs tout en prolongeant la marque du client. Au final, le design sublime l’ergonomie. Cette étape doit permettre la production de la charte graphique de l’application.

C’est ici qu’intervient un designer dont la tâche est de construire la charte graphique selon les étapes suivantes :

1)      Recueil du besoin

2)      Maquettage

3)      Définition de la charte graphique de l’application

Intégration graphique

L’intégration graphique consiste à créer les écrans de l’application tout en respectant son ergonomie. Cette étape permet notamment de préparer le travail du développeur. Pour ce faire, l’intégrateur graphique doit avoir à sa disposition à la fois le document de spécification ergonomique qui identifie les contrôles visuels et la charte graphique qui définit le style visuel appliqué aux contrôles.

1)      Recueil du besoin

2)      Création des squelettes d’écrans

3)      Intégration graphique

A l’issu de ce travail, l’intégrateur graphique met à la disposition des développeurs une bibliothèque de composants stylisés qui doit couvrir tous les besoins de l’application.

Gains Utilisateurs

La prise en compte de l’ergonomie au sein des applications SL/WPF offre bien des apports sur plusieurs aspects. Tout d’abord au niveau de la conduite de projet, on observe une amélioration de la productivité grâce au séquençage des tâches. Avec une meilleure ergonomie, l’application est beaucoup plus intuitive d’un point de vue utilisateur et donc les besoins en formations sont diminués et une meilleure satisfaction d’utilisation de l’application et l’adhérence des utilisateurs. Et d’une manière générale, on observe une diminution du nombre d’erreurs.

Conseil aux développeurs qui veulent se lancer dans l’ergonomie:

• Faire attention au vocabulaire employé
• Ne pas placer ses contrôles n’importe où

The post WPF & Silverlight : L’état de l’art au Microsoft TechDays 2011 (partie 1) first appeared on In Fine - Le Blog.

Détecter les deadlocks en C# / .NET grâce au pattern IDisposable

Si vous êtes développeur en environnement multithread, alors vous vous êtes déjà posé cette question : Où est ce deadlock ? !

Bien sûr, ce deadlock est non-reproductible, il survient chez l’utilisateur, et l’on peut passer des heures à le chercher. Sans jamais être sur d’avoir trouvé LE deadlock qui pose problème !

Vous trouverez dans ce post un exemple de lock qui a pour objectif de

1. Pouvoir détecter les deadlocks
2. Proposer une syntaxe claire et concise
3. Ajouter un overhead minimum en terme de performance à la syntaxe lock C# classique

Petit rappel : qu’est-ce  qu’un deadlock ?

Un deadlock (interblocage dans sa version française que personne n’utilise) est la situation dans laquelle 2 threads s’attendent mutuellement. Cas concret :

1. Un thread T1 acquiert une ressource R1
2. Un thread T2 acquiert une ressource R2
3. T1 demande la ressource R2
4. T2 demande la ressource R1

Avec un schéma :

Exemple de code provoquant un deadlock

void CreateDeadLock()
{
   Object R1 = new object();
   Object R2 = new object();

   Thread T1 = new Thread(delegate() { Work(R1, R2); });
   Thread T2 = new Thread(delegate() { Work(R2, R1); });

   T1.Start();
   T2.Start();
}

void Work(Object acquire, Object demand)
{
   lock (acquire)//T1 take R1 and T2 take R2
   {
      Thread.Sleep(1000);//To ensure that the ressources are taken
      lock (demand)
      {
      }
    }
}

NB : Bien sûr, les situations réelles sont souvent plus compliquées, impliquant par exemple plus de 2 threads ou des locks implicites (écriture dans un fichier…).

Le lock C#

Quand en C# on écrit la syntaxe suivante :

lock (ressource)
{
}

Il se passe en fait à peu près ça :

Object temp = ressource;
Monitor.Enter(temp);
try
{
}
finally
{
   Monitor.Exit(temp);
}

Monitor.Enter acquière le lock, Monitor.Exit le relâche, Le block try-finally est là pour s’assurer que la ressource sera libérée même en cas d’exception. Quant à la référence “temp”, il garantit que c’est bien l’objet acquis qui sera libéré (l’utilisateur ne peut pas la modifier l’objet vers lequel “temp” pointe).

Prévenir les deadlocks avec un Timeout

Le principe pour prévenir les deadlocks implique l’introduction d’un timeout avec un log ou une levée d’exception dans le cas ou le thread échoue à acquérir la ressource demandée.

Voici un exemple de code résolvant le problème.

if (Monitor.TryEnter(ressource, 10000))
{
   try
   {
      //Work
   }
   finally
   {
      Monitor.Exit();
   }
}
else
{
   // Log, stack trace display...
   throw new TimeoutException("Lock acquiring failed");
}

Dans une application avec de nombreux locks, vous conviendrez que cette syntaxe est plus lourde et moins lisible que le lock classique.

Plus grave, elle laisse la possibilité « d’oublier » la libération de la ressource puisque celle-ci incombe au programmeur à chaque utilisation (sisi, ça peut arriver !).

Une solution plus « User-friendly »

L’objectif est de garder le bénéfice du timeout, tout en bénéficiant d’une syntaxe plus concise et claire.

L’idée ici est d’utiliser un Pattern bien connu des programmeurs C++, mais moins des développeurs C# ou JAVA, le principe RAII (Ressource Acquisition Is Initialization).

Le principe RAII

En C++, il y a un moyen simple de s’assurer qu’une ressource sera toujours libérée à la sortie d’une méthode, c’est de l’encapsuler dans un objet créé sur la pile, et de la libérer dans le destructeur de cet objet. En effet, lorsque la méthode se termine (que ce soit par return ou exception), le destructeur de l’objet est appelé et la ressource toujours libérée.

En C# cependant, on ne peut pas appliquer directement cet idiome. En effet :

-L’appel du destructeur d’une classe n’est pas déterministe (il est réalisé par le Garbage Collector)

-Les structures, équivalent C# des objets créé sur la pile en C++, ne peuvent pas avoir de destructeur.

Implémentation du lock par l’utilisation du pattern IDisposable

Pour contourner cette limitation du langage, on peut utiliser le pattern IDisposable.

Voici une première implémentation :

public class LockCookie : IDisposable
{
private const int TIMEOUT = 10000;
private Object _ressource;

public LockCookie(Object ressource)
{
   if (Monitor.TryEnter(ressource, TIMEOUT))
   {
      _ressource = ressource;
   }
   else
   {
      // Log, stack trace display...
      throw new TimeoutException("Lock acquiring failed");
   }
}

public void Dispose()
{
   if (_ressource != null)
   {
      Monitor.Exit(_ressource);
   }
}

}

Et son utilisation :

using (new LockCookie(ressource))
{
   //Work
}

Avec ce pattern, une seule ligne permet d’acquérir la ressource, la libération est systématique à l’accolade fermante (même en cas d’exception) et le traitement en cas d’échec n’est pas dupliqué.

CQFD ? Pas tout à fait. Même si l’on peut se satisfera de cette solution dans la plupart des cas, elle créé un overhead non négligeable : il y a création d’objet à chaque acquisition de la ressource (et qui dit création d’objet dit également plus de travail pour le Garbage Collector !).

Optimisation de la solution

Eliminons tout de suite une première piste : transformer notre classe LockCookie en type struct n’optimise pas la solution. Pourquoi ? Parce qu’à l’accolade fermante du using, la méthode Dispose de l’interface IDisposable est appelée, et appeler une méthode d’interface à partir d’un type struct implique un boxing.

Une autre piste consiste à faire de notre classe LockCookie l’objet même de synchronisation. Voici le code qui en résulte.

public class LockCookie : IDisposable
{
private const int TIMEOUT = 10000;
private bool _ressourceAcquired;

public LockCookie Get()
{
   _ressourceAcquired = Monitor.TryEnter(this, TIMEOUT);
   if (!_ressourceAcquired)
   {
      throw new TimeoutException("Lock acquiring failed");
   }
   return this;
}

public void Dispose()
{
   if (_ressourceAcquired)
   {
      //NB : the 2 next lines must be in is order to prevent _ressourceAcquired
      //to be set to true by Get() then reset by this call to dispose
      _ressourceAcquired = false;
      Monitor.Exit(this);
   }
}

}

Et son utilisation :

//For instance, ressource is a class field : LockCookie _ressource = new LockCookie();
using (_ressource.Get())
{
   //Work
}

L’utilisation est sans doute un peu moins évidente, mais aucun objet n’est créé et la libération de la ressource reste implicite et systématique.

Sur le plan des performances, un lock classique coûte selon mes tests 40 ns (40 milliardièmes de secondes), avec la première solution (avec création d’objet), le coût monte à 50 ns, soit un overhead de 25%, la seconde solution descent à 44 ns, soit un overhead de 10%. Le code des tests de performances sont disponibles en bas de l’article.

Conclusion

Ces 2 solutions apportent une réponse centralisée et efficace aux problèmes liés aux acquisitions de ressources en général et aux deadlocks en particulier. Le coût en terme de performance peut paraître important à certains, mais gardons à l’esprit que le temps d’acquisition d’un lock est souvent négligeable en comparaison du temps ou un thread est effectivement bloqué en l’attente d’une ressource. Je suis par ailleurs curieux de connaître d’éventuelles améliorations ou corrections que vous pourriez apporter.

Code d’analyse de la performance :

void TestPerf()
{
TestPerf(ClassicLock,”ClassicLock”);
TestPerf(LockCookieCreation,”LockCookieCreation”);
TestPerf(LockCookieGet,”LockCookieGet”);
}

public static void ClassicLock(){ lock (_lockObject) { } }
public static void UseLockCookie(){using (new LockCookie(ressource)){ } }
public static void UseLockCookie() { using (ressource.Get()) { } }

public delegate void TestPerfDelegate();
public static void TestPerf(TestPerfDelegate testPerfDelegate, string testName)
{
const long nbIteration = 10000000;//10 millions times
const long nanoSecCoeff = 1000000;//1 ms contains 1 million ns

Stopwatch stopwatch = new Stopwatch();
GC.Collect();//Prevent from garbage collection during loop
stopwatch.Start();
for (int i = 0; i < nbIteration; i++) { testPerfDelegate(); } stopwatch.Stop(); double ellapsedNanoSec = (double)(stopwatch.ElapsedMilliseconds * nanoSecCoeff) / nbIteration; Console.WriteLine(testName.PadRight(50) + ellapsedNanoSec); } } [/sourcecode]

The post Détecter les deadlocks en C# / .NET grâce au pattern IDisposable first appeared on In Fine - Le Blog.