Allocation, BufferedImage et UnSafe

Bonsoir,

j'aurai quelques question concernant les allocations mémoires en Java.

- Tout d'abord, il me semble que lorsque l'on fait une simple allocation du type "int[] tab = new int[10]" (ou tout autre type primitif), on n'est pas certain que toutes les cases allouées soient contiguës en mémoire. Est ce bien cela ?

- Si j'ai raison, y a t-il un moyen de forcer pour que l'allocation sont contigüe ?

- Il me semble que la classe UnSafe sert justement à avoir la continuité dans les données. Est ce bien cela ?


Merci par avance pour vos précisions.

Citation:

---

Envoyé par ToTo13

- Tout d'abord, il me semble que lorsque l'on fait une simple allocation du type "int[] tab = new int[10]" (ou tout autre type primitif), on n'est pas certain que toutes les cases allouées soient contiguës en mémoire. Est ce bien cela ?

---

1) où à tu lu cela
2) en quoi cela te poserait-il problème.

Citation:

---

- Il me semble que la classe UnSafe sert justement à avoir la continuité dans les données. Est ce bien cela ?

---

Non, la classe unsafe sert à violer à peu près toutes les contraintes du langage. Tu te fera le plus grand bien en oubliant qu'elle existe :aie:

Sans compter que si on se permet d'utiliser sun.misc.Unsafe, alors on doit en principe penser que les tableaux sont contigus : deux méthodes de Unsafe n'auraient aucun sens, sans cela.

Par contre, si on fait int[][] tab = new int[10][10];
Là, en effet, les 100 éléments ne seront pas contigus.
Mais Unsafe ne propose rien de mieux que faire int[] tab = new int[100] à la place.

Citation:

---

Envoyé par tchize_

1) où à tu lu cela

---

Honnêtement je ne me rappelle plus :-(
Par contre MicroSoft avait justement proposé une JVM dont la principale particularité était al continuité en mémoire. Ils avaient perdu le procès contre Sun et avaient laissé tomber.

Citation:

---

Envoyé par tchize_

2) en quoi cela te poserait-il problème.

---

La lenteur chronique grandissante de Java fasse au C me pose de plus en plus de problème. Je voudrai donc faire de l'auto-vectorization dans un coeur C/C++ et l'appeler via SWIG. Mais pour cela j'ai impérativement besoin d'une continuité en mémoire.

Citation:

---

Envoyé par tchize_

Non, la classe unsafe sert à violer à peu près toutes les contraintes du langage. Tu te fera le plus grand bien en oubliant qu'elle existe :aie:

---

J'aime pas les contraintes :vomi: :mur:
J'avais déjà essayé d'utiliser Unsafe pour gagner en vitesse : pas de contrainte => on perd pas de temps. Evidemment il faut faire attention à ce que l'on fait.
Par contre je n'avais pas réussi à l'utiliser efficacement et du coup les gains en temps étaient dérisoires :-(
Bon faut dire aussi que les exemples d'utilisation de la classe ne courent pas les rues et que je pense ne pas l'utiliser de façon optimale :-(

On peut se demander pourquoi tu fais du Java, en fait.
Plus exactement, tu ne fais pas de Java : tu fais du C++ avec un compilateur Java. Tous les inconvénients des deux langages, en ne gardant comme avantage qu'une part de la rapidité d'accès du C.

Personnellement, si je devais traiter des choses qui doivent zapper les sécurité de Java pour raisons de performances, je les ferais intégralement en C, données comprises, et je le rendrais accessible au reste de mon programme Java par JNI.

Mais si tu tiens tellement à t'embarrasser de Unsafe au lieu d'un langage fait pour, à ta guise.
En attendant, bien qu'en théorie, en effet, Java dit que ça ne te concerne pas si un tableau est contigu ou non, en pratique Unsafe lui-même et plusieurs autres choses laissent penser que c'est sûrement le cas, sans quoi ils auraient peu d'intérêt.

Unsafe est, par contre, parfaitement capable de zapper un certain nombre de sécurités qui ralentissent les accès mémoires ou qui ne sont pas commodes. Mais ça a des limites : les accès à Unsafe restent des accès à une méthode, après tout. On ne peut pas accéder plus vite à un tableau avec Unsafe.

Si la JVM ne vérifie pas les débordement à cause de Unsafe, on doit théoriquement accélérer les lectures/écritures.

En fait j'ai voulu passer à un langage Objet et Java était le plus utilisé. J'adore ce langage pour tout ce qu'il apporte et ça simplicité.
Mais par moment, j'aimerai pouvoir aller dans la performance pure et passer au delà de toutes ces vérifications et autres contraintes limitantes.

Pour le traitement d'image, Java me pose un autre problème vraiment handicapant en terme de performance, c'est l'absence des unsigned, ce qui fait que je dois utiliser en permanence du "& 0xFF" ou du "& 0xFFFF" pour avoir les bonnes valeurs.
Sans compter que les optimisation SSE2 sont super mal faites dans la JVM et l'auto-vectorisation n'est pas gérée.

Si tu es à l'aise avec C/C++, pourquoi ne pas faire les operations critiques avec et n'utiliser java que pour exploiter le resultat ? Parce que la lecture du fil laisse penser que tu vas faire un truc entre 2 ou tu auras les inconvenients des 2 cotés : Pas portable, moins rapide et risque de bug...

Citation:

---

Envoyé par hwoarang

Si tu es à l'aise avec C/C++, pourquoi ne pas faire les operations critiques avec et n'utiliser java que pour exploiter le resultat ? Parce que la lecture du fil laisse penser que tu vas faire un truc entre 2 ou tu auras les inconvenients des 2 cotés : Pas portable, moins rapide et risque de bug...

---

Je suis pas fou ! enfin... pas tout à fait :-)

Je veux garder tous les avantages de Java, mais j'aurai voulu palier à certains de ses défauts.

C'est pour cela que je voulais m'assurer que la mémoire était bien continue.
Si j'arrive à certifier une mémoire continue/contigüe, je m'assure de pouvoir utiliser une coeur C++ ultra performant, tout en laissant cela transparent à l'utilisateur.

La contiguité dépend, je dirais, de ta jvm. maintenant si tu veux traiter tes images en C++, qu'est-ce qui t'empeche de les stocker dans des tableaux c++ plutot que dans des objets java?

Citation:

---

Envoyé par tchize_

La contiguité dépend, je dirais, de ta jvm. maintenant si tu veux traiter tes images en C++, qu'est-ce qui t'empeche de les stocker dans des tableaux c++ plutot que dans des objets java?

---

Toutes mes I/O sont faites en Java, donc par défaut mes images sont stockées dans des tableaux Java.
Ce n'est que pour certaines tâches très spécifiques que je souhaite utiliser le C++.