Pointeurs et mémoire

Bonjour,

j'aurai une question sur l'occupation en mémoire d'un tableau.
Voilà, j'ai deux ensembles d'éléments d'une classe A, disons :

Code:

---

1 2 3 4 5

A[] set1 = new A[N] ; A[] set2 = new A[M] ; ... // Tous les éléments sont instanciés, il n'y a aucun null.

---

Chaque élément d'un ensemble pointe sur un très grand nombre (parfois la totalité) des élément de l'autre ensemble. Dans ma classeA, j'ai donc quelque chose du genre :

Code:

---

1 2	List<A> pointeurs = new ArrayList<A>() ;

---

Chaque élément a donc une liste de pointeurs vers les éléments de l'autre ensemble.
Ma question est en fait : étant donné que c'est une liste de pointeurs, qu'elle est l'occupation mémoire (RAM) d'une liste de pointeurs ?
Y a t-il un moyen de le savoir ?

Merci par avance,

Un profiler mesurerait combien de mémoire tu consommes concrètement.

Mais la mémoire utilisée dépend de la JVM utilisée, qui dépend de l'architecture de la machine, bien sûr.

En général 4 ou 8 octets par pointeur. Et une ArrayList peut réserver un pourcentage de plus que les pointeurs vraiment insérés, si on ne lui donne pas des instructions plus précises.

Je rajoute que ça deviens encore plus compliqué à calculer si on a activé la compression des références mémoire dans la JVM :aie:

Merci à tous les deux pour vos réponses !

Citation:

---

Envoyé par thelvin

Mais la mémoire utilisée dépend de la JVM utilisée, qui dépend de l'architecture de la machine, bien sûr.

---

Comme d'habitude :@ J'en ai plus que marre des dépendances à l'architecture !

Citation:

---

Envoyé par thelvin

En général 4 ou 8 octets par pointeur.

---

J'espérais très naïvement que ce soit moins...

Citation:

---

Envoyé par thelvin

Et une ArrayList peut réserver un pourcentage de plus que les pointeurs vraiment insérés, si on ne lui donne pas des instructions plus précises.

---

J'ai pris une ArrayList pour l'exemple, mais je peux utiliser un tableau.

Ca pourrait difficiliement être moins. 32 bits sont nécessaires pour adresser 4G de mémoire. Au delà, on passe en 64 bits (sur les architectures 64 bits).

Si la quantité de référence commence à être ce qui occupe la majorité de ton application, il est peut être temps de revoir la manière dont tu as architecturé tes données :)

En fait je développe un réseau de neurones complet (DNN, CNN, etc.).
J'étais parti sur une architecture très légère afin de minimiser l'utilisation de la RAM et accélérer les calculs. Malheureusement, cela complexifie énormément la partie apprentissage :-(
Donc adieu architecture lite & fast, bonjour simple & fat.

Combien de neurones typiquement? en dessous de 65.000 il doit y avoir moyen de réduire l'espace mémoire consommé en jouant avec des tableaux de short.


Au dela de plusieurs dixaines de millions, c'est la notion même d'objet qui va devenir problématique :) Tu risque de commencer à sérieusement handicaper le GC je pense :mouarf:

En fait, c'est pour définir les connexions/synapses !
Un neurone d'une couche, pointe (normalement) sur certains neurones de la couche précédente.
J'avais au début une architecture dans laquelle je me passais totalement des connexions entre neurones des différentes couches, mais c'était très dur à maintenir pour chaque nouvelle évolution de mon RDN.
En prenant une architecture couche/neurones/synapses, j'ai une architecture plus logique, facile à maintenir, etc., mais qui demande de stocker les connexions.