Précisions sur les objets

Bonjour à toutes et à tous,

Je commence à apprendre le C++ pour un projet de soft scientifique.
Je cherche à réaliser une logiciel de SPH. En simplifié, le principe est de créer des billes (qui peuvent représenter un fluide ou un solide) avec des lois d'interactions entre elles. C'est un peu comme si on créait une piscine de billes qui interagissent entre elle (transfert de chaleur,...).
Mon problème est le suivant: j'ai besoin d'un grand nombre de Billes cent milles, un million. à chaque bille est associé une dizaine de variables (position, vitesse, pression,...).
Pour le moment j'ai deux idées pour mettre en place ce programme:
_La première est d'utiliser des énormes matrices (vecteurs de 1 million de variable) avec une bibliothèque adapté. Il me semble que blitz++ est fait pour ca?
_La deuxième est d'utiliser la POO et de créer un objet par particule. Cela me semble très intuitif et plus facile à mettre en place. Mais ce que je n'arrive pas à estimer c'est la place mémoire que prend un objet.

Donc mes questions sont les suivantes:

Savez vous combien de place mémoire en plus prend un million d'objet de 10 attributs par rapport à 10 vecteur de 1 million de variables?
Le nombre de méthode de la classe va il augmenter la taille des objets?

Connaissez vous des bibliothèques susceptibles de m'aider dans mon projet?

Tous les commentaires sont bien venu :D

Amicalement

Nicolas

Citation:

---

Envoyé par Nicolas_T

Savez vous combien de place mémoire en plus prend un million d'objet de 10 attributs par rapport à 10 vecteur de 1 million de variables?
Le nombre de méthode de la classe va il augmenter la taille des objets?

---

Hello,

Object ou pas la taille sera la même.
La taille d'un objet est la somme de la taille de ses attributs, mais l'alignement peut faire grossir la taille de tes objets. Tout comme les vecteurs qui réservent généralement plus de place que nécessaire (pour que les prochains ajouts soient rapide).

10 millions d'attributs (float ou double surement), ça ne consomme que 40/80 Mo, utilise la représentation qui te permette de simplifier les calculs.

Pour ce genre de calculs intensifs, le GPGPU peut être intéressant.
Sur CPU, la vectorisation et le multithreading peuvent te faire gagner énormément en performance.

edit : l'utilisation d'ojet permet d'être sur que les données d'un point soient proche en mémoire, c'est important d'un point de vu performance.

Merci Iradrille pour ta réponse. Je vais donc partir sur l'utilisation des objets qui me permet une plus grande flexibilité.

Citation:

---

Pour ce genre de calculs intensifs, le GPGPU peut être intéressant.

---

J'avais un peu regardé pour la programmation GPGPU il me semble qu'il faut regarder du cotée de CUDA pour cela?

Citation:

---

Sur CPU, la vectorisation et le multithreading peuvent te faire gagner énormément en performance.

---

Pour ce qui est de la vectorisation et du multithreading, il existe des bibliotèques bien?

Bon, fasse à la masse de choses à apprendre, je pense commencer à rédiger mon programme, puis le modifier par la suite.
Si tu connais de bon sites ou bibliothèques sur ces trois sujets, je suis preneur! :)

Nicolas

http://www.ce.jhu.edu/dalrymple/GPUSPH/Home.html

Citation:

---

Envoyé par oodini

http://www.ce.jhu.edu/dalrymple/GPUSPH/Home.html

---

Oui j'avais déjà vu. Mais c'est en partie en Fortran. Je cherche plutôt quelque chose exhaustif pour partir de zéro.

Salut,

De manière générale, tu as largement intérêt à regrouper "tout ce qui va bien ensemble" au sein d'une structure dédiée. Si, pour les besoins de ton programme, tu dois manipuler une variable "truc" et une variable "machin" qui sont "intimement liées" (il y a une relation particulière entre la valeur de "truc" et celle de "machin"), et que tu dois manipuler "un grand nombre" (ou pas si grand que cela d'ailleurs) de valeur pour truc et pour machin, il est beaucoup plus facile pour toi d'avoir une structure qui ressemble à

Code:

---

1 2 3 4

struct MaStructure{ un_type truc; un_autre_type machin; };

---

(note que un_type et un_autre_type peuvent parfaitement être du même type de donnée, ou non, selon tes besoins ;) ) et de gérer une collection d'éléments de type MaStructure que de commencer à gérer une collection de truc d'un coté et de machin de l'autre sous une forme qui pourrait ressembler à

Code:

---

1 2	std::vector<un_type> tousLesTrucs; std::vector<un_autre_type> tousLesMachins;

