Manipulation de tableaux & pointeurs (C++ ?)

Hello,

Je dois travailler dans le cadre d'une prestation sur un projet de bibliothèque manipulant des NURBS. Le client aimerait que cela soit fait en C#, parce qu'ils utilisent ce langage en interne.

Mais je dois travailler avec des fichiers d'entrée ASCII qui expriment différemment sous formes d'énormes tableaux les données géométriques. Je dois donc réorganiser ces données, mais je me demande si C# est très efficace pour ce genre de travail. EN C++, j'aurais fort probablement utilisé de l'arithmétique de pointeurs.

En outre, les bibliothèques 3D sont en général en C++, et je me dis que C# n'est peut-être pas la meilleure solution pour travailler sur ces domaines. Qu'en pensez-vous ?

En C# c'est tout a fait possible de travailler avec des pointeurs mais ce n'est cependant utilisé que dans des cas très rare.
Que dois tu faire exactement qui ne te semble pas faisable sans pointeur?

Citation:

---

Envoyé par oodini

des NURBS

---

:koi:

C'est quoi et ça mange quoi l'hiver ces bêtes là ?

Citation:

---

Envoyé par Nathanael Marchand

En C# c'est tout a fait possible de travailler avec des pointeurs mais ce n'est cependant utilisé que dans des cas très rare.
Que dois tu faire exactement qui ne te semble pas faisable sans pointeur?

---

C'est tout à fait faisable sans pointeurs.
Mais je crains que cela soit peu efficaces.

J'ai une surface NURBS carrée qui est décrite de deux façons différentes dans deux formats de fichiers.

Dans l'un, les coordonnées XYZ de tous les sommets sont indiquées à la suite; ensuite les dérivées partielles au bord; ensuite les dérivées mixtes aux coins.

Dans l'autre format, il y a les coordonnées de sommet pour une rangée, suivies par les dérivées partielles, suivies par les dérivées mixtes aux coins.

Il faut que j'unifie tout ça dans une seule structure de données. Ça implique de manipuler des tableaux de centaines ou milliers d'éléments. Je ne suis pas sûr que passer par des objets tableau soit le plus efficace...

Citation:

---

Envoyé par Bluedeep

Expert Confirmé Sénior
Chef de projet NTIC

:koi:

C'est quoi et ça mange quoi l'hiver ces bêtes là ?

---

C'est en voyant des seniors poser de telles questions qu'on se rend compte que bien qu'on soit tous codeurs, nos domaines d'expertise peuvent être très différents. :-)

NURBS signifie Non-Uniform Rational B-Spline. C'est une représentation mathématique décrivant une géométrie.

Citation:

---

Envoyé par oodini

NURBS signifie Non-Uniform Rational B-Spline. C'est une représentation mathématique décrivant une géométrie.

---

Merci !

EDIT : et pour ceux qui se sont posés la même question, voici l'article de wikipedia sur la question : http://fr.wikipedia.org/wiki/NURBS

L'explication est très claire.

Citation:

---

Envoyé par oodini

Il faut que j'unifie tout ça dans une seule structure de données. Ça implique de manipuler des tableaux de centaines ou milliers d'éléments. Je ne suis pas sûr que passer par des objets tableau soit le plus efficace...

---

Manipuler des pointeurs en C# risque de ne pas être efficace, car si le langage le permet sous certaines conditions, il n'est pas conçu pour cela. Au final, ton code ne sera certainement pas plus rapide qu'avec des List (au sens large) et beaucoup moins maintenable.

Dans [ame="http://www.amazon.fr/C-NET-G%C3%A9rard-Leblanc/dp/2212110669/ref=sr_1_3?s=books&ie=UTF8&qid=1303999360&sr=1-3"]C # et .NET: Amazon.fr: G?rard Leblanc: Livres@@AMEPARAM@@http://ecx.images-amazon.com/images/I/4165BGEMN6L.@@AMEPARAM@@4165BGEMN6L[/ame], pour illustrer les pointeurs, l'auteur présente une application qui lit/écrit des pixels. En utilisant les pointeurs plutôt que Get/SetPixel, il va des dizaines de fois plus vite...

Citation:

---

Envoyé par oodini

. En utilisant les pointeurs plutôt que Get/SetPixel, il va des dizaines de fois plus vite...

---

Oui, par ce qu'il travaille sur une zone de mémoire non managée.
Mais si tu comptes faire cela, tu dois t'interroger sur la pertinence de l'utilisation de C#

Citation:

---

Envoyé par Bluedeep

Oui, par ce qu'il travaille sur une zone de mémoire non managée.
Mais si tu comptes faire cela, tu dois t'interroger sur la pertinence de l'utilisation de C#

---

