Discussion :

[teddyalbina]

Bonjour,

Je suis actuellement entrain de travailler sur une application dans le coeur est écrit en C++ (utilisation du concurency runtime, PPL et direct compute). Je voudrais interfacer ce coeur avec des couches plus hauts niveaux en .net (pour la partie WCF etc.) et voudrais savoir si j'aurai une perte de performance en utilisant le design suivant :

Haut niveau en C# / Niveau intermédiaire en C++/CLI / Bas niveau en C++

Je pense que non mais n'ayant jamais mis en place ce genre de solution je sollicite donc vos avis.

Merci

[moldavi]

Bonjour.

J'utilise ce principe mais sans niveau intermédiaire.

L'interface graphique c'est du Winforms/C++ managed, et les dll, du C++ natif.

J'ai une dll qui contient du code DirectShow pour la lecture d'audio/vidéo : pas de problème, les vidéos, même avec des formats gourmands comme le mpeg2, sont fluides.

Une autre dll intègre du code DirectX (objet 3D, shader, texture, etc...). Idem, l'affichage est fluide.

Les graphismes de ces deux dll s'affichent dans un contrôle PictureBox avec une bonne qualité.

Les difficultés :

- pour passer des paramètres à la dll, parfois c'est compliqué. Les types de base (int, float...) ça va, mais pour les autres types c'est souvent galère.

- si la dll plante, souvent le programme .net plante aussi. (Sous seven et avec .net, il y a une méthode pour gérer les plug-in, mais pas sous XP).

- j'utilise des dll COM, et elles doivent répondre à des critères bien précis pour ne pas poser de problème avec le programme .net.

- certaines méthodes de .net pour passer des données à une dll d'un objet managé à un objet non managé sont, je trouve, horribles à utiliser. Il faut gérer leur durée de vie et j'ai quelques soucis de corruptions mémoires difficiles à résoudre avec ce type d'objets.

- Et le pire, je n'ai toujours pas trouvé le moyen de faire un callback de la dll vers le programme .net... parce que passer un pointeur de fonction managé à la dll, faut s'accrocher...

En conclusion :

Le code natif intégré à un programme .net s'exécute avec les mêmes performances que s'il s'exécutait depuis un programme natif.
Si on ne fait que passer des paramètres de base à la dll, tout va bien.
Si on veut compliquer la chose avec des types plus élaborés, du callback, ça se corse très vite, et on passe tout son temps sur MSDN/Google à trouver des solutions.

[teddyalbina]

Ah oui ok mon programme consiste à lire des données stockées dans berkeleydb puis à construire une matrice et enfin y appliquer plusieurs algo le tout bien entendu déporté au niveau de la carte graphique parce que faire ça avec le cpu... on a pas fini

La seule structure que j'ai a passer d'un monde à l'autre est une class assez simple ne contenant aucune logique