Je suis entrain de coder des fonctions de string-matching pour obtenir de m=
eilleurs r=E9sultats que la fonction indexOf. J'ai cod=E9 l'algorithme Boye=
r-Moore et Knuth-Morris-Pratt. Pour mes benchmarks, je lance 10 fois chaque=
fonction et je fait une moyenne pour avoir une approximation du temps.=20
J'ai cependant un probl=E8me, au premier appel de mes fonctions de string-m=
atching, le temps est beaucoup plus grand que les appels suivant. J'ai l'im=
pression que la fonction apr=E8s le premier appel est charg=E9e en m=E9moir=
e, ce qui fait que pour les appels suivant le temps est r=E9duit. J'ai effe=
ctu=E9 un test qui tend =E0 confirmer cela : avant de lancer mes 10 tests p=
our un algo, j'appelle la fonction avec un param=E8tre sp=E9cial qui indiqu=
e =E0 la fonction qu'elle ne doit rien faire. Par ce proc=E9d=E9, elle est =
charg=E9e en m=E9moire avant mes benchmarks.
Est-ce qu'il existerait une option en java permettant de garder les fonctio=
ns en m=E9moires ou quelque chose du style ?=20
Toute aide sera la bienvenue. D'avance merci.
Fran=E7ois Gaspard
Sans appeler la fonction avant :
BM Terminated in 36 ms
BM Terminated in 15 ms
BM Terminated in 10 ms
BM Terminated in 9 ms
BM Terminated in 9 ms
BM Terminated in 10 ms
BM Terminated in 8 ms
BM Terminated in 13 ms
BM Terminated in 8 ms
BM Terminated in 9 ms
Moyenne : 12
En appellant la fonction avant :
BM Terminated in 13 ms
BM Terminated in 10 ms
BM Terminated in 8 ms
BM Terminated in 9 ms
BM Terminated in 13 ms
BM Terminated in 12 ms
BM Terminated in 8 ms
BM Terminated in 19 ms
BM Terminated in 9 ms
BM Terminated in 9 ms
Moyenne : 11
bash-2.05b$ java -version
java version "1.4.2_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
Java HotSpot(TM) Client VM (build 1.4.2_04-b05, mixed mode)
bash-2.05b$=20
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Gaetan Zoritchak
Gaspard François wrote:
Bonjour,
Je suis entrain de coder des fonctions de string-matching pour obtenir de meilleurs résultats que la fonction indexOf. J'ai codé l'algorithme Boyer-Moore et Knuth-Morris-Pratt. Pour mes benchmarks, je lance 10 fois chaque fonction et je fait une moyenne pour avoir une approximation du temps.
J'ai cependant un problème, au premier appel de mes fonctions de string-matching, le temps est beaucoup plus grand que les appels suivant. J'ai l'impression que la fonction après le premier appel est chargée en mémoire, ce qui fait que pour les appels suivant le temps est réduit. J'ai effectué un test qui tend à confirmer cela : avant de lancer mes 10 tests pour un algo, j'appelle la fonction avec un paramètre spécial qui indique à la fonction qu'elle ne doit rien faire. Par ce procédé, elle est chargée en mémoire avant mes benchmarks.
Est-ce qu'il existerait une option en java permettant de garder les fonctions en mémoires ou quelque chose du style ?
Toute aide sera la bienvenue. D'avance merci.
François Gaspard
En fait la JVM Hotspot optimise ton bytecode et la première exécution est plus lente, entre autres, pour cela. Pour ton bench, tu as donc intérêt à l'exécuter une première fois normalement avant de commencer tes mesures. Si tu veux plus de précision sur tes comparaisons, je te conseille de lancer ton test une centaine de fois et de ne pas faire de System.out pendant le test.
-- Gaetan Zoritchak Gestion de bug en mode ASP sous java http://eap.bug-sweeper.fr
Gaspard François wrote:
Bonjour,
Je suis entrain de coder des fonctions de string-matching pour obtenir de meilleurs résultats que la fonction indexOf. J'ai codé l'algorithme Boyer-Moore et Knuth-Morris-Pratt. Pour mes benchmarks, je lance 10 fois chaque fonction et je fait une moyenne pour avoir une approximation du temps.
J'ai cependant un problème, au premier appel de mes fonctions de string-matching, le temps est beaucoup plus grand que les appels suivant. J'ai l'impression que la fonction après le premier appel est chargée en mémoire, ce qui fait que pour les appels suivant le temps est réduit. J'ai effectué un test qui tend à confirmer cela : avant de lancer mes 10 tests pour un algo, j'appelle la fonction avec un paramètre spécial qui indique à la fonction qu'elle ne doit rien faire. Par ce procédé, elle est chargée en mémoire avant mes benchmarks.
Est-ce qu'il existerait une option en java permettant de garder les fonctions en mémoires ou quelque chose du style ?
Toute aide sera la bienvenue. D'avance merci.
François Gaspard
En fait la JVM Hotspot optimise ton bytecode et la première exécution
est plus lente, entre autres, pour cela. Pour ton bench, tu as donc
intérêt à l'exécuter une première fois normalement avant de commencer
tes mesures. Si tu veux plus de précision sur tes comparaisons, je te
conseille de lancer ton test une centaine de fois et de ne pas faire de
System.out pendant le test.
--
Gaetan Zoritchak
Gestion de bug en mode ASP sous java
http://eap.bug-sweeper.fr
Je suis entrain de coder des fonctions de string-matching pour obtenir de meilleurs résultats que la fonction indexOf. J'ai codé l'algorithme Boyer-Moore et Knuth-Morris-Pratt. Pour mes benchmarks, je lance 10 fois chaque fonction et je fait une moyenne pour avoir une approximation du temps.
J'ai cependant un problème, au premier appel de mes fonctions de string-matching, le temps est beaucoup plus grand que les appels suivant. J'ai l'impression que la fonction après le premier appel est chargée en mémoire, ce qui fait que pour les appels suivant le temps est réduit. J'ai effectué un test qui tend à confirmer cela : avant de lancer mes 10 tests pour un algo, j'appelle la fonction avec un paramètre spécial qui indique à la fonction qu'elle ne doit rien faire. Par ce procédé, elle est chargée en mémoire avant mes benchmarks.
Est-ce qu'il existerait une option en java permettant de garder les fonctions en mémoires ou quelque chose du style ?
Toute aide sera la bienvenue. D'avance merci.
François Gaspard
En fait la JVM Hotspot optimise ton bytecode et la première exécution est plus lente, entre autres, pour cela. Pour ton bench, tu as donc intérêt à l'exécuter une première fois normalement avant de commencer tes mesures. Si tu veux plus de précision sur tes comparaisons, je te conseille de lancer ton test une centaine de fois et de ne pas faire de System.out pendant le test.
-- Gaetan Zoritchak Gestion de bug en mode ASP sous java http://eap.bug-sweeper.fr
Sébastien
En fait la JVM Hotspot optimise ton bytecode et la première exécution est plus lente, entre autres, pour cela. Pour ton bench, tu as donc intérêt à l'exécuter une première fois normalement avant de commencer tes mesures. Si tu veux plus de précision sur tes comparaisons, je te conseille de lancer ton test une centaine de fois et de ne pas faire de System.out pendant le test.
sauf erreur, hotspot ne va optimiser la méthode qu'au bout d'un certain nombre d'appels et en tout cas pas au premier. Il faut qu'une méthode soit très sollicitée pour être gérée par hotspot. Je crois que c'est configurable dans la jvm. J'ai lu il y a pas mal de temps des articles sur des façons de tester avec hotspot. L'idée c'est de laisser passer un "grand" nombre d'appels à la méthode avant de commencer les mesures.
Sébastien
En fait la JVM Hotspot optimise ton bytecode et la première exécution
est plus lente, entre autres, pour cela. Pour ton bench, tu as donc
intérêt à l'exécuter une première fois normalement avant de commencer
tes mesures. Si tu veux plus de précision sur tes comparaisons, je te
conseille de lancer ton test une centaine de fois et de ne pas faire de
System.out pendant le test.
sauf erreur, hotspot ne va optimiser la méthode qu'au bout d'un certain nombre d'appels et en tout
cas pas au premier. Il faut qu'une méthode soit très sollicitée pour être gérée par hotspot. Je
crois que c'est configurable dans la jvm.
J'ai lu il y a pas mal de temps des articles sur des façons de tester avec hotspot. L'idée c'est de
laisser passer un "grand" nombre d'appels à la méthode avant de commencer les mesures.
En fait la JVM Hotspot optimise ton bytecode et la première exécution est plus lente, entre autres, pour cela. Pour ton bench, tu as donc intérêt à l'exécuter une première fois normalement avant de commencer tes mesures. Si tu veux plus de précision sur tes comparaisons, je te conseille de lancer ton test une centaine de fois et de ne pas faire de System.out pendant le test.
sauf erreur, hotspot ne va optimiser la méthode qu'au bout d'un certain nombre d'appels et en tout cas pas au premier. Il faut qu'une méthode soit très sollicitée pour être gérée par hotspot. Je crois que c'est configurable dans la jvm. J'ai lu il y a pas mal de temps des articles sur des façons de tester avec hotspot. L'idée c'est de laisser passer un "grand" nombre d'appels à la méthode avant de commencer les mesures.
Sébastien
Johann Burkard
Gaspard François wrote:
[...] J'ai codé l'algorithme Boyer-Moore et Knuth-Morris-Pratt.
Trop tard, parce que je l'ai fait déjà pour toi [1] (en fait, j'ai pas BM, mais Boyer-Moore-Horspool et Boyer-Moore-Horspool-Raita). En plus, KMP n'était past très vite, donc c'est pas inclus dans StringSearch.
[1] <http://johannburkard.de>
Johann -- Verschwinden sie endlich in ihren Laufstall und geben Sie ruhe, denn das, was von ihnen in den letzten Wochen und Monaten zu lesen war, ist kaum noch an Peinlichkeiten zu ueberbieten. (*Tönnes über Andere in <a701sh$99p$)
Gaspard François wrote:
[...] J'ai codé l'algorithme Boyer-Moore et Knuth-Morris-Pratt.
Trop tard, parce que je l'ai fait déjà pour toi [1] (en fait, j'ai pas
BM, mais Boyer-Moore-Horspool et Boyer-Moore-Horspool-Raita). En plus,
KMP n'était past très vite, donc c'est pas inclus dans StringSearch.
[1] <http://johannburkard.de>
Johann
--
Verschwinden sie endlich in ihren Laufstall und geben Sie ruhe, denn
das, was von ihnen in den letzten Wochen und Monaten zu lesen war, ist
kaum noch an Peinlichkeiten zu ueberbieten.
(*Tönnes über Andere in <a701sh$99p$1@newsreader2.netcologne.de>)
[...] J'ai codé l'algorithme Boyer-Moore et Knuth-Morris-Pratt.
Trop tard, parce que je l'ai fait déjà pour toi [1] (en fait, j'ai pas BM, mais Boyer-Moore-Horspool et Boyer-Moore-Horspool-Raita). En plus, KMP n'était past très vite, donc c'est pas inclus dans StringSearch.
[1] <http://johannburkard.de>
Johann -- Verschwinden sie endlich in ihren Laufstall und geben Sie ruhe, denn das, was von ihnen in den letzten Wochen und Monaten zu lesen war, ist kaum noch an Peinlichkeiten zu ueberbieten. (*Tönnes über Andere in <a701sh$99p$)
barilla
par defaut (mode client) la compilation se fait lors de la premiere execution. si tu lances java avec -server, tout est compile des le lancement de l'appli. du coup le lancement de l'appli est un peu plus long, mais pas de pause dans l'execution.
en effet l'optimisation n'arrive qu'apres de nombreux appel du meme code.
paul.
par defaut (mode client) la compilation se fait lors de
la premiere execution.
si tu lances java avec -server, tout est compile des
le lancement de l'appli. du coup le lancement de l'appli est
un peu plus long, mais pas de pause dans l'execution.
en effet l'optimisation n'arrive qu'apres de nombreux
appel du meme code.
par defaut (mode client) la compilation se fait lors de la premiere execution. si tu lances java avec -server, tout est compile des le lancement de l'appli. du coup le lancement de l'appli est un peu plus long, mais pas de pause dans l'execution.
en effet l'optimisation n'arrive qu'apres de nombreux appel du meme code.
paul.
Gaspard François
Johann,
Je viens de voir ton implémentation mais ne n'est pas pour ça que je n' ai pas le droit de refaire mes fonctions :)
Pour ma part, j'ai implémenté l'algo BM avec l'heuristique du mauvais c aractère et du bon suffixe. J'ai également testé avec la comparaison en byte qui est plus rapide. Je vois cependant que tu as testé aussi avec les fonctions en natives, ce que je n'ai pas encore fait. Je comptais de t oute façon essayer.
Je dois dire que ton code est beaucoup plus propre que le mien en tous les cas et semble très bien fait (mais je ne l'ai pas testé). KMP est en ef fet beaucoup trop lent, mais je voulais avoir une approximation. Je compte bien encore gagné du temps en implémentant plusieurs algos : tuned BM, Berry-RavinDram, Galil-Seiferas ainsi que les algos jouant sur la fréquen ces des lettres comme Optimal Mismatch ou Maximal Shift. Mon but est de cho isir l'algo adéquat en runtime en fonction du pattern cherché et de l'a lphabet.
François
On Thu, 17 Mar 2005 13:57:07 +0100 Johann Burkard wrote:
Gaspard François wrote:
[...] J'ai codé l'algorithme Boyer-Moore et Knuth-Morris-Pratt.
Trop tard, parce que je l'ai fait déjà pour toi [1] (en fait, j'ai pas BM, mais Boyer-Moore-Horspool et Boyer-Moore-Horspool-Raita). En plus, KMP n'était past très vite, donc c'est pas inclus dans StringSearch.
[1] <http://johannburkard.de>
Johann -- Verschwinden sie endlich in ihren Laufstall und geben Sie ruhe, denn das, was von ihnen in den letzten Wochen und Monaten zu lesen war, ist kaum noch an Peinlichkeiten zu ueberbieten. (*Tönnes über Andere in <a701sh$99p$)
Johann,
Je viens de voir ton implémentation mais ne n'est pas pour ça que je n' ai pas le droit de refaire mes fonctions :)
Pour ma part, j'ai implémenté l'algo BM avec l'heuristique du mauvais c aractère et du bon suffixe. J'ai également testé avec la comparaison en byte qui est plus rapide. Je vois cependant que tu as testé aussi avec les fonctions en natives, ce que je n'ai pas encore fait. Je comptais de t oute façon essayer.
Je dois dire que ton code est beaucoup plus propre que le mien en tous les cas et semble très bien fait (mais je ne l'ai pas testé). KMP est en ef fet beaucoup trop lent, mais je voulais avoir une approximation. Je compte bien encore gagné du temps en implémentant plusieurs algos : tuned BM, Berry-RavinDram, Galil-Seiferas ainsi que les algos jouant sur la fréquen ces des lettres comme Optimal Mismatch ou Maximal Shift. Mon but est de cho isir l'algo adéquat en runtime en fonction du pattern cherché et de l'a lphabet.
François
On Thu, 17 Mar 2005 13:57:07 +0100
Johann Burkard <johannburkard@nexgo.de> wrote:
Gaspard François wrote:
[...] J'ai codé l'algorithme Boyer-Moore et Knuth-Morris-Pratt.
Trop tard, parce que je l'ai fait déjà pour toi [1] (en fait, j'ai pas
BM, mais Boyer-Moore-Horspool et Boyer-Moore-Horspool-Raita). En plus,
KMP n'était past très vite, donc c'est pas inclus dans StringSearch.
[1] <http://johannburkard.de>
Johann
--
Verschwinden sie endlich in ihren Laufstall und geben Sie ruhe, denn
das, was von ihnen in den letzten Wochen und Monaten zu lesen war, ist
kaum noch an Peinlichkeiten zu ueberbieten.
(*Tönnes über Andere in <a701sh$99p$1@newsreader2.netcologne.de>)
Je viens de voir ton implémentation mais ne n'est pas pour ça que je n' ai pas le droit de refaire mes fonctions :)
Pour ma part, j'ai implémenté l'algo BM avec l'heuristique du mauvais c aractère et du bon suffixe. J'ai également testé avec la comparaison en byte qui est plus rapide. Je vois cependant que tu as testé aussi avec les fonctions en natives, ce que je n'ai pas encore fait. Je comptais de t oute façon essayer.
Je dois dire que ton code est beaucoup plus propre que le mien en tous les cas et semble très bien fait (mais je ne l'ai pas testé). KMP est en ef fet beaucoup trop lent, mais je voulais avoir une approximation. Je compte bien encore gagné du temps en implémentant plusieurs algos : tuned BM, Berry-RavinDram, Galil-Seiferas ainsi que les algos jouant sur la fréquen ces des lettres comme Optimal Mismatch ou Maximal Shift. Mon but est de cho isir l'algo adéquat en runtime en fonction du pattern cherché et de l'a lphabet.
François
On Thu, 17 Mar 2005 13:57:07 +0100 Johann Burkard wrote:
Gaspard François wrote:
[...] J'ai codé l'algorithme Boyer-Moore et Knuth-Morris-Pratt.
Trop tard, parce que je l'ai fait déjà pour toi [1] (en fait, j'ai pas BM, mais Boyer-Moore-Horspool et Boyer-Moore-Horspool-Raita). En plus, KMP n'était past très vite, donc c'est pas inclus dans StringSearch.
[1] <http://johannburkard.de>
Johann -- Verschwinden sie endlich in ihren Laufstall und geben Sie ruhe, denn das, was von ihnen in den letzten Wochen und Monaten zu lesen war, ist kaum noch an Peinlichkeiten zu ueberbieten. (*Tönnes über Andere in <a701sh$99p$)
Gaspard François
Merci pour vos éclairsissement. Pour répondre à Gaetan, le system.out n'est pas compté dans le temps du benchmark. Je pourrais en effet test é sur 100 recherches pour avoir une approximation plus précise.
Je vais testé ce que Paul m'a conseillé avec l'option -server et je vou s tient à jour des résultats.
Ce que je trouve quand même bizare, c'est qu'avec le bench de la fonction indexOf, le premier appel prend le même temps que les autres appels. Est -ce que la fonction indexOf de java serait déjà compilé au lancement par rapport à mes fonctions ?
François
On Thu, 17 Mar 2005 14:54:09 +0100 barilla wrote:
par defaut (mode client) la compilation se fait lors de la premiere execution. si tu lances java avec -server, tout est compile des le lancement de l'appli. du coup le lancement de l'appli est un peu plus long, mais pas de pause dans l'execution.
en effet l'optimisation n'arrive qu'apres de nombreux appel du meme code.
paul.
Merci pour vos éclairsissement. Pour répondre à Gaetan, le system.out n'est pas compté dans le temps du benchmark. Je pourrais en effet test é sur 100 recherches pour avoir une approximation plus précise.
Je vais testé ce que Paul m'a conseillé avec l'option -server et je vou s tient à jour des résultats.
Ce que je trouve quand même bizare, c'est qu'avec le bench de la fonction indexOf, le premier appel prend le même temps que les autres appels. Est -ce que la fonction indexOf de java serait déjà compilé au lancement par rapport à mes fonctions ?
François
On Thu, 17 Mar 2005 14:54:09 +0100
barilla <nospam@nospam.nonono> wrote:
par defaut (mode client) la compilation se fait lors de
la premiere execution.
si tu lances java avec -server, tout est compile des
le lancement de l'appli. du coup le lancement de l'appli est
un peu plus long, mais pas de pause dans l'execution.
en effet l'optimisation n'arrive qu'apres de nombreux
appel du meme code.
Merci pour vos éclairsissement. Pour répondre à Gaetan, le system.out n'est pas compté dans le temps du benchmark. Je pourrais en effet test é sur 100 recherches pour avoir une approximation plus précise.
Je vais testé ce que Paul m'a conseillé avec l'option -server et je vou s tient à jour des résultats.
Ce que je trouve quand même bizare, c'est qu'avec le bench de la fonction indexOf, le premier appel prend le même temps que les autres appels. Est -ce que la fonction indexOf de java serait déjà compilé au lancement par rapport à mes fonctions ?
François
On Thu, 17 Mar 2005 14:54:09 +0100 barilla wrote:
par defaut (mode client) la compilation se fait lors de la premiere execution. si tu lances java avec -server, tout est compile des le lancement de l'appli. du coup le lancement de l'appli est un peu plus long, mais pas de pause dans l'execution.
en effet l'optimisation n'arrive qu'apres de nombreux appel du meme code.
paul.
Gaspard François
Johann,
Je viens de faire des tests avec java5 et mes résultats de bench sur la c omparaison de caractère son presque 5 fois plus lent qu'avec java 1.4 !!? ??!!! Par contre, avec la recherche en byte, j'obtiens les mêmes résult ats plus ou moins.
As-tu essayé ta lib de string matching avec java5 ? Je ne sais pas si j'a i fait une erreur quelque part ou si c'est vraiment java5 qui a un problè me pour le traitement de caractères.
D'avance merci,
François.
On Thu, 17 Mar 2005 13:57:07 +0100 Johann Burkard wrote:
Gaspard François wrote:
[...] J'ai codé l'algorithme Boyer-Moore et Knuth-Morris-Pratt.
Trop tard, parce que je l'ai fait déjà pour toi [1] (en fait, j'ai pas BM, mais Boyer-Moore-Horspool et Boyer-Moore-Horspool-Raita). En plus, KMP n'était past très vite, donc c'est pas inclus dans StringSearch.
[1] <http://johannburkard.de>
Johann -- Verschwinden sie endlich in ihren Laufstall und geben Sie ruhe, denn das, was von ihnen in den letzten Wochen und Monaten zu lesen war, ist kaum noch an Peinlichkeiten zu ueberbieten. (*Tönnes über Andere in <a701sh$99p$)
Johann,
Je viens de faire des tests avec java5 et mes résultats de bench sur la c omparaison de caractère son presque 5 fois plus lent qu'avec java 1.4 !!? ??!!! Par contre, avec la recherche en byte, j'obtiens les mêmes résult ats plus ou moins.
As-tu essayé ta lib de string matching avec java5 ? Je ne sais pas si j'a i fait une erreur quelque part ou si c'est vraiment java5 qui a un problè me pour le traitement de caractères.
D'avance merci,
François.
On Thu, 17 Mar 2005 13:57:07 +0100
Johann Burkard <johannburkard@nexgo.de> wrote:
Gaspard François wrote:
[...] J'ai codé l'algorithme Boyer-Moore et Knuth-Morris-Pratt.
Trop tard, parce que je l'ai fait déjà pour toi [1] (en fait, j'ai pas
BM, mais Boyer-Moore-Horspool et Boyer-Moore-Horspool-Raita). En plus,
KMP n'était past très vite, donc c'est pas inclus dans StringSearch.
[1] <http://johannburkard.de>
Johann
--
Verschwinden sie endlich in ihren Laufstall und geben Sie ruhe, denn
das, was von ihnen in den letzten Wochen und Monaten zu lesen war, ist
kaum noch an Peinlichkeiten zu ueberbieten.
(*Tönnes über Andere in <a701sh$99p$1@newsreader2.netcologne.de>)
Je viens de faire des tests avec java5 et mes résultats de bench sur la c omparaison de caractère son presque 5 fois plus lent qu'avec java 1.4 !!? ??!!! Par contre, avec la recherche en byte, j'obtiens les mêmes résult ats plus ou moins.
As-tu essayé ta lib de string matching avec java5 ? Je ne sais pas si j'a i fait une erreur quelque part ou si c'est vraiment java5 qui a un problè me pour le traitement de caractères.
D'avance merci,
François.
On Thu, 17 Mar 2005 13:57:07 +0100 Johann Burkard wrote:
Gaspard François wrote:
[...] J'ai codé l'algorithme Boyer-Moore et Knuth-Morris-Pratt.
Trop tard, parce que je l'ai fait déjà pour toi [1] (en fait, j'ai pas BM, mais Boyer-Moore-Horspool et Boyer-Moore-Horspool-Raita). En plus, KMP n'était past très vite, donc c'est pas inclus dans StringSearch.
[1] <http://johannburkard.de>
Johann -- Verschwinden sie endlich in ihren Laufstall und geben Sie ruhe, denn das, was von ihnen in den letzten Wochen und Monaten zu lesen war, ist kaum noch an Peinlichkeiten zu ueberbieten. (*Tönnes über Andere in <a701sh$99p$)
Gaspard François
Johann,
J'ai testé les mêmes test que avaec java 4. C'est à dire, que j'ai la ncé 10 test avec Boyer-Moore et j'ai fais une moyenne. Tout les tests ave c java 5 et les comparaisons de caractères sont plus lents. Par contre, l es tests avec la comparaison en byte sont plus rapide (pour boyer-moore et KMP).
Si je trouve la solution je le mets ici, mais jusque là je n'ai pas trouv é d'où pouvais venir l'erreur
François
On Sat, 19 Mar 2005 12:40:28 +0100 Johann Burkard wrote:
Johann Burkard wrote:
Dans com.eaio.stringsearch.StringSearch, il y'a un petit test de la version Java:
Et sur Java 5, crossover est CROSSOVER_SUN_PRE_1_4
Euh, non. J'ai installé JDK 5.0 hier et JDK 5.0 me donne 1.5.0_02, donc crossover est CROSSOVER_SUN_1_4.
Gaspard, tu peux me dire quoi exactement tu as testé:
-- 8< -- Je viens de faire des tests avec java5 et mes résultats de bench sur la comparaison de caractère son presque 5 fois plus lent qu'avec java 1.4 !!???!!! -- >8 --
J'aimerais bien le vérfier moi-même. Merci.
Johann -- Verschwinden sie endlich in ihren Laufstall und geben Sie ruhe, denn das, was von ihnen in den letzten Wochen und Monaten zu lesen war, ist kaum noch an Peinlichkeiten zu ueberbieten. (*Tönnes über Andere in <a701sh$99p$)
Johann,
J'ai testé les mêmes test que avaec java 4. C'est à dire, que j'ai la ncé 10 test avec Boyer-Moore et j'ai fais une moyenne. Tout les tests ave c java 5 et les comparaisons de caractères sont plus lents. Par contre, l es tests avec la comparaison en byte sont plus rapide (pour boyer-moore et KMP).
Si je trouve la solution je le mets ici, mais jusque là je n'ai pas trouv é d'où pouvais venir l'erreur
François
On Sat, 19 Mar 2005 12:40:28 +0100
Johann Burkard <johannburkard@nexgo.de> wrote:
Johann Burkard wrote:
Dans com.eaio.stringsearch.StringSearch, il y'a un petit test de la
version Java:
Et sur Java 5, crossover est CROSSOVER_SUN_PRE_1_4
Euh, non. J'ai installé JDK 5.0 hier et JDK 5.0 me donne 1.5.0_02, donc
crossover est CROSSOVER_SUN_1_4.
Gaspard, tu peux me dire quoi exactement tu as testé:
-- 8< --
Je viens de faire des tests avec java5 et mes résultats de bench sur la
comparaison de caractère son presque 5 fois plus lent qu'avec java 1.4
!!???!!!
-- >8 --
J'aimerais bien le vérfier moi-même. Merci.
Johann
--
Verschwinden sie endlich in ihren Laufstall und geben Sie ruhe, denn
das, was von ihnen in den letzten Wochen und Monaten zu lesen war, ist
kaum noch an Peinlichkeiten zu ueberbieten.
(*Tönnes über Andere in <a701sh$99p$1@newsreader2.netcologne.de>)
J'ai testé les mêmes test que avaec java 4. C'est à dire, que j'ai la ncé 10 test avec Boyer-Moore et j'ai fais une moyenne. Tout les tests ave c java 5 et les comparaisons de caractères sont plus lents. Par contre, l es tests avec la comparaison en byte sont plus rapide (pour boyer-moore et KMP).
Si je trouve la solution je le mets ici, mais jusque là je n'ai pas trouv é d'où pouvais venir l'erreur
François
On Sat, 19 Mar 2005 12:40:28 +0100 Johann Burkard wrote:
Johann Burkard wrote:
Dans com.eaio.stringsearch.StringSearch, il y'a un petit test de la version Java:
Et sur Java 5, crossover est CROSSOVER_SUN_PRE_1_4
Euh, non. J'ai installé JDK 5.0 hier et JDK 5.0 me donne 1.5.0_02, donc crossover est CROSSOVER_SUN_1_4.
Gaspard, tu peux me dire quoi exactement tu as testé:
-- 8< -- Je viens de faire des tests avec java5 et mes résultats de bench sur la comparaison de caractère son presque 5 fois plus lent qu'avec java 1.4 !!???!!! -- >8 --
J'aimerais bien le vérfier moi-même. Merci.
Johann -- Verschwinden sie endlich in ihren Laufstall und geben Sie ruhe, denn das, was von ihnen in den letzten Wochen und Monaten zu lesen war, ist kaum noch an Peinlichkeiten zu ueberbieten. (*Tönnes über Andere in <a701sh$99p$)
Gaspard François
C'est normal si les comparaisons de charactères sont _un peu_ plus lents (au maximum deux ou trois fois plus lents, voir les benchmarks que j'ai mis dans l'archive).
Comment ca c'est normal ? La nouvelle VM de java5 est plus lente que l'anci enne ? Dans ton benchmark, je ne vois pas que tu as testé avec java5.
Par contre, les tests avec la comparaison en byte sont plus rapide (pour boyer-moore et KMP).
Quel tests? Tu testes mes implementations contre tes implementations? Ou bien tu testes comparaison de charactères contre comparaison de bytes?
J'ai testé avec mon code (BM et KMP avec la comparaison en byte et charac tère). Je n'ai pas encore testé tes implémentations.
François.
C'est normal si les comparaisons de charactères sont _un peu_ plus lents
(au maximum deux ou trois fois plus lents, voir les benchmarks que j'ai
mis dans l'archive).
Comment ca c'est normal ? La nouvelle VM de java5 est plus lente que l'anci enne ?
Dans ton benchmark, je ne vois pas que tu as testé avec java5.
Par contre, les tests avec la comparaison en byte sont plus rapide
(pour boyer-moore et KMP).
Quel tests? Tu testes mes implementations contre tes implementations? Ou
bien tu testes comparaison de charactères contre comparaison de bytes?
J'ai testé avec mon code (BM et KMP avec la comparaison en byte et charac tère).
Je n'ai pas encore testé tes implémentations.
C'est normal si les comparaisons de charactères sont _un peu_ plus lents (au maximum deux ou trois fois plus lents, voir les benchmarks que j'ai mis dans l'archive).
Comment ca c'est normal ? La nouvelle VM de java5 est plus lente que l'anci enne ? Dans ton benchmark, je ne vois pas que tu as testé avec java5.
Par contre, les tests avec la comparaison en byte sont plus rapide (pour boyer-moore et KMP).
Quel tests? Tu testes mes implementations contre tes implementations? Ou bien tu testes comparaison de charactères contre comparaison de bytes?
J'ai testé avec mon code (BM et KMP avec la comparaison en byte et charac tère). Je n'ai pas encore testé tes implémentations.