---

La raison en est simple : lorsque tu utilises la structure, il y a forcément un truc donné qui est associé à un machin donné, alors que tu es toujours susceptible de "faire un bêtise" en essayant de gérer les trucs et les machins séparément : il suffit d'un instant de distraction, et tu oublie d'ajouter (ou de retirer) le machin associé au truc que tu viens de créer (ou de retirer), et toute ta logique s'écroule, parce que test trucs se retrouvent associés à des machins qui ne sont pas cohérents par rapport à la valeur de truc.

Si truc et machin sont des types primitifs, il ne faut pas t'en faire outre mesure de la taille que la structure prendra en mémoire. Au pire, il y aura un effet d'alignement (padding en anglais) qui fera que la taille de ta structure est "quelques bytes" plus grande que ce qu'elle ne doit réellement l'être. Ce padding correspond au maximum au nombre de byte qui séparent deux adresses mémoire accessibles successives -1.

On parle donc, dans le pire des cas, d'un espace correspondant à 7 bytes sur une machine 64 bits, en considérant que chaque adresse mémoire accessible est séparée de la suivante par 8 bytes (estimation qui se vérifie régulièrement sur les architectures de type PC 64 bits, à contrôler sur d'autres architectures ;)) ! Avant que ces 7 bytes "perdus" ne commencent à réellement poser problème, il faudrait avoir à gérer un "très grand nombre" d'éléments ;)

Citation:

---

Savez vous combien de place mémoire en plus prend un million d'objet de 10 attributs par rapport à 10 vecteur de 1 million de variables?

---

Cela dépend de beaucoup de choses.

D'abord, il faut savoir si tu envisage le "vecteur" comme étant de type std::vector<un_type> ou comme étant (quelle horreur!) un tableau géré "à l'ancienne" à coup de new[] et de delete[].

Par exemple, sur ma machine, (un pc de bureau 64 bits, tournant sous linux), la taille d'un std::vector, quelle que soit le type d'éléments qu'il contient, est de 24bytes. Cela correspond à la somme de:

• la taille d'un pointeur utilisé pour l'allocation dynamique de l'espace nécessaire pour représenter l'ensemble des élément (8 bytes sur mon système)
• la taille d'un size_t permettant de connaitre le nombre d'éléments présents dans la collection (8 bytes sur mon système)
• la taille d'un size_t permettant de savoir au delà de combien d'éléments présents dans la collection il faudra prévoir d'augmenter l'espace alloué dynamiquement (8 bytes sur mon système)

On peut donc dire que, si on a 10 std::vector contenant chacun 1 000 000 d'éléments, l'espace mémoire total utilisé sera de 240byte + (10 000 000 * sizeof(element à placer dans le tableau) ).

On pourrait éventuellement partir du principe que la gestion à l'ancienne d'un tableau à coup de new[] et de delete[] ne nécessiterait que la taille d'un pointeur (8bytes sur mon système), et que l'on gagnerait donc la quantité phénoménale de ... 160bytes sur les dix tableaux.

C'est oublier un peu vite que tu devras, de toutes façons, maintenir "quelque part" le nombre d'éléments contenus dans ton tableau ainsi que le nombre d'éléments au delà duquel il faudra envisager d'augmenter la taille de l'espace alloué dynamiquement. Tu te retrouveras donc de toutes façons à gérer "quelque part" un size_t pour le nombre d'élément et un autre pour savoir quand augmenter la taille! Au final, si tu veux faire les choses correctement, tu ne gagnera donc absolument rien :D (ou, au maximum que 146bytes, si tous tes tableaux ont très certainement la même taille et sont tous mis à jour en même temps)

Quant à savoir s'il est plus intéressant d'avoir un tableau de truc et un tableau de machin plutôt qu'un tableau de MaStructure, il faut te dire que l'espace éventuellement perdu au niveau de MaStructure restera malgré tout particulièrement minime (je le répète, on parle de maximum 7bytes par élément, à mettre en relation avec la taille de truc et de machin cumulée ;)).

Au final, le conseil que je te donnerai est "ne te casses pas la tête". Tu auras beaucoup plus facile à travailler avec une structure qui ne prendra de toutes façons pas "beaucoup plus de place" en mémoire que la somme des tailles des informations qu'elle regroupe. Les alternatives sont sujettes à provoquer un maximum d'erreurs qui te pourriront la vie! Uses et abuses donc des structures de données, tu ne t'en sentiras que mieux dans ta peau de développeur ;)

Conseil: n'utilise pas la virtualité pour tes particules (sinon tu vas augmenter l'empreinte mémoire avec des vptr et des vtables).