Mais je m'interroge fortement !! D'où mon post.
C'est mon client qui veut du C#. Moi, je serais plutôt parti sur du C++ (que je connais bien mieux).

.Net offre-t-il une classe pour mesurer le temps d'un traitement ? Histoire que je puisse argumenter ?

Citation:

---

Envoyé par oodini

.Net offre-t-il une classe pour mesurer le temps d'un traitement ? Histoire que je puisse argumenter ?

---

System.Diagnostics.StopWatch par exemple.

Une remarque : visiblement tu travailles sur un domaine complexe que tu connais bien; en revanche, tu sembles peu connaitre C# (ce qui n'est pas génant) et .Net (ce qui l'est beaucoup, beaucoup plus). Dans ces conditions, partir sur un développement pointu mais avec une plateforme technique mal connue n'est pas forcement idéal.

Tu as tout compris et j'arrive à la même conclusion que toi !! :-)

Des tableaux de centaines OU milliers de pixels ?! Mais c'est rien, ça !
Bon, en C# il s'agirait de tableaux vu que tu ne vas pas écrire tout le code en unsafe, ce serait ridicule. Un tableau en C#, c'est matérialisé côté système par un pointeur qui débute par un champ longueur et dont les accès sont encadrés deux branchements conditionnels afin de vérifier qu'il n'y a pas dépassement de capacité (i < 0 ou i >= *ptr => erreur).

Pour commencer, as-tu une contrainte de performances, genre douze millions de points par seconde ? Si ce n'est pas le cas, qu'il ne s'agit que de lire un fichier de quelques milliers de points une fois de temps à autre, il n'y a aucun problème.

Ensuite, de toute façon les vérifications sur les indices des tableaux ne pèseront pas lourd devant les accès disque et l'interprétation des données textuelles.

Enfin, tu as donc deux types d'accès :
* Séquentiel (données en rangées), tu vas pourvoir exploiter la structure "for(int i = 0; i < array.Length; i++)" qui supprime les vérifications de capacité sur les appels de "array[i]".
* Pseudo-aléatoire: si tes données sont trop volumineuses pour tenir dans le cache (c'est sans doute le cas), alors de toute façon, pour un simple problème d'ordonnacement, il y a de grandes chances que tu sois limité par l'accès aux données plutôt que par leur traitement.

Le problème de perfs viendra en aval, lorsqu'il faudra exploiter les structures de données créées afin de réaliser des calculs intensifs et demandant des accès pseudo-aléatoires. Mais c++ managé ou c#, ça ne fera aucune différence si tes structures de données doivent, elles, êtres managées pour les besoins du client.


PS : Si tu connais mal dotnet, un objet managé a un header caché de 10 octets. Non-négligeable dans ton scénario. Les structures n'ont pas ce problème.

Je n'ai pas de contrainte de performances pour du temps réel. Mais bon, je peux avoir des traitements par lot de conversions de données.

Concernant les accès, c'est du semi-séquentiel. Si j'ai un tableau de 1000 points sur 1000 points, je vais lire la première ligne de 1000 points, rajouter des données dans le tableau, passer à la ligne suivante, etc.

Du fait de sa nature, et de son mode de fonctionnement, le code .NET est aussi rapide que du C++ compilé en terme d'instructions par seconde.

Le seul truc, c'est que le C# prends plus de "précautions" que le C++, d'ou une impression de perte de performances...

Ceci dit, tu peux toujours faire ca :
Tout ce qui concerne la partie traitement pur, calcul, etc... tu l'ecris en C++, et tu en fait une DLL native.
Ensuite, pour tout ce qui ne nécessite pas des performances extraordinaires, tu fais une interface en C# pour manipuler ta dll C++ (a coup de DllImport).
Ce qui pourrai donner librairie .NET, qui utilise du code natif en C++.

Au final, tu aura la liberté de traitement du C++, et tu offrira la manipulation des tes fonctions en C#.

Pour le client il n'y aura aucune différence si tu fais ton traitement+interface en C# ou bien si tu fais le traitement en C++ et que tu offre une interface en C#.

Vu tes arguments, ca me semble la meilleure solution...

C'est judicieux, ça peut être la bonne solution. Mais le coût lors de la communication managé <-> non-managé est quand même important dans certains cas donc il faudra voir la tronche de l'API demandée par le client.

Calling native functions from managed code et Performance considerations for Interop (C++) (compare le PInvoke classique au PInvoke implicite du C++ managé et détailles opérations nécessaires dans chaque cas).

Certe, mais ce cout n'est significatif que si l'on appelle constemment des fonctions avec le P/Invoke.
J'ai plutot compris que de temps en tenps, une fonction déclenche un traitement long et couteux. Dans ce cas, l'impact est nul, ou non significatif.