Le Thu, 23 Sep 2010 21:35:24 +0200,
sap écrivait :Le 23/09/2010 21:20, JKB a écrit :Le Thu, 23 Sep 2010 20:49:06 +0200,
sap écrivait :Le 23/09/2010 20:28, JKB a écrit :Le Thu, 23 Sep 2010 20:20:15 +0200,
Stephane CARPENTIER écrivait :JKB a écrit:Est-ce que tu vois la subtile différence entre un tri à la
shell-Metzner et une division ? Lorsque tu parles division à un
ingénieur, il sait de quoi tu parles. Lorsque tu cause tri
shell-Metzner à un ingénieur, il te regarde avec des gr ands yeux
vides. Il n'a _jamais_ entendu parlé
Ãa m'étonne un peu. Que certain ingénieurs n'en aie nt jamais entendus parler
ne m'étonne pas. Mais que la majorité des formations n'e n parle plus, me
surprend.
As-tu eu des ingénieurs frais émoulus dans les pattes rà ©cemment ?
Pour faire les généralités que vous avancez je su ppose que vous avez
eu entre les pattes un échantillon représentatif d'ingé nieurs de chaque
écoles de France et de Navarre ... à moins qu'on vous refi le les
derniers de la classe ,de l'école du coin .
J'enseigne dans plusieurs écoles dont Centrale et l'ENST. à a va comme
échantillon ? J'ai aussi des stagiaires de plusieurs école s assez
représentatives. Les meilleurs, on les trouve au CNAM.
JKB
ok après être passé entre tes mains ces aspirants ing énieurs sont
déclarés nuls . ça fait peur !
Je n'enseigne qu'_une_ matière.
Le Thu, 23 Sep 2010 21:35:24 +0200,
sap <doom.666@enfer.fr> écrivait :
Le 23/09/2010 21:20, JKB a écrit :
Le Thu, 23 Sep 2010 20:49:06 +0200,
sap<doom.666@enfer.fr> écrivait :
Le 23/09/2010 20:28, JKB a écrit :
Le Thu, 23 Sep 2010 20:20:15 +0200,
Stephane CARPENTIER<stef.carpentier@free.fr> écrivait :
JKB a écrit:
Est-ce que tu vois la subtile différence entre un tri à la
shell-Metzner et une division ? Lorsque tu parles division à un
ingénieur, il sait de quoi tu parles. Lorsque tu cause tri
shell-Metzner à un ingénieur, il te regarde avec des gr ands yeux
vides. Il n'a _jamais_ entendu parlé
Ãa m'étonne un peu. Que certain ingénieurs n'en aie nt jamais entendus parler
ne m'étonne pas. Mais que la majorité des formations n'e n parle plus, me
surprend.
As-tu eu des ingénieurs frais émoulus dans les pattes rà ©cemment ?
Pour faire les généralités que vous avancez je su ppose que vous avez
eu entre les pattes un échantillon représentatif d'ingé nieurs de chaque
écoles de France et de Navarre ... à moins qu'on vous refi le les
derniers de la classe ,de l'école du coin .
J'enseigne dans plusieurs écoles dont Centrale et l'ENST. à a va comme
échantillon ? J'ai aussi des stagiaires de plusieurs école s assez
représentatives. Les meilleurs, on les trouve au CNAM.
JKB
ok après être passé entre tes mains ces aspirants ing énieurs sont
déclarés nuls . ça fait peur !
Je n'enseigne qu'_une_ matière.
Le Thu, 23 Sep 2010 21:35:24 +0200,
sap écrivait :Le 23/09/2010 21:20, JKB a écrit :Le Thu, 23 Sep 2010 20:49:06 +0200,
sap écrivait :Le 23/09/2010 20:28, JKB a écrit :Le Thu, 23 Sep 2010 20:20:15 +0200,
Stephane CARPENTIER écrivait :JKB a écrit:Est-ce que tu vois la subtile différence entre un tri à la
shell-Metzner et une division ? Lorsque tu parles division à un
ingénieur, il sait de quoi tu parles. Lorsque tu cause tri
shell-Metzner à un ingénieur, il te regarde avec des gr ands yeux
vides. Il n'a _jamais_ entendu parlé
Ãa m'étonne un peu. Que certain ingénieurs n'en aie nt jamais entendus parler
ne m'étonne pas. Mais que la majorité des formations n'e n parle plus, me
surprend.
As-tu eu des ingénieurs frais émoulus dans les pattes rà ©cemment ?
Pour faire les généralités que vous avancez je su ppose que vous avez
eu entre les pattes un échantillon représentatif d'ingé nieurs de chaque
écoles de France et de Navarre ... à moins qu'on vous refi le les
derniers de la classe ,de l'école du coin .
J'enseigne dans plusieurs écoles dont Centrale et l'ENST. à a va comme
échantillon ? J'ai aussi des stagiaires de plusieurs école s assez
représentatives. Les meilleurs, on les trouve au CNAM.
JKB
ok après être passé entre tes mains ces aspirants ing énieurs sont
déclarés nuls . ça fait peur !
Je n'enseigne qu'_une_ matière.
Le 23/09/2010 22:58, PP a écrit :L'optimisation DOIT rester dans l'esprit des développeurs pour un tas
d'autres choses encore. Au niveau software certes, mais au niveau
hardware encore plus ! Ce qui semble encore mal barré.
Plus personne n'optimise plus et les clients achètent quand mê me.
Le 23/09/2010 22:58, PP a écrit :
L'optimisation DOIT rester dans l'esprit des développeurs pour un tas
d'autres choses encore. Au niveau software certes, mais au niveau
hardware encore plus ! Ce qui semble encore mal barré.
Plus personne n'optimise plus et les clients achètent quand mê me.
Le 23/09/2010 22:58, PP a écrit :L'optimisation DOIT rester dans l'esprit des développeurs pour un tas
d'autres choses encore. Au niveau software certes, mais au niveau
hardware encore plus ! Ce qui semble encore mal barré.
Plus personne n'optimise plus et les clients achètent quand mê me.
JKB a écrit :Le Thu, 23 Sep 2010 21:35:24 +0200,
sap écrivait :Le 23/09/2010 21:20, JKB a écrit :Le Thu, 23 Sep 2010 20:49:06 +0200,
sap écrivait :Le 23/09/2010 20:28, JKB a écrit :Le Thu, 23 Sep 2010 20:20:15 +0200,
Stephane CARPENTIER écrivait :JKB a écrit:Est-ce que tu vois la subtile différence entre un tri à la
shell-Metzner et une division ? Lorsque tu parles division à un
ingénieur, il sait de quoi tu parles. Lorsque tu cause tri
shell-Metzner à un ingénieur, il te regarde avec des grands yeux
vides. Il n'a _jamais_ entendu parlé
Ça m'étonne un peu. Que certain ingénieurs n'en aient jamais entendus parler
ne m'étonne pas. Mais que la majorité des formations n'en parle plus, me
surprend.
As-tu eu des ingénieurs frais émoulus dans les pattes récemment ?
Pour faire les généralités que vous avancez je suppose que vous avez
eu entre les pattes un échantillon représentatif d'ingénieurs de chaque
écoles de France et de Navarre ... à moins qu'on vous refile les
derniers de la classe ,de l'école du coin .
J'enseigne dans plusieurs écoles dont Centrale et l'ENST. Ça va comme
échantillon ? J'ai aussi des stagiaires de plusieurs écoles assez
représentatives. Les meilleurs, on les trouve au CNAM.
JKB
ok après être passé entre tes mains ces aspirants ingénieurs sont
déclarés nuls . ça fait peur !
Je n'enseigne qu'_une_ matière.
ne me dis pas que c'est l'informatique stp
JKB a écrit :
Le Thu, 23 Sep 2010 21:35:24 +0200,
sap <doom.666@enfer.fr> écrivait :
Le 23/09/2010 21:20, JKB a écrit :
Le Thu, 23 Sep 2010 20:49:06 +0200,
sap<doom.666@enfer.fr> écrivait :
Le 23/09/2010 20:28, JKB a écrit :
Le Thu, 23 Sep 2010 20:20:15 +0200,
Stephane CARPENTIER<stef.carpentier@free.fr> écrivait :
JKB a écrit:
Est-ce que tu vois la subtile différence entre un tri à la
shell-Metzner et une division ? Lorsque tu parles division à un
ingénieur, il sait de quoi tu parles. Lorsque tu cause tri
shell-Metzner à un ingénieur, il te regarde avec des grands yeux
vides. Il n'a _jamais_ entendu parlé
Ça m'étonne un peu. Que certain ingénieurs n'en aient jamais entendus parler
ne m'étonne pas. Mais que la majorité des formations n'en parle plus, me
surprend.
As-tu eu des ingénieurs frais émoulus dans les pattes récemment ?
Pour faire les généralités que vous avancez je suppose que vous avez
eu entre les pattes un échantillon représentatif d'ingénieurs de chaque
écoles de France et de Navarre ... à moins qu'on vous refile les
derniers de la classe ,de l'école du coin .
J'enseigne dans plusieurs écoles dont Centrale et l'ENST. Ça va comme
échantillon ? J'ai aussi des stagiaires de plusieurs écoles assez
représentatives. Les meilleurs, on les trouve au CNAM.
JKB
ok après être passé entre tes mains ces aspirants ingénieurs sont
déclarés nuls . ça fait peur !
Je n'enseigne qu'_une_ matière.
ne me dis pas que c'est l'informatique stp
JKB a écrit :Le Thu, 23 Sep 2010 21:35:24 +0200,
sap écrivait :Le 23/09/2010 21:20, JKB a écrit :Le Thu, 23 Sep 2010 20:49:06 +0200,
sap écrivait :Le 23/09/2010 20:28, JKB a écrit :Le Thu, 23 Sep 2010 20:20:15 +0200,
Stephane CARPENTIER écrivait :JKB a écrit:Est-ce que tu vois la subtile différence entre un tri à la
shell-Metzner et une division ? Lorsque tu parles division à un
ingénieur, il sait de quoi tu parles. Lorsque tu cause tri
shell-Metzner à un ingénieur, il te regarde avec des grands yeux
vides. Il n'a _jamais_ entendu parlé
Ça m'étonne un peu. Que certain ingénieurs n'en aient jamais entendus parler
ne m'étonne pas. Mais que la majorité des formations n'en parle plus, me
surprend.
As-tu eu des ingénieurs frais émoulus dans les pattes récemment ?
Pour faire les généralités que vous avancez je suppose que vous avez
eu entre les pattes un échantillon représentatif d'ingénieurs de chaque
écoles de France et de Navarre ... à moins qu'on vous refile les
derniers de la classe ,de l'école du coin .
J'enseigne dans plusieurs écoles dont Centrale et l'ENST. Ça va comme
échantillon ? J'ai aussi des stagiaires de plusieurs écoles assez
représentatives. Les meilleurs, on les trouve au CNAM.
JKB
ok après être passé entre tes mains ces aspirants ingénieurs sont
déclarés nuls . ça fait peur !
Je n'enseigne qu'_une_ matière.
ne me dis pas que c'est l'informatique stp
> Peut être que si tu appelais ça "shell sort" comme tout le monde,
> les gens ouvriraient les yeux moins grands. Personnellement je
> n'avais jamais entendu parler de Metzner dans cette affaire, et,
> selon Wikipedia, Metzner n'a jamais contribué à cet algorithme.
Tous mes bouquins appellent ça Shell-Metzner. De toute façon, c'est du
détail, appelle ça Shell-sort si tu veux, le raisonnement reste
valable.
> Peut être que si tu appelais ça "shell sort" comme tout le monde,
> les gens ouvriraient les yeux moins grands. Personnellement je
> n'avais jamais entendu parler de Metzner dans cette affaire, et,
> selon Wikipedia, Metzner n'a jamais contribué à cet algorithme.
Tous mes bouquins appellent ça Shell-Metzner. De toute façon, c'est du
détail, appelle ça Shell-sort si tu veux, le raisonnement reste
valable.
> Peut être que si tu appelais ça "shell sort" comme tout le monde,
> les gens ouvriraient les yeux moins grands. Personnellement je
> n'avais jamais entendu parler de Metzner dans cette affaire, et,
> selon Wikipedia, Metzner n'a jamais contribué à cet algorithme.
Tous mes bouquins appellent ça Shell-Metzner. De toute façon, c'est du
détail, appelle ça Shell-sort si tu veux, le raisonnement reste
valable.
Toxico Nimbus a écrit :Le 23/09/2010 22:58, PP a écrit :L'optimisation DOIT rester dans l'esprit des développeurs pour un tas
d'autres choses encore. Au niveau software certes, mais au niveau
hardware encore plus ! Ce qui semble encore mal barré.
Plus personne n'optimise plus et les clients achètent quand même.
l'optimisation réside dans la modularité du code
en gros ,
l'obj est une manière élégante de rendre modulaire
un traitement et les design pattern permettent d'agencer de manière
élégante les interactions de ses différents traitements
mais ses notions ne servent pas à effectuer un traitement
(par exemple un tri) le traitement lui il est codé une seule fois et
certainement plus optimisé qu'un machin bidule écrit à l'arrache par un
prétendu auto proclamé expert, qui en plus se plante une fois sur 3
le traitement lui il est optimisé, les pouillemes perdus ne sont pas
liés au traitement mais à la notion d'abstraction induite par l'obj
et que cela vous plaise ou pas il s'agit bien de pouillemes
Toxico Nimbus a écrit :
Le 23/09/2010 22:58, PP a écrit :
L'optimisation DOIT rester dans l'esprit des développeurs pour un tas
d'autres choses encore. Au niveau software certes, mais au niveau
hardware encore plus ! Ce qui semble encore mal barré.
Plus personne n'optimise plus et les clients achètent quand même.
l'optimisation réside dans la modularité du code
en gros ,
l'obj est une manière élégante de rendre modulaire
un traitement et les design pattern permettent d'agencer de manière
élégante les interactions de ses différents traitements
mais ses notions ne servent pas à effectuer un traitement
(par exemple un tri) le traitement lui il est codé une seule fois et
certainement plus optimisé qu'un machin bidule écrit à l'arrache par un
prétendu auto proclamé expert, qui en plus se plante une fois sur 3
le traitement lui il est optimisé, les pouillemes perdus ne sont pas
liés au traitement mais à la notion d'abstraction induite par l'obj
et que cela vous plaise ou pas il s'agit bien de pouillemes
Toxico Nimbus a écrit :Le 23/09/2010 22:58, PP a écrit :L'optimisation DOIT rester dans l'esprit des développeurs pour un tas
d'autres choses encore. Au niveau software certes, mais au niveau
hardware encore plus ! Ce qui semble encore mal barré.
Plus personne n'optimise plus et les clients achètent quand même.
l'optimisation réside dans la modularité du code
en gros ,
l'obj est une manière élégante de rendre modulaire
un traitement et les design pattern permettent d'agencer de manière
élégante les interactions de ses différents traitements
mais ses notions ne servent pas à effectuer un traitement
(par exemple un tri) le traitement lui il est codé une seule fois et
certainement plus optimisé qu'un machin bidule écrit à l'arrache par un
prétendu auto proclamé expert, qui en plus se plante une fois sur 3
le traitement lui il est optimisé, les pouillemes perdus ne sont pas
liés au traitement mais à la notion d'abstraction induite par l'obj
et que cela vous plaise ou pas il s'agit bien de pouillemes
purement malhonnête. Maintenant, il y a des optimisations qu'il vaut
mieux penser dès le début ; par exemple quand on voit le coût de
l'interfaçage du Java et du C, on réfléchit à deux fois avant de traiter
un gros volume de données en Java.
--
Toxico Nimbus
purement malhonnête. Maintenant, il y a des optimisations qu'il vaut
mieux penser dès le début ; par exemple quand on voit le coût de
l'interfaçage du Java et du C, on réfléchit à deux fois avant de traiter
un gros volume de données en Java.
--
Toxico Nimbus
purement malhonnête. Maintenant, il y a des optimisations qu'il vaut
mieux penser dès le début ; par exemple quand on voit le coût de
l'interfaçage du Java et du C, on réfléchit à deux fois avant de traiter
un gros volume de données en Java.
--
Toxico Nimbus
Le Fri, 24 Sep 2010 09:33:35 +0200,
remy écrivait :Toxico Nimbus a écrit :Le 23/09/2010 22:58, PP a écrit :L'optimisation DOIT rester dans l'esprit des développeurs pour un tas
d'autres choses encore. Au niveau software certes, mais au niveau
hardware encore plus ! Ce qui semble encore mal barré.
Plus personne n'optimise plus et les clients achètent quand mà ªme.
l'optimisation réside dans la modularité du code
Non (et déjà , il faut définir la modularité, je t' attends).en gros ,
l'obj est une manière élégante de rendre modulaire
un traitement et les design pattern permettent d'agencer de maniè re
élégante les interactions de ses différents traitements
Non. La programmation objet est orthogonale à la programmtion
fonctionnelle. La programmation objet (abjecte ?) n'est là que po ur
masquer le contenu des objets que tu dois expliciter en C ou en
Fortran et créer des boîtes noires. Il n'y a aucune raison d e ne pas
avoir du code élégant écrit dans des langages fonctionn els purs.mais ses notions ne servent pas à effectuer un traitement
(par exemple un tri) le traitement lui il est codé une seule fois et
certainement plus optimisé qu'un machin bidule écrit à l'arrache par un
prétendu auto proclamé expert, qui en plus se plante une foi s sur 3
Non, mais tu es incapable de comprendre pourquoi.le traitement lui il est optimisé, les pouillemes perdus ne sont pas
liés au traitement mais à la notion d'abstraction induite p ar l'obj
et que cela vous plaise ou pas il s'agit bien de pouillemes
Non, triple buse ! Ce ne sont pas des pouillèmes. Je reprends mon
exemple de BOOST et d'un calcul de trajet optimal dans un graphe.
J'y tiens parce que c'est un grand classique. Mais pour les tris, le
même raisonnement s'applique.
Pour calculer un trajet dans un graphe, tu as besoin d'une structure
point qui ressemble à ça (si le graphe est orienté) :
integer sommet_1;
integer sommet_2;
integer arete;
double precision cout_direct;
double precision cout_inverse;
structure qui a sur mon calculateur sparc64 une taille de 40 octets.
La taille de la cartographie (10E6 points) est de 400 Mo.
Si maintenant, tu prends ta fonction optimisée. Tu as une structu re
de graphe générique qui n'a rien à voir. Je te conseill e d'aller
faire un tour dans /usr/include/boost/graph. Cette structure fait
dans les 650 octets par sommet (!) et comporte tout un tas
d'information dont tu n'as que faire parce que cette structure est
générique et que d'autres fonctions travaillant sur les grap hes les
utilisent.
Résultat des courses, tes données occupent 6,5 Go de mé moire là où
400 Mo suffisent. Il y a juste 6,1 Go d'information inutiles. J'aime
bien ta notion du pouillème. Au passage, c'est exactement pour ce la
que pour faire un bête Hello, world ! en Java, il faut déjà beaucoup
de ressources.
Sur une machine munie de 8 Go, tu commences assez vite à swapper
parce que généralement, elle ne fait pas que ça. Et là , ça devient
marrant. Défauts de pages dans tous les sens, mémoire qui se
fragmente et deux façons de faire :
- allocateur best fit : ça rame, les accès disques te font t omber
les perfs d'une manière alarmante mais ça tourne encore;
- allocateur first fit : l'OS alloue la mémoire dans les pages qu i
sont déjà en mémoire centrale et la taille de ton pro cessus gonfle
jusqu'Ã exploser.
Si là , tu n'as pas encore compris pourquoi on n'utilise pas
d'algorithmes génériques quand on veut faire des choses sà ©rieuses
et qu'on ne parle pas de pouillèmes, je ne peux rien pour toi.
Le Fri, 24 Sep 2010 09:33:35 +0200,
remy <remy@fctpas.fr> écrivait :
Toxico Nimbus a écrit :
Le 23/09/2010 22:58, PP a écrit :
L'optimisation DOIT rester dans l'esprit des développeurs pour un tas
d'autres choses encore. Au niveau software certes, mais au niveau
hardware encore plus ! Ce qui semble encore mal barré.
Plus personne n'optimise plus et les clients achètent quand mà ªme.
l'optimisation réside dans la modularité du code
Non (et déjà , il faut définir la modularité, je t' attends).
en gros ,
l'obj est une manière élégante de rendre modulaire
un traitement et les design pattern permettent d'agencer de maniè re
élégante les interactions de ses différents traitements
Non. La programmation objet est orthogonale à la programmtion
fonctionnelle. La programmation objet (abjecte ?) n'est là que po ur
masquer le contenu des objets que tu dois expliciter en C ou en
Fortran et créer des boîtes noires. Il n'y a aucune raison d e ne pas
avoir du code élégant écrit dans des langages fonctionn els purs.
mais ses notions ne servent pas à effectuer un traitement
(par exemple un tri) le traitement lui il est codé une seule fois et
certainement plus optimisé qu'un machin bidule écrit à l'arrache par un
prétendu auto proclamé expert, qui en plus se plante une foi s sur 3
Non, mais tu es incapable de comprendre pourquoi.
le traitement lui il est optimisé, les pouillemes perdus ne sont pas
liés au traitement mais à la notion d'abstraction induite p ar l'obj
et que cela vous plaise ou pas il s'agit bien de pouillemes
Non, triple buse ! Ce ne sont pas des pouillèmes. Je reprends mon
exemple de BOOST et d'un calcul de trajet optimal dans un graphe.
J'y tiens parce que c'est un grand classique. Mais pour les tris, le
même raisonnement s'applique.
Pour calculer un trajet dans un graphe, tu as besoin d'une structure
point qui ressemble à ça (si le graphe est orienté) :
integer sommet_1;
integer sommet_2;
integer arete;
double precision cout_direct;
double precision cout_inverse;
structure qui a sur mon calculateur sparc64 une taille de 40 octets.
La taille de la cartographie (10E6 points) est de 400 Mo.
Si maintenant, tu prends ta fonction optimisée. Tu as une structu re
de graphe générique qui n'a rien à voir. Je te conseill e d'aller
faire un tour dans /usr/include/boost/graph. Cette structure fait
dans les 650 octets par sommet (!) et comporte tout un tas
d'information dont tu n'as que faire parce que cette structure est
générique et que d'autres fonctions travaillant sur les grap hes les
utilisent.
Résultat des courses, tes données occupent 6,5 Go de mé moire là où
400 Mo suffisent. Il y a juste 6,1 Go d'information inutiles. J'aime
bien ta notion du pouillème. Au passage, c'est exactement pour ce la
que pour faire un bête Hello, world ! en Java, il faut déjà beaucoup
de ressources.
Sur une machine munie de 8 Go, tu commences assez vite à swapper
parce que généralement, elle ne fait pas que ça. Et là , ça devient
marrant. Défauts de pages dans tous les sens, mémoire qui se
fragmente et deux façons de faire :
- allocateur best fit : ça rame, les accès disques te font t omber
les perfs d'une manière alarmante mais ça tourne encore;
- allocateur first fit : l'OS alloue la mémoire dans les pages qu i
sont déjà en mémoire centrale et la taille de ton pro cessus gonfle
jusqu'Ã exploser.
Si là , tu n'as pas encore compris pourquoi on n'utilise pas
d'algorithmes génériques quand on veut faire des choses sà ©rieuses
et qu'on ne parle pas de pouillèmes, je ne peux rien pour toi.
Le Fri, 24 Sep 2010 09:33:35 +0200,
remy écrivait :Toxico Nimbus a écrit :Le 23/09/2010 22:58, PP a écrit :L'optimisation DOIT rester dans l'esprit des développeurs pour un tas
d'autres choses encore. Au niveau software certes, mais au niveau
hardware encore plus ! Ce qui semble encore mal barré.
Plus personne n'optimise plus et les clients achètent quand mà ªme.
l'optimisation réside dans la modularité du code
Non (et déjà , il faut définir la modularité, je t' attends).en gros ,
l'obj est une manière élégante de rendre modulaire
un traitement et les design pattern permettent d'agencer de maniè re
élégante les interactions de ses différents traitements
Non. La programmation objet est orthogonale à la programmtion
fonctionnelle. La programmation objet (abjecte ?) n'est là que po ur
masquer le contenu des objets que tu dois expliciter en C ou en
Fortran et créer des boîtes noires. Il n'y a aucune raison d e ne pas
avoir du code élégant écrit dans des langages fonctionn els purs.mais ses notions ne servent pas à effectuer un traitement
(par exemple un tri) le traitement lui il est codé une seule fois et
certainement plus optimisé qu'un machin bidule écrit à l'arrache par un
prétendu auto proclamé expert, qui en plus se plante une foi s sur 3
Non, mais tu es incapable de comprendre pourquoi.le traitement lui il est optimisé, les pouillemes perdus ne sont pas
liés au traitement mais à la notion d'abstraction induite p ar l'obj
et que cela vous plaise ou pas il s'agit bien de pouillemes
Non, triple buse ! Ce ne sont pas des pouillèmes. Je reprends mon
exemple de BOOST et d'un calcul de trajet optimal dans un graphe.
J'y tiens parce que c'est un grand classique. Mais pour les tris, le
même raisonnement s'applique.
Pour calculer un trajet dans un graphe, tu as besoin d'une structure
point qui ressemble à ça (si le graphe est orienté) :
integer sommet_1;
integer sommet_2;
integer arete;
double precision cout_direct;
double precision cout_inverse;
structure qui a sur mon calculateur sparc64 une taille de 40 octets.
La taille de la cartographie (10E6 points) est de 400 Mo.
Si maintenant, tu prends ta fonction optimisée. Tu as une structu re
de graphe générique qui n'a rien à voir. Je te conseill e d'aller
faire un tour dans /usr/include/boost/graph. Cette structure fait
dans les 650 octets par sommet (!) et comporte tout un tas
d'information dont tu n'as que faire parce que cette structure est
générique et que d'autres fonctions travaillant sur les grap hes les
utilisent.
Résultat des courses, tes données occupent 6,5 Go de mé moire là où
400 Mo suffisent. Il y a juste 6,1 Go d'information inutiles. J'aime
bien ta notion du pouillème. Au passage, c'est exactement pour ce la
que pour faire un bête Hello, world ! en Java, il faut déjà beaucoup
de ressources.
Sur une machine munie de 8 Go, tu commences assez vite à swapper
parce que généralement, elle ne fait pas que ça. Et là , ça devient
marrant. Défauts de pages dans tous les sens, mémoire qui se
fragmente et deux façons de faire :
- allocateur best fit : ça rame, les accès disques te font t omber
les perfs d'une manière alarmante mais ça tourne encore;
- allocateur first fit : l'OS alloue la mémoire dans les pages qu i
sont déjà en mémoire centrale et la taille de ton pro cessus gonfle
jusqu'Ã exploser.
Si là , tu n'as pas encore compris pourquoi on n'utilise pas
d'algorithmes génériques quand on veut faire des choses sà ©rieuses
et qu'on ne parle pas de pouillèmes, je ne peux rien pour toi.
Toxico Nimbus wrote:purement malhonnête. Maintenant, il y a des optimisations qu'il vaut
mieux penser dès le début ; par exemple quand on voit le coût de
l'interfaçage du Java et du C, on réfléchit à deux fois avant de traiter
un gros volume de données en Java.
--
Toxico Nimbus
Je ne suis pas du tout un utilisateur de Java, mais je crois que les
performances sont globalement équivalentes à celles du C (idem pour le
Lisp d'ailleurs) donc je ne vois pas ce qui peut te faire dire ça.
D'ailleurs il y a énormément de serveurs très sollicités qui tournent
via Java. Maintenant s'il s'agit de calcul scientifique, comme ce que
fait JKB, alors évidemment c'est Fortran ou C.
Je ne dirais pas la même chose pour des langages qui tournent via un
interpréteur, comme perl, python, etc. Là ça peut passer s'il y a peu de
traîtement et beaucoup d'entrées sorties, ce qui est un cas assez
général, autrement il faut au moins que les parties critiques soient
codées de façon compilée (par exemple pyrex pour python).
Il ne faut pas oublier que Java se débrouille pour fabriquer du code
machine optimisé à l'exécution (HotSpot)
Toxico Nimbus <ToxN@free.fr> wrote:
purement malhonnête. Maintenant, il y a des optimisations qu'il vaut
mieux penser dès le début ; par exemple quand on voit le coût de
l'interfaçage du Java et du C, on réfléchit à deux fois avant de traiter
un gros volume de données en Java.
--
Toxico Nimbus
Je ne suis pas du tout un utilisateur de Java, mais je crois que les
performances sont globalement équivalentes à celles du C (idem pour le
Lisp d'ailleurs) donc je ne vois pas ce qui peut te faire dire ça.
D'ailleurs il y a énormément de serveurs très sollicités qui tournent
via Java. Maintenant s'il s'agit de calcul scientifique, comme ce que
fait JKB, alors évidemment c'est Fortran ou C.
Je ne dirais pas la même chose pour des langages qui tournent via un
interpréteur, comme perl, python, etc. Là ça peut passer s'il y a peu de
traîtement et beaucoup d'entrées sorties, ce qui est un cas assez
général, autrement il faut au moins que les parties critiques soient
codées de façon compilée (par exemple pyrex pour python).
Il ne faut pas oublier que Java se débrouille pour fabriquer du code
machine optimisé à l'exécution (HotSpot)
Toxico Nimbus wrote:purement malhonnête. Maintenant, il y a des optimisations qu'il vaut
mieux penser dès le début ; par exemple quand on voit le coût de
l'interfaçage du Java et du C, on réfléchit à deux fois avant de traiter
un gros volume de données en Java.
--
Toxico Nimbus
Je ne suis pas du tout un utilisateur de Java, mais je crois que les
performances sont globalement équivalentes à celles du C (idem pour le
Lisp d'ailleurs) donc je ne vois pas ce qui peut te faire dire ça.
D'ailleurs il y a énormément de serveurs très sollicités qui tournent
via Java. Maintenant s'il s'agit de calcul scientifique, comme ce que
fait JKB, alors évidemment c'est Fortran ou C.
Je ne dirais pas la même chose pour des langages qui tournent via un
interpréteur, comme perl, python, etc. Là ça peut passer s'il y a peu de
traîtement et beaucoup d'entrées sorties, ce qui est un cas assez
général, autrement il faut au moins que les parties critiques soient
codées de façon compilée (par exemple pyrex pour python).
Il ne faut pas oublier que Java se débrouille pour fabriquer du code
machine optimisé à l'exécution (HotSpot)
JKB a écrit :
mais tu es bouché, la généricité n'est pas dans l'algo qui traite les
données ,mais dans le conteneur qui encapsule la donnée
l'algo est le même ,je répète
je trie un entier
ou je trie un conteneur qui contient un entier
point barre ,la différence s'arrête là
la méthode de tri est la même ,c'est la même ,c'est la même,c'est la
même,après si le mec est assez con pour mettre dans ton conteneur non
pas un entier mais 100k de données
c'est un autre problème, bon d'un autre côté la plupart du temps cela ne
se voit pas ,mais pour des cas limites on peut faire semblant de
réfléchir
JKB a écrit :
mais tu es bouché, la généricité n'est pas dans l'algo qui traite les
données ,mais dans le conteneur qui encapsule la donnée
l'algo est le même ,je répète
je trie un entier
ou je trie un conteneur qui contient un entier
point barre ,la différence s'arrête là
la méthode de tri est la même ,c'est la même ,c'est la même,c'est la
même,après si le mec est assez con pour mettre dans ton conteneur non
pas un entier mais 100k de données
c'est un autre problème, bon d'un autre côté la plupart du temps cela ne
se voit pas ,mais pour des cas limites on peut faire semblant de
réfléchir
JKB a écrit :
mais tu es bouché, la généricité n'est pas dans l'algo qui traite les
données ,mais dans le conteneur qui encapsule la donnée
l'algo est le même ,je répète
je trie un entier
ou je trie un conteneur qui contient un entier
point barre ,la différence s'arrête là
la méthode de tri est la même ,c'est la même ,c'est la même,c'est la
même,après si le mec est assez con pour mettre dans ton conteneur non
pas un entier mais 100k de données
c'est un autre problème, bon d'un autre côté la plupart du temps cela ne
se voit pas ,mais pour des cas limites on peut faire semblant de
réfléchir
