Bonjour, j'ai entendu dire que tout ce qui est Vector, Hashtable, et
autres collection, ainsi que ce que propose le projet Trove allaient
être obsoletes du fait de nouvelles optimisations de compilation de JDK
1.5.0 sur la gestion des primitives dans les structures de données... je
n'arrive pas à trouver de lien sur cela...
quelqu'un peut il confirmer et m'indiquer une page pour en savoir plus ?
Encore une fois ce que je dis n'est pas "Il faut utiliser l'autoboxing avec les collections parceque c'est aussi rapide qu'un tableau de primitives", mais "Dire de ne pas utiliser l'autoboxing avec les Collections parceque c'est lent est un mauvais conseil".
Le problème de "Pif" était:
"Pif" wrote in message news:c4juat$3ve$
sans parler de bug, si c'est uniquement syntaxique, le problème est que mon appli a besoin de types primitifs pour gagner en performance, sinon, ca ferait trop d'objets qui feraient exploiser mister GC ! Donc la question, c'est est-ce exploitable ou dois-je en rester à Trove ? (nb, quelqu'un connait quelque chose de mieux que trove pour faire des hashtable de int ou de floats ?)
Aujourd'hui, dans ce contexte, je ne trouve pas l'autoboxing avec les collections exploitable. (Je n'ai jamais dit que, en règle général, il ne faut pas utiliser l'autoboxing avec les collections parce que c'est lent)
Retour au post de Marc:
Regles:
1. Designer le meilleur systeme possible. 2. Tester les performances 3. Optimiser les hotspots 4. Recommencer au point 2 a chaque nouvelle release de la JVM et au point 1 le plus souvent possible.
OK, mais ton discours au debut était:
(post de 2/4/2004)
IMO: Hotspot peut (va?) optimiser les collections de primitives auto-boxed, donc pourquoi se faire du soucis? Au pire quelqu'un fera les mesures qui s'imposent et creera un bug chez Sun.
Pas tout à fait la même chose ...
[...]
Je te laisse faire le bug report chez Sun :-)
Oui.
Peux-tu nous tenir au courant?
[...]
C'est exact. Je vais signaler le probleme a l'expert group.
J'aimerais bien avoir leur réponse.
-- Orjan Petersson, Logcode SARL The email address in the From: header is valid
Marc Petit-Huguenin <marc@petit-huguenin.org> writes:
[...]
Encore une fois ce que je dis n'est pas "Il faut
utiliser l'autoboxing avec les collections parceque c'est aussi rapide
qu'un tableau de primitives", mais "Dire de ne pas utiliser
l'autoboxing avec les Collections parceque c'est lent est un mauvais
conseil".
Le problème de "Pif" était:
"Pif" <pif@ifrance.com> wrote in message news:c4juat$3ve$1@eerie.ema.fr...
sans parler de bug, si c'est uniquement syntaxique, le problème est que
mon appli a besoin de types primitifs pour gagner en performance, sinon,
ca ferait trop d'objets qui feraient exploiser mister GC !
Donc la question, c'est est-ce exploitable ou dois-je en rester à Trove ?
(nb, quelqu'un connait quelque chose de mieux que trove pour faire des
hashtable de int ou de floats ?)
Aujourd'hui, dans ce contexte, je ne trouve pas l'autoboxing avec les
collections exploitable. (Je n'ai jamais dit que, en règle général, il
ne faut pas utiliser l'autoboxing avec les collections parce que c'est
lent)
Retour au post de Marc:
Regles:
1. Designer le meilleur systeme possible.
2. Tester les performances
3. Optimiser les hotspots
4. Recommencer au point 2 a chaque nouvelle release de la JVM et au
point 1 le plus souvent possible.
OK, mais ton discours au debut était:
(post de 2/4/2004)
IMO: Hotspot peut (va?) optimiser les collections de primitives
auto-boxed, donc pourquoi se faire du soucis? Au pire quelqu'un fera
les mesures qui s'imposent et creera un bug chez Sun.
Pas tout à fait la même chose ...
[...]
Je te laisse faire le bug report chez Sun :-)
Oui.
Peux-tu nous tenir au courant?
[...]
C'est exact. Je vais signaler le probleme a l'expert group.
J'aimerais bien avoir leur réponse.
--
Orjan Petersson, Logcode SARL
The email address in the From: header is valid
Encore une fois ce que je dis n'est pas "Il faut utiliser l'autoboxing avec les collections parceque c'est aussi rapide qu'un tableau de primitives", mais "Dire de ne pas utiliser l'autoboxing avec les Collections parceque c'est lent est un mauvais conseil".
Le problème de "Pif" était:
"Pif" wrote in message news:c4juat$3ve$
sans parler de bug, si c'est uniquement syntaxique, le problème est que mon appli a besoin de types primitifs pour gagner en performance, sinon, ca ferait trop d'objets qui feraient exploiser mister GC ! Donc la question, c'est est-ce exploitable ou dois-je en rester à Trove ? (nb, quelqu'un connait quelque chose de mieux que trove pour faire des hashtable de int ou de floats ?)
Aujourd'hui, dans ce contexte, je ne trouve pas l'autoboxing avec les collections exploitable. (Je n'ai jamais dit que, en règle général, il ne faut pas utiliser l'autoboxing avec les collections parce que c'est lent)
Retour au post de Marc:
Regles:
1. Designer le meilleur systeme possible. 2. Tester les performances 3. Optimiser les hotspots 4. Recommencer au point 2 a chaque nouvelle release de la JVM et au point 1 le plus souvent possible.
OK, mais ton discours au debut était:
(post de 2/4/2004)
IMO: Hotspot peut (va?) optimiser les collections de primitives auto-boxed, donc pourquoi se faire du soucis? Au pire quelqu'un fera les mesures qui s'imposent et creera un bug chez Sun.
Pas tout à fait la même chose ...
[...]
Je te laisse faire le bug report chez Sun :-)
Oui.
Peux-tu nous tenir au courant?
[...]
C'est exact. Je vais signaler le probleme a l'expert group.
J'aimerais bien avoir leur réponse.
-- Orjan Petersson, Logcode SARL The email address in the From: header is valid
Marc Petit-Huguenin
Örjan Petersson wrote:
Marc Petit-Huguenin writes:
[...]
Encore une fois ce que je dis n'est pas "Il faut utiliser l'autoboxing avec les collections parceque c'est aussi rapide qu'un tableau de primitives", mais "Dire de ne pas utiliser l'autoboxing avec les Collections parceque c'est lent est un mauvais conseil".
Le problème de "Pif" était:
"Pif" wrote in message news:c4juat$3ve$
sans parler de bug, si c'est uniquement syntaxique, le problème est que mon appli a besoin de types primitifs pour gagner en performance, sinon, ca ferait trop d'objets qui feraient exploiser mister GC ! Donc la question, c'est est-ce exploitable ou dois-je en rester à Trove ? (nb, quelqu'un connait quelque chose de mieux que trove pour faire des hashtable de int ou de floats ?)
Aujourd'hui, dans ce contexte, je ne trouve pas l'autoboxing avec les collections exploitable. (Je n'ai jamais dit que, en règle général, il ne faut pas utiliser l'autoboxing avec les collections parce que c'est lent)
Non, mais c'est ce que disait "Kupee", le poster auquel je repondais.
Retour au post de Marc:
Regles:
1. Designer le meilleur systeme possible. 2. Tester les performances 3. Optimiser les hotspots 4. Recommencer au point 2 a chaque nouvelle release de la JVM et au point 1 le plus souvent possible.
OK, mais ton discours au debut était:
(post de 2/4/2004)
IMO: Hotspot peut (va?) optimiser les collections de primitives auto-boxed, donc pourquoi se faire du soucis? Au pire quelqu'un fera les mesures qui s'imposent et creera un bug chez Sun.
Pas tout à fait la même chose ...
OK, il y a quelques raccourcis dans mon post original, mais le sens reste quand meme de ne pas se faire de soucis [au moment du design] parceque au pire quelqu'un fera les mesures qui s'imposent [dans son code pour faire les optimisations necessaire] et creera un bug chez Sun [pour pouvoir enlever ulterieurement ces optimisations quand SUN sortira une version optiisee].
Voila, voila.
[...]
Je te laisse faire le bug report chez Sun :-)
Oui.
Peux-tu nous tenir au courant?
OK.
[...]
C'est exact. Je vais signaler le probleme a l'expert group.
J'aimerais bien avoir leur réponse.
OK.
Örjan Petersson wrote:
Marc Petit-Huguenin <marc@petit-huguenin.org> writes:
[...]
Encore une fois ce que je dis n'est pas "Il faut
utiliser l'autoboxing avec les collections parceque c'est aussi rapide
qu'un tableau de primitives", mais "Dire de ne pas utiliser
l'autoboxing avec les Collections parceque c'est lent est un mauvais
conseil".
Le problème de "Pif" était:
"Pif" <pif@ifrance.com> wrote in message news:c4juat$3ve$1@eerie.ema.fr...
sans parler de bug, si c'est uniquement syntaxique, le problème est que
mon appli a besoin de types primitifs pour gagner en performance, sinon,
ca ferait trop d'objets qui feraient exploiser mister GC !
Donc la question, c'est est-ce exploitable ou dois-je en rester à Trove ?
(nb, quelqu'un connait quelque chose de mieux que trove pour faire des
hashtable de int ou de floats ?)
Aujourd'hui, dans ce contexte, je ne trouve pas l'autoboxing avec les
collections exploitable. (Je n'ai jamais dit que, en règle général, il
ne faut pas utiliser l'autoboxing avec les collections parce que c'est
lent)
Non, mais c'est ce que disait "Kupee", le poster auquel je repondais.
Retour au post de Marc:
Regles:
1. Designer le meilleur systeme possible.
2. Tester les performances
3. Optimiser les hotspots
4. Recommencer au point 2 a chaque nouvelle release de la JVM et au
point 1 le plus souvent possible.
OK, mais ton discours au debut était:
(post de 2/4/2004)
IMO: Hotspot peut (va?) optimiser les collections de primitives
auto-boxed, donc pourquoi se faire du soucis? Au pire quelqu'un fera
les mesures qui s'imposent et creera un bug chez Sun.
Pas tout à fait la même chose ...
OK, il y a quelques raccourcis dans mon post original, mais le sens reste
quand meme de ne pas se faire de soucis [au moment du design] parceque au
pire quelqu'un fera les mesures qui s'imposent [dans son code pour faire
les optimisations necessaire] et creera un bug chez Sun [pour pouvoir
enlever ulterieurement ces optimisations quand SUN sortira une version
optiisee].
Voila, voila.
[...]
Je te laisse faire le bug report chez Sun :-)
Oui.
Peux-tu nous tenir au courant?
OK.
[...]
C'est exact. Je vais signaler le probleme a l'expert group.
Encore une fois ce que je dis n'est pas "Il faut utiliser l'autoboxing avec les collections parceque c'est aussi rapide qu'un tableau de primitives", mais "Dire de ne pas utiliser l'autoboxing avec les Collections parceque c'est lent est un mauvais conseil".
Le problème de "Pif" était:
"Pif" wrote in message news:c4juat$3ve$
sans parler de bug, si c'est uniquement syntaxique, le problème est que mon appli a besoin de types primitifs pour gagner en performance, sinon, ca ferait trop d'objets qui feraient exploiser mister GC ! Donc la question, c'est est-ce exploitable ou dois-je en rester à Trove ? (nb, quelqu'un connait quelque chose de mieux que trove pour faire des hashtable de int ou de floats ?)
Aujourd'hui, dans ce contexte, je ne trouve pas l'autoboxing avec les collections exploitable. (Je n'ai jamais dit que, en règle général, il ne faut pas utiliser l'autoboxing avec les collections parce que c'est lent)
Non, mais c'est ce que disait "Kupee", le poster auquel je repondais.
Retour au post de Marc:
Regles:
1. Designer le meilleur systeme possible. 2. Tester les performances 3. Optimiser les hotspots 4. Recommencer au point 2 a chaque nouvelle release de la JVM et au point 1 le plus souvent possible.
OK, mais ton discours au debut était:
(post de 2/4/2004)
IMO: Hotspot peut (va?) optimiser les collections de primitives auto-boxed, donc pourquoi se faire du soucis? Au pire quelqu'un fera les mesures qui s'imposent et creera un bug chez Sun.
Pas tout à fait la même chose ...
OK, il y a quelques raccourcis dans mon post original, mais le sens reste quand meme de ne pas se faire de soucis [au moment du design] parceque au pire quelqu'un fera les mesures qui s'imposent [dans son code pour faire les optimisations necessaire] et creera un bug chez Sun [pour pouvoir enlever ulterieurement ces optimisations quand SUN sortira une version optiisee].
Voila, voila.
[...]
Je te laisse faire le bug report chez Sun :-)
Oui.
Peux-tu nous tenir au courant?
OK.
[...]
C'est exact. Je vais signaler le probleme a l'expert group.
J'aimerais bien avoir leur réponse.
OK.
Marc Petit-Huguenin
Örjan Petersson wrote:
Marc Petit-Huguenin writes:
Retour au post de Marc:
[snip]
OK, mais ton discours au debut était:
(post de 2/4/2004)
IMO: Hotspot peut (va?) optimiser les collections de primitives auto-boxed, donc pourquoi se faire du soucis? Au pire quelqu'un fera les mesures qui s'imposent et creera un bug chez Sun.
Pas tout à fait la même chose ...
[...]
Je te laisse faire le bug report chez Sun :-)
Oui.
Peux-tu nous tenir au courant?
[...]
C'est exact. Je vais signaler le probleme a l'expert group.
J'aimerais bien avoir leur réponse.
Alors apres discussion avec quelques sommites de chez Sun, la conclusion est sans equivoque que toutes ces optimisations sont possible maintenant et seront faite un jour (mais pas tout de suite).
La ou j'ai ete bluffe, c'est quand j'ai propose ce programme comme exemple de ce qui pouvait etre optimise...
List<Integer> list = new ArrayList<Integer>(); for (int i = 0; i < 1000; i++) { list.add(i); } int value = 0; for (int i = 0; i < 1000; i++) { value += list.get(i); }
Et que l'on m'a repondu qu'il est possible qu'un jour Hotspot puisse le reduire a ca:
int value = (999 * 1000) / 2;
Les microbenchmarkers de tout poils n'ont pas fini de pleurer leur mere...
Örjan Petersson wrote:
Marc Petit-Huguenin <marc@petit-huguenin.org> writes:
Retour au post de Marc:
[snip]
OK, mais ton discours au debut était:
(post de 2/4/2004)
IMO: Hotspot peut (va?) optimiser les collections de primitives
auto-boxed, donc pourquoi se faire du soucis? Au pire quelqu'un fera
les mesures qui s'imposent et creera un bug chez Sun.
Pas tout à fait la même chose ...
[...]
Je te laisse faire le bug report chez Sun :-)
Oui.
Peux-tu nous tenir au courant?
[...]
C'est exact. Je vais signaler le probleme a l'expert group.
J'aimerais bien avoir leur réponse.
Alors apres discussion avec quelques sommites de chez Sun, la conclusion
est sans equivoque que toutes ces optimisations sont possible maintenant et
seront faite un jour (mais pas tout de suite).
La ou j'ai ete bluffe, c'est quand j'ai propose ce programme comme exemple
de ce qui pouvait etre optimise...
List<Integer> list = new ArrayList<Integer>();
for (int i = 0; i < 1000; i++) {
list.add(i);
}
int value = 0;
for (int i = 0; i < 1000; i++) {
value += list.get(i);
}
Et que l'on m'a repondu qu'il est possible qu'un jour Hotspot puisse le
reduire a ca:
int value = (999 * 1000) / 2;
Les microbenchmarkers de tout poils n'ont pas fini de pleurer leur mere...
IMO: Hotspot peut (va?) optimiser les collections de primitives auto-boxed, donc pourquoi se faire du soucis? Au pire quelqu'un fera les mesures qui s'imposent et creera un bug chez Sun.
Pas tout à fait la même chose ...
[...]
Je te laisse faire le bug report chez Sun :-)
Oui.
Peux-tu nous tenir au courant?
[...]
C'est exact. Je vais signaler le probleme a l'expert group.
J'aimerais bien avoir leur réponse.
Alors apres discussion avec quelques sommites de chez Sun, la conclusion est sans equivoque que toutes ces optimisations sont possible maintenant et seront faite un jour (mais pas tout de suite).
La ou j'ai ete bluffe, c'est quand j'ai propose ce programme comme exemple de ce qui pouvait etre optimise...
List<Integer> list = new ArrayList<Integer>(); for (int i = 0; i < 1000; i++) { list.add(i); } int value = 0; for (int i = 0; i < 1000; i++) { value += list.get(i); }
Et que l'on m'a repondu qu'il est possible qu'un jour Hotspot puisse le reduire a ca:
int value = (999 * 1000) / 2;
Les microbenchmarkers de tout poils n'ont pas fini de pleurer leur mere...
