On Mon, 27 Oct 2003 13:54:05 +0000 (UTC) (Michel Talon) wrote:
Je me suis bien gardé de te parler de OpenBSD. Effectivement le benchmark a aussi montré que certains systèmes étaient instables sous forte charge, par exemple FreeBSD-5.1-RELEASE, il a du utiliser une version plus récente pour passer les benchs. Ca aussi est une information utile. Par exemple il dit clairement qu'il n'a eu aucun problème avec NetBSD et que les résultats n'ont jamais été catastrophiques, une information de plus. Conjuguons celà avec les tests qui ont été fait il y a quelque temps de bande passante en pppoa, je vois des résultats extrêmement similaires, dont tu tires les conclusions que tu veux (je sais, tu vas dire que tu te fous des performances ...).
Aller, je me lance dans le troll ;)
Sérieusement, j'ai un peu lu le "papier" en question (rapidement je l'avoue), ce qui me chagrine c'est que ses tests semblent "orientés" (et je dis bien "semblent", je n'ai pas encore eu le temps de lire son code). En gros, quand tu fais du bench et que tu possiblement partisant, si ton bench donne l'un des OS testés (presque) toujours en tête, il y a toujours un doute (juge et partie, tout ça ... )
Sinon, dans l'ensemble le bench en question peut sembler honête, mais ce qui m'embête, quand même, c'est qu'il ai porté une API destiné à l'origine pour Linux (c'est ce qu'il raconte dans l'intro) vers les BSD, or, il ne semble pas si à l'aise que ça sur les BSD, je ne sais pas dans quelle mesure l'usage de cette API influe sur les résultats mais comme je le disais avant, ça peut laisser des doutes ...
On Mon, 27 Oct 2003 13:54:05 +0000 (UTC)
talon@lpthe.jussieu.fr (Michel Talon) wrote:
Je me suis bien gardé de te parler de OpenBSD. Effectivement le
benchmark a aussi montré que certains systèmes étaient instables sous
forte charge, par exemple FreeBSD-5.1-RELEASE, il a du utiliser une
version plus récente pour passer les benchs. Ca aussi est une
information utile. Par exemple il dit clairement qu'il n'a eu aucun
problème avec NetBSD et que les résultats n'ont jamais été
catastrophiques, une information de plus. Conjuguons celà avec les
tests qui ont été fait il y a quelque temps de bande passante en pppoa,
je vois des résultats extrêmement similaires, dont tu tires les
conclusions que tu veux (je sais, tu vas dire que tu te fous des
performances ...).
Aller, je me lance dans le troll ;)
Sérieusement, j'ai un peu lu le "papier" en question (rapidement je
l'avoue), ce qui me chagrine c'est que ses tests semblent "orientés" (et
je dis bien "semblent", je n'ai pas encore eu le temps de lire son code).
En gros, quand tu fais du bench et que tu possiblement partisant, si ton
bench donne l'un des OS testés (presque) toujours en tête, il y a toujours
un doute (juge et partie, tout ça ... )
Sinon, dans l'ensemble le bench en question peut sembler honête, mais ce
qui m'embête, quand même, c'est qu'il ai porté une API destiné à
l'origine pour Linux (c'est ce qu'il raconte dans l'intro) vers les BSD,
or, il ne semble pas si à l'aise que ça sur les BSD, je ne sais pas dans
quelle mesure l'usage de cette API influe sur les résultats mais comme je
le disais avant, ça peut laisser des doutes ...
On Mon, 27 Oct 2003 13:54:05 +0000 (UTC) (Michel Talon) wrote:
Je me suis bien gardé de te parler de OpenBSD. Effectivement le benchmark a aussi montré que certains systèmes étaient instables sous forte charge, par exemple FreeBSD-5.1-RELEASE, il a du utiliser une version plus récente pour passer les benchs. Ca aussi est une information utile. Par exemple il dit clairement qu'il n'a eu aucun problème avec NetBSD et que les résultats n'ont jamais été catastrophiques, une information de plus. Conjuguons celà avec les tests qui ont été fait il y a quelque temps de bande passante en pppoa, je vois des résultats extrêmement similaires, dont tu tires les conclusions que tu veux (je sais, tu vas dire que tu te fous des performances ...).
Aller, je me lance dans le troll ;)
Sérieusement, j'ai un peu lu le "papier" en question (rapidement je l'avoue), ce qui me chagrine c'est que ses tests semblent "orientés" (et je dis bien "semblent", je n'ai pas encore eu le temps de lire son code). En gros, quand tu fais du bench et que tu possiblement partisant, si ton bench donne l'un des OS testés (presque) toujours en tête, il y a toujours un doute (juge et partie, tout ça ... )
Sinon, dans l'ensemble le bench en question peut sembler honête, mais ce qui m'embête, quand même, c'est qu'il ai porté une API destiné à l'origine pour Linux (c'est ce qu'il raconte dans l'intro) vers les BSD, or, il ne semble pas si à l'aise que ça sur les BSD, je ne sais pas dans quelle mesure l'usage de cette API influe sur les résultats mais comme je le disais avant, ça peut laisser des doutes ...
On Sun, 26 Oct 2003 22:44:51 -0800 Vincent Bernat wrote:
Cela ne change absolument rien à ma remarque "sur le papier", comme tu le dis. Le O, c'est de l'asymptotique et comme je te le dis déjà (mais t'as pas dû tilter), je te trouve un algo en *O(n)* sur les *entiers* moins bons qu'un algo classique en *O(nln)*.
Je ne dis pas qu'il ne faut pas essayer de trouver de meilleurs algos, mais tout réduire à des O, c'est très réducteur.
Oui mais non (tm + c je sais pas qui ;)
Il teste le passage à l'echelle en l'occurence, et là entre constant (quelque soit la constante) et n'importe quel O(f(n)) c'est très important, parce que justement quand tu passses à l'echelle, un O(1) finit toujours par être plus intéressant, puisque ton O(f(n)) finit par atteindre cette constante (si ton f(n) est croissant, enfin je n'ai jamais rencontré d'algo avec une complexité décroissante ;)
Le problême de la mémoire reste annecdotique ici, si l'algo est constant en temps (enfin borné par une constante), il sera borné en mémoire également.
On Sun, 26 Oct 2003 22:44:51 -0800
Vincent Bernat <vincent.bernat@raysa.org> wrote:
Cela ne change absolument rien à ma remarque "sur le papier", comme tu
le dis. Le O, c'est de l'asymptotique et comme je te le dis déjà (mais
t'as pas dû tilter), je te trouve un algo en *O(n)* sur les *entiers*
moins bons qu'un algo classique en *O(nln)*.
Je ne dis pas qu'il ne faut pas essayer de trouver de meilleurs algos,
mais tout réduire à des O, c'est très réducteur.
Oui mais non (tm + c je sais pas qui ;)
Il teste le passage à l'echelle en l'occurence, et là entre constant
(quelque soit la constante) et n'importe quel O(f(n)) c'est très
important, parce que justement quand tu passses à l'echelle, un O(1) finit
toujours par être plus intéressant, puisque ton O(f(n)) finit par
atteindre cette constante (si ton f(n) est croissant, enfin je n'ai
jamais rencontré d'algo avec une complexité décroissante ;)
Le problême de la mémoire reste annecdotique ici, si l'algo est constant
en temps (enfin borné par une constante), il sera borné en mémoire
également.
On Sun, 26 Oct 2003 22:44:51 -0800 Vincent Bernat wrote:
Cela ne change absolument rien à ma remarque "sur le papier", comme tu le dis. Le O, c'est de l'asymptotique et comme je te le dis déjà (mais t'as pas dû tilter), je te trouve un algo en *O(n)* sur les *entiers* moins bons qu'un algo classique en *O(nln)*.
Je ne dis pas qu'il ne faut pas essayer de trouver de meilleurs algos, mais tout réduire à des O, c'est très réducteur.
Oui mais non (tm + c je sais pas qui ;)
Il teste le passage à l'echelle en l'occurence, et là entre constant (quelque soit la constante) et n'importe quel O(f(n)) c'est très important, parce que justement quand tu passses à l'echelle, un O(1) finit toujours par être plus intéressant, puisque ton O(f(n)) finit par atteindre cette constante (si ton f(n) est croissant, enfin je n'ai jamais rencontré d'algo avec une complexité décroissante ;)
Le problême de la mémoire reste annecdotique ici, si l'algo est constant en temps (enfin borné par une constante), il sera borné en mémoire également.
C'est marrant, mais dans les mailing lists freebsd les gens ont discuté de ce benchmark trés sérieusement, et y attachent de l'importance.
Oui, sur NetBSD ca a été aussi pas mal l'ebullition. Je trouve ce test très bien ca pointe du doigt les endroits où une bonne amélioration ne fait pas de mal.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Michel Talon <talon@lpthe.jussieu.fr> wrote:
C'est marrant, mais dans les mailing lists freebsd les gens ont discuté
de ce benchmark trés sérieusement, et y attachent de l'importance.
Oui, sur NetBSD ca a été aussi pas mal l'ebullition. Je trouve ce test
très bien ca pointe du doigt les endroits où une bonne amélioration ne
fait pas de mal.
--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
C'est marrant, mais dans les mailing lists freebsd les gens ont discuté de ce benchmark trés sérieusement, et y attachent de l'importance.
Oui, sur NetBSD ca a été aussi pas mal l'ebullition. Je trouve ce test très bien ca pointe du doigt les endroits où une bonne amélioration ne fait pas de mal.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Vincent Bernat
OoO En ce début d'après-midi nuageux du lundi 27 octobre 2003, vers 14:37, Marwan "FeanoR/var" Burelle disait:
Cela ne change absolument rien à ma remarque "sur le papier", comme tu le dis. Le O, c'est de l'asymptotique et comme je te le dis déjà (mais t'as pas dû tilter), je te trouve un algo en *O(n)* sur les *entiers* moins bons qu'un algo classique en *O(nln)*.
Je ne dis pas qu'il ne faut pas essayer de trouver de meilleurs algos, mais tout réduire à des O, c'est très réducteur.
Oui mais non (tm + c je sais pas qui ;)
Pareil.
Il teste le passage à l'echelle en l'occurence, et là entre constant (quelque soit la constante) et n'importe quel O(f(n)) c'est très important, parce que justement quand tu passses à l'echelle, un O(1) finit toujours par être plus intéressant, puisque ton O(f(n)) finit par atteindre cette constante (si ton f(n) est croissant, enfin je n'ai jamais rencontré d'algo avec une complexité décroissante ;)
Mais si la constante est de l'ordre de 100000 (par exemple) pour l'algo en temps constant et que l'on prend le nombre de process, tu n'en sais rien si tu arriveras effectivement au point où le O(1) devient plus intéressant que le O(n). C'est la seule chose que je voulais pointer ici avec mon algo de tri en O(n) contre les classiques O(nlogn).
Ça me chagrine que personne ne m'ait dit que c'était pas possible de trier des entiers en O(n). :) -- I WILL NOT CREATE ART FROM DUNG I WILL NOT CREATE ART FROM DUNG I WILL NOT CREATE ART FROM DUNG -+- Bart Simpson on chalkboard in episode BABF04
OoO En ce début d'après-midi nuageux du lundi 27 octobre 2003, vers
14:37, Marwan "FeanoR/var" Burelle <burelle@lri.fr> disait:
Cela ne change absolument rien à ma remarque "sur le papier", comme tu
le dis. Le O, c'est de l'asymptotique et comme je te le dis déjà (mais
t'as pas dû tilter), je te trouve un algo en *O(n)* sur les *entiers*
moins bons qu'un algo classique en *O(nln)*.
Je ne dis pas qu'il ne faut pas essayer de trouver de meilleurs algos,
mais tout réduire à des O, c'est très réducteur.
Oui mais non (tm + c je sais pas qui ;)
Pareil.
Il teste le passage à l'echelle en l'occurence, et là entre constant
(quelque soit la constante) et n'importe quel O(f(n)) c'est très
important, parce que justement quand tu passses à l'echelle, un O(1) finit
toujours par être plus intéressant, puisque ton O(f(n)) finit par
atteindre cette constante (si ton f(n) est croissant, enfin je n'ai
jamais rencontré d'algo avec une complexité décroissante ;)
Mais si la constante est de l'ordre de 100000 (par exemple) pour
l'algo en temps constant et que l'on prend le nombre de process, tu
n'en sais rien si tu arriveras effectivement au point où le O(1)
devient plus intéressant que le O(n). C'est la seule chose que je
voulais pointer ici avec mon algo de tri en O(n) contre les classiques
O(nlogn).
Ça me chagrine que personne ne m'ait dit que c'était pas possible de
trier des entiers en O(n). :)
--
I WILL NOT CREATE ART FROM DUNG
I WILL NOT CREATE ART FROM DUNG
I WILL NOT CREATE ART FROM DUNG
-+- Bart Simpson on chalkboard in episode BABF04
OoO En ce début d'après-midi nuageux du lundi 27 octobre 2003, vers 14:37, Marwan "FeanoR/var" Burelle disait:
Cela ne change absolument rien à ma remarque "sur le papier", comme tu le dis. Le O, c'est de l'asymptotique et comme je te le dis déjà (mais t'as pas dû tilter), je te trouve un algo en *O(n)* sur les *entiers* moins bons qu'un algo classique en *O(nln)*.
Je ne dis pas qu'il ne faut pas essayer de trouver de meilleurs algos, mais tout réduire à des O, c'est très réducteur.
Oui mais non (tm + c je sais pas qui ;)
Pareil.
Il teste le passage à l'echelle en l'occurence, et là entre constant (quelque soit la constante) et n'importe quel O(f(n)) c'est très important, parce que justement quand tu passses à l'echelle, un O(1) finit toujours par être plus intéressant, puisque ton O(f(n)) finit par atteindre cette constante (si ton f(n) est croissant, enfin je n'ai jamais rencontré d'algo avec une complexité décroissante ;)
Mais si la constante est de l'ordre de 100000 (par exemple) pour l'algo en temps constant et que l'on prend le nombre de process, tu n'en sais rien si tu arriveras effectivement au point où le O(1) devient plus intéressant que le O(n). C'est la seule chose que je voulais pointer ici avec mon algo de tri en O(n) contre les classiques O(nlogn).
Ça me chagrine que personne ne m'ait dit que c'était pas possible de trier des entiers en O(n). :) -- I WILL NOT CREATE ART FROM DUNG I WILL NOT CREATE ART FROM DUNG I WILL NOT CREATE ART FROM DUNG -+- Bart Simpson on chalkboard in episode BABF04
Arnaud Launay
Le Tue, 28 Oct 2003 00:13:31 +0100, Emmanuel Dreyfus écrivit:
C'est marrant, mais dans les mailing lists freebsd les gens ont discuté de ce benchmark trés sérieusement, et y attachent de l'importance. Oui, sur NetBSD ca a été aussi pas mal l'ebullition. Je trouve ce test
très bien ca pointe du doigt les endroits où une bonne amélioration ne fait pas de mal.
Il n'y a guère que chez open qu'ils n'en ont rien à foutre.
Arnaud. -- Happiness is something money can't buy. Lourds et aigris, mais on aime ça. HLFL 0.60.1 !! Look here: http://www.hlfl.org/
Le Tue, 28 Oct 2003 00:13:31 +0100, Emmanuel Dreyfus écrivit:
C'est marrant, mais dans les mailing lists freebsd les gens ont discuté
de ce benchmark trés sérieusement, et y attachent de l'importance.
Oui, sur NetBSD ca a été aussi pas mal l'ebullition. Je trouve ce test
très bien ca pointe du doigt les endroits où une bonne amélioration ne
fait pas de mal.
Il n'y a guère que chez open qu'ils n'en ont rien à foutre.
Arnaud.
--
Happiness is something money can't buy.
Lourds et aigris, mais on aime ça.
HLFL 0.60.1 !! Look here: http://www.hlfl.org/
Le Tue, 28 Oct 2003 00:13:31 +0100, Emmanuel Dreyfus écrivit:
C'est marrant, mais dans les mailing lists freebsd les gens ont discuté de ce benchmark trés sérieusement, et y attachent de l'importance. Oui, sur NetBSD ca a été aussi pas mal l'ebullition. Je trouve ce test
très bien ca pointe du doigt les endroits où une bonne amélioration ne fait pas de mal.
Il n'y a guère que chez open qu'ils n'en ont rien à foutre.
Arnaud. -- Happiness is something money can't buy. Lourds et aigris, mais on aime ça. HLFL 0.60.1 !! Look here: http://www.hlfl.org/
talon
Marwan FeanoR/var Burelle wrote:
Sinon, dans l'ensemble le bench en question peut sembler honête, mais ce qui m'embête, quand même, c'est qu'il ai porté une API destiné à l'origine pour Linux (c'est ce qu'il raconte dans l'intro) vers les BSD, or, il ne semble pas si à l'aise que ça sur les BSD, je ne sais pas dans quelle mesure l'usage de cette API influe sur les résultats mais comme je le disais avant, ça peut laisser des doutes ...
En effet il ne semble pas à l'aise sur les BSD, donc il est possible que les résultats sur BSD soient "pessimaux" par rapport à ceux sur Linux. Celà étant les résultats sur FreeBSD-5.1 sont pratiquement identiques à ceux sur Linux-2.6 et il a l'honnêteté de remarquer que cette version de FreeBSD est encore expérimentale et possède plein de codes de debug qui ralentissent le système. Donc grosso modo ses conclusions sont que Linux-2.6 et FreeBSD-CURRENT jouent dans la même cour, Linux-2.4, FreeBSD-STABLE dans la cour du dessous, NetBSD a toujours été fiable mais moins performant, et OpenBSD a été calamiteux. Mis à part le dernier résultat, est-ce que ça surprend grand monde?
--
Michel TALON
Marwan FeanoR/var Burelle <burelle@lri.fr> wrote:
Sinon, dans l'ensemble le bench en question peut sembler honête, mais ce
qui m'embête, quand même, c'est qu'il ai porté une API destiné à
l'origine pour Linux (c'est ce qu'il raconte dans l'intro) vers les BSD,
or, il ne semble pas si à l'aise que ça sur les BSD, je ne sais pas dans
quelle mesure l'usage de cette API influe sur les résultats mais comme je
le disais avant, ça peut laisser des doutes ...
En effet il ne semble pas à l'aise sur les BSD, donc il est possible que
les résultats sur BSD soient "pessimaux" par rapport à ceux sur Linux.
Celà étant les résultats sur FreeBSD-5.1 sont pratiquement identiques à
ceux sur Linux-2.6 et il a l'honnêteté de remarquer que cette version de
FreeBSD est encore expérimentale et possède plein de codes de debug qui
ralentissent le système. Donc grosso modo ses conclusions sont que
Linux-2.6 et FreeBSD-CURRENT jouent dans la même cour, Linux-2.4,
FreeBSD-STABLE dans la cour du dessous, NetBSD a toujours été fiable
mais moins performant, et OpenBSD a été calamiteux. Mis à part le
dernier résultat, est-ce que ça surprend grand monde?
Sinon, dans l'ensemble le bench en question peut sembler honête, mais ce qui m'embête, quand même, c'est qu'il ai porté une API destiné à l'origine pour Linux (c'est ce qu'il raconte dans l'intro) vers les BSD, or, il ne semble pas si à l'aise que ça sur les BSD, je ne sais pas dans quelle mesure l'usage de cette API influe sur les résultats mais comme je le disais avant, ça peut laisser des doutes ...
En effet il ne semble pas à l'aise sur les BSD, donc il est possible que les résultats sur BSD soient "pessimaux" par rapport à ceux sur Linux. Celà étant les résultats sur FreeBSD-5.1 sont pratiquement identiques à ceux sur Linux-2.6 et il a l'honnêteté de remarquer que cette version de FreeBSD est encore expérimentale et possède plein de codes de debug qui ralentissent le système. Donc grosso modo ses conclusions sont que Linux-2.6 et FreeBSD-CURRENT jouent dans la même cour, Linux-2.4, FreeBSD-STABLE dans la cour du dessous, NetBSD a toujours été fiable mais moins performant, et OpenBSD a été calamiteux. Mis à part le dernier résultat, est-ce que ça surprend grand monde?
--
Michel TALON
Étienne 'Tinou' Labaume
Le Mon, 27 Oct 2003 16:40:57 -0800, Vincent nous disait:
Ça me chagrine que personne ne m'ait dit que c'était pas possible de trier des entiers en O(n). :)
Vincent, j'ai de gros doutes quand à la possibilité de trier des entiers en O(n) ...
-- Tinou Vazy, montre-le ton gros algo :-)
Le Mon, 27 Oct 2003 16:40:57 -0800, Vincent nous disait:
Ça me chagrine que personne ne m'ait dit que c'était pas possible de
trier des entiers en O(n). :)
Vincent, j'ai de gros doutes quand à la possibilité de trier des entiers
en O(n) ...
Le Mon, 27 Oct 2003 16:40:57 -0800, Vincent nous disait:
Ça me chagrine que personne ne m'ait dit que c'était pas possible de trier des entiers en O(n). :)
Vincent, j'ai de gros doutes quand à la possibilité de trier des entiers en O(n) ...
Si, à condition que ces entiers soient bornés (borne connue a priori) et avec une mémoire en O(borne)...
-- Erwan
Vincent Bernat
OoO En cette nuit nuageuse du mardi 28 octobre 2003, vers 01:09, Étienne 'Tinou' Labaume disait:
Ça me chagrine que personne ne m'ait dit que c'était pas possible de trier des entiers en O(n). :)
Vincent, j'ai de gros doutes quand à la possibilité de trier des entiers en O(n) ...
Aaahh ! :) Comme le dit Erwan en réponse, il s'agit d'entiers "informatiques" et on peut utiliser un algorithme dérivé du drapeau de Djikistra (pardonnez moi l'écorchure s'il y a). -- BOFH excuse #55: Plumber mistook routing panel for decorative wall fixture
OoO En cette nuit nuageuse du mardi 28 octobre 2003, vers 01:09,
Étienne 'Tinou' Labaume <labaume@enseirb.fr> disait:
Ça me chagrine que personne ne m'ait dit que c'était pas possible de
trier des entiers en O(n). :)
Vincent, j'ai de gros doutes quand à la possibilité de trier des entiers
en O(n) ...
Aaahh ! :)
Comme le dit Erwan en réponse, il s'agit d'entiers "informatiques" et
on peut utiliser un algorithme dérivé du drapeau de Djikistra
(pardonnez moi l'écorchure s'il y a).
--
BOFH excuse #55:
Plumber mistook routing panel for decorative wall fixture
OoO En cette nuit nuageuse du mardi 28 octobre 2003, vers 01:09, Étienne 'Tinou' Labaume disait:
Ça me chagrine que personne ne m'ait dit que c'était pas possible de trier des entiers en O(n). :)
Vincent, j'ai de gros doutes quand à la possibilité de trier des entiers en O(n) ...
Aaahh ! :) Comme le dit Erwan en réponse, il s'agit d'entiers "informatiques" et on peut utiliser un algorithme dérivé du drapeau de Djikistra (pardonnez moi l'écorchure s'il y a). -- BOFH excuse #55: Plumber mistook routing panel for decorative wall fixture
Arnaud Launay
Le Tue, 28 Oct 2003 11:41:24 -0800, Vincent Bernat écrivit:
on peut utiliser un algorithme dérivé du drapeau de Djikistra
Dijkstra.
(pardonnez moi l'écorchure s'il y a).
Non.
Arnaud. -- Happiness is something money can't buy. Lourds et aigris, mais on aime ça. HLFL 0.60.1 !! Look here: http://www.hlfl.org/
Le Tue, 28 Oct 2003 11:41:24 -0800, Vincent Bernat écrivit:
on peut utiliser un algorithme dérivé du drapeau de Djikistra
Dijkstra.
(pardonnez moi l'écorchure s'il y a).
Non.
Arnaud.
--
Happiness is something money can't buy.
Lourds et aigris, mais on aime ça.
HLFL 0.60.1 !! Look here: http://www.hlfl.org/
