On peut parfois le faire, par exemple comparer FreeBSD 5.1 et Linux 2.4 (Redhat, Debian). On verra par exemple que la couche NFS de Linux est assez pitoyable au niveau compatibilité, elle rend des permissions denied alors que FreeBSD liste le repertoire correctement. Je ne comprends pas ta démonstration, pourrais-tu la détailler ?
Euh, je voudrais bien, mais en fait, j'ai triché. Le serveur est sous Windows, il est donc assez peu souvent en état de fonctionner...
[ ~]% cd /home/nlescoua cd: resource temporarily unavailable: /home/nlescoua
(Disons 18h/24h par jour depuis 3 semaines).
Mais quand il fonctionne, j'ai un rwx--x--x nlescoua root et Linux ne peut pas faire de ls. je peux lire et ecrire les fichiers en donnant le nom.
Par contre, sous FreeBSD, ca marche très bien.
Mais bon, l'essentiel de cet démonstration amene a conclure que choisir Windows pour faire un serveur de fichier est un mauvais choix, surtout si ce serveur doit en plus faire du NFS...
-- Nicolas Le Scouarnec http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
On peut parfois le faire, par exemple comparer FreeBSD 5.1 et Linux 2.4
(Redhat, Debian). On verra par exemple que la couche NFS de Linux est
assez pitoyable au niveau compatibilité, elle rend des permissions
denied alors que FreeBSD liste le repertoire correctement.
Je ne comprends pas ta démonstration, pourrais-tu la détailler ?
Euh, je voudrais bien, mais en fait, j'ai triché. Le serveur est sous
Windows, il est donc assez peu souvent en état de fonctionner...
[nlsn@lea ~]% cd /home/nlescoua
cd: resource temporarily unavailable: /home/nlescoua
(Disons 18h/24h par jour depuis 3 semaines).
Mais quand il fonctionne, j'ai un
rwx--x--x nlescoua root et Linux ne peut pas faire de ls.
je peux lire et ecrire les
fichiers en donnant le nom.
Par contre, sous FreeBSD, ca
marche très bien.
Mais bon, l'essentiel de cet démonstration amene a conclure que choisir
Windows pour faire un serveur de fichier est un mauvais choix, surtout
si ce serveur doit en plus faire du NFS...
--
Nicolas Le Scouarnec
http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
On peut parfois le faire, par exemple comparer FreeBSD 5.1 et Linux 2.4 (Redhat, Debian). On verra par exemple que la couche NFS de Linux est assez pitoyable au niveau compatibilité, elle rend des permissions denied alors que FreeBSD liste le repertoire correctement. Je ne comprends pas ta démonstration, pourrais-tu la détailler ?
Euh, je voudrais bien, mais en fait, j'ai triché. Le serveur est sous Windows, il est donc assez peu souvent en état de fonctionner...
[ ~]% cd /home/nlescoua cd: resource temporarily unavailable: /home/nlescoua
(Disons 18h/24h par jour depuis 3 semaines).
Mais quand il fonctionne, j'ai un rwx--x--x nlescoua root et Linux ne peut pas faire de ls. je peux lire et ecrire les fichiers en donnant le nom.
Par contre, sous FreeBSD, ca marche très bien.
Mais bon, l'essentiel de cet démonstration amene a conclure que choisir Windows pour faire un serveur de fichier est un mauvais choix, surtout si ce serveur doit en plus faire du NFS...
-- Nicolas Le Scouarnec http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
Manuel Bouyer
Emmanuel Dreyfus wrote:
Arnaud Launay wrote:
Oui mais non, personne ne s'en sert de ce truc... Et alors? Je le fais pour moi, je veux utiliser sous NetBSD
les logiciels que j'ai acheté pour MacOS X. Au lieu d'acheter des logiciels, et de concevoir une couche de
compatibiiité, tu ferais mieux d'écrire un équivalent sous une vraie licence.
Ca va plus vite d'ecrire COMPAT_DARWIN.
C'est pas ce que tu m'avais repondu quand je t'avais suggere ca. Il me semble que la reponse c'etait "c'est plus rigolo". Mais bon peut-etre que je me souviens pas bien ... :)
-- Manuel Bouyer NetBSD: 24 ans d'experience feront toujours la difference --
Oui mais non, personne ne s'en sert de ce truc...
Et alors? Je le fais pour moi, je veux utiliser sous NetBSD
les logiciels que j'ai acheté pour MacOS X.
Au lieu d'acheter des logiciels, et de concevoir une couche de
compatibiiité, tu ferais mieux d'écrire un équivalent sous une
vraie licence.
Ca va plus vite d'ecrire COMPAT_DARWIN.
C'est pas ce que tu m'avais repondu quand je t'avais suggere ca.
Il me semble que la reponse c'etait "c'est plus rigolo".
Mais bon peut-etre que je me souviens pas bien ... :)
--
Manuel Bouyer <bouyer@nerim.net>
NetBSD: 24 ans d'experience feront toujours la difference
--
Oui mais non, personne ne s'en sert de ce truc... Et alors? Je le fais pour moi, je veux utiliser sous NetBSD
les logiciels que j'ai acheté pour MacOS X. Au lieu d'acheter des logiciels, et de concevoir une couche de
compatibiiité, tu ferais mieux d'écrire un équivalent sous une vraie licence.
Ca va plus vite d'ecrire COMPAT_DARWIN.
C'est pas ce que tu m'avais repondu quand je t'avais suggere ca. Il me semble que la reponse c'etait "c'est plus rigolo". Mais bon peut-etre que je me souviens pas bien ... :)
-- Manuel Bouyer NetBSD: 24 ans d'experience feront toujours la difference --
manu
Manuel Bouyer wrote:
Ca va plus vite d'ecrire COMPAT_DARWIN. C'est pas ce que tu m'avais repondu quand je t'avais suggere ca.
Il me semble que la reponse c'etait "c'est plus rigolo". Mais bon peut-etre que je me souviens pas bien ... :)
Ah oui, c'est aussi beaucoup plus rigolo :o)
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Manuel Bouyer <bouyer@nerim.net> wrote:
Ca va plus vite d'ecrire COMPAT_DARWIN.
C'est pas ce que tu m'avais repondu quand je t'avais suggere ca.
Il me semble que la reponse c'etait "c'est plus rigolo".
Mais bon peut-etre que je me souviens pas bien ... :)
Ah oui, c'est aussi beaucoup plus rigolo :o)
--
Emmanuel Dreyfus
Un bouquin en français sur BSD:
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
Ca va plus vite d'ecrire COMPAT_DARWIN. C'est pas ce que tu m'avais repondu quand je t'avais suggere ca.
Il me semble que la reponse c'etait "c'est plus rigolo". Mais bon peut-etre que je me souviens pas bien ... :)
Ah oui, c'est aussi beaucoup plus rigolo :o)
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu
Vincent Bernat wrote:
J'ai choisi la deuxieme solution. Les drivers sont bien avancés, le serveur X pour MacOS X est presque capable de tourner (il ne reste que des problèmes avec les codes des touches renvoyées au clavier), ensuite je travaillerai sur le serveur Quartz. C'est documenté tout ça ?
Un peu, mais le reverse engineering prends toujours beaucoup de place dans ce genre de projet. J'ai quelques programes de tests qui explorent les comportements du driver IOHIDSystem.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Vincent Bernat <vincent.bernat@raysa.org> wrote:
J'ai choisi la deuxieme solution. Les drivers sont bien avancés, le
serveur X pour MacOS X est presque capable de tourner (il ne reste que
des problèmes avec les codes des touches renvoyées au clavier), ensuite
je travaillerai sur le serveur Quartz.
C'est documenté tout ça ?
Un peu, mais le reverse engineering prends toujours beaucoup de place
dans ce genre de projet. J'ai quelques programes de tests qui explorent
les comportements du driver IOHIDSystem.
--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
J'ai choisi la deuxieme solution. Les drivers sont bien avancés, le serveur X pour MacOS X est presque capable de tourner (il ne reste que des problèmes avec les codes des touches renvoyées au clavier), ensuite je travaillerai sur le serveur Quartz. C'est documenté tout ça ?
Un peu, mais le reverse engineering prends toujours beaucoup de place dans ce genre de projet. J'ai quelques programes de tests qui explorent les comportements du driver IOHIDSystem.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu
Arnaud wrote:
Oui, même moi qui n'ai (presque) jamais programmé et aucune connaissance en matière de fonctionnement d'OS, j'arrive à comprendre certaines choses dans les articles d'Emmanuel, et même à les trouver intéressantes...
Je suis très touché.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Oui, même moi qui n'ai (presque) jamais programmé et aucune connaissance
en matière de fonctionnement d'OS, j'arrive à comprendre certaines
choses dans les articles d'Emmanuel, et même à les trouver
intéressantes...
Je suis très touché.
--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
Oui, même moi qui n'ai (presque) jamais programmé et aucune connaissance en matière de fonctionnement d'OS, j'arrive à comprendre certaines choses dans les articles d'Emmanuel, et même à les trouver intéressantes...
Je suis très touché.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu
Julien wrote:
C'est sérieux tout ca ? Je pourrais avoir plus de renseignement à quel URL ?
http://hcpnet.free.fr/applebsd.html
Je n'ai pas remis à jour la page depuis longtemps. En particulier, les progres sur les drivers et sur le serveur X n'y sont pas encore.
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Julien <julien@nospam.net> wrote:
C'est sérieux tout ca ? Je pourrais avoir plus de renseignement à quel URL ?
http://hcpnet.free.fr/applebsd.html
Je n'ai pas remis à jour la page depuis longtemps. En particulier, les
progres sur les drivers et sur le serveur X n'y sont pas encore.
--
Emmanuel Dreyfus
Un bouquin en français sur BSD:
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
C'est sérieux tout ca ? Je pourrais avoir plus de renseignement à quel URL ?
http://hcpnet.free.fr/applebsd.html
Je n'ai pas remis à jour la page depuis longtemps. En particulier, les progres sur les drivers et sur le serveur X n'y sont pas encore.
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
mips
On Tue, 21 Oct 2003 09:04:28 +0000 (UTC) (Thomas Pornin) wrote:
Le test, il vaut ce qu'il vaut, et on peut faire dire beaucoup de chosesà quelques malheureux chiffres ; mais quand je vois les OpenBSDistes se mobiliser comme ça pour dire du mal du testeur, je trouve ça louche et je me dis qu'il y a peut-être alors un peu de vrai dans cette histoire de performances qui ne sont pas à la hauteur. En plus, ça m'évoque irrésistiblement les piailleries des Linuxiens quand Netcraft a déclaré que Windows allait plus vite que RedHat.
Il me semble que le projet OpenBSD n'a jamais cache qu'il preferait la securite aux performances. Il ne me semble pas non plus qu'il ai ete dit qu'OpenBSD rivalisait sans probleme avec les autres Os en termes de performances. Bref je te trouve toujours petit joueur sur le troll.
D'ailleurs, chaque fois que je crois Marc et qu'on cause de son logiciel du moment (egcs, OpenBSD...), je lui fait part des problèmes que j'ai eu avec (l'egcs pond du code 10% plus lent et met deux fois plus de temps, l'OpenBSD sur Alpha il a pas de libs dynamiques et ça raaaaaame), il me répond invariablement "ah mais faut prendre le tout dernier snapshot CVS, ça va beaucoup mieux, le problème est réglé" (et, invariablement, le dernier snapshot ne règle rien, ou apporte d'autres problèmes encore plus pénibles). C'est un comportement dont je constate encore aujourd'hui la continuité dans le temps. Le truc bizarre, c'est que c'est plutôt la spécialité des Macounets, habituellement ("mais si, le prochain MacOS X ira vite, c'est juste que la version actuelle n'a pasété optimisée afin d'avoir plus de fonctionalités et d'être plus stable"-- répété à chaque version, ça lasse).
On attends tes patches ...
Indépendamment des histoires d'IPv6 et du GUI (et force est de reconnaître que le manque d'IPv4 via IPv6 a un look un peu arbitraire et pénible, vu que les autres BSD savent faire), le
Ah oui effectivement, les autres se jettent de la falaise alors forcement il faut forcement que je fasse pareil. A priori meme les informaticiens ont l'instinct gregaire.
testeur montre quand même un certain nombre de mesures où OpenBSD ne monte pas bien en puissance, et je ne vois pas beaucoup de gens qui regardent effectivement le code pour dire "mais non, le gars s'est trompé, regardez l'algo, on est en O(1), pas O(n)".
C'est clair que vu le debut du test beaucoup n'ont pas cherche plus loin.
mips
On Tue, 21 Oct 2003 09:04:28 +0000 (UTC)
pornin@nerim.net (Thomas Pornin) wrote:
Le test, il vaut ce qu'il vaut, et on peut faire dire beaucoup de
chosesà quelques malheureux chiffres ; mais quand je vois les
OpenBSDistes se mobiliser comme ça pour dire du mal du testeur, je
trouve ça louche et je me dis qu'il y a peut-être alors un peu de
vrai dans cette histoire de performances qui ne sont pas à la
hauteur. En plus, ça m'évoque irrésistiblement les piailleries des
Linuxiens quand Netcraft a déclaré que Windows allait plus vite que
RedHat.
Il me semble que le projet OpenBSD n'a jamais cache qu'il preferait la
securite aux performances. Il ne me semble pas non plus qu'il ai ete
dit qu'OpenBSD rivalisait sans probleme avec les autres Os en termes
de performances.
Bref je te trouve toujours petit joueur sur le troll.
D'ailleurs, chaque fois que je crois Marc et qu'on cause de son
logiciel du moment (egcs, OpenBSD...), je lui fait part des
problèmes que j'ai eu avec (l'egcs pond du code 10% plus lent et met
deux fois plus de temps, l'OpenBSD sur Alpha il a pas de libs
dynamiques et ça raaaaaame), il me répond invariablement "ah mais
faut prendre le tout dernier snapshot CVS, ça va beaucoup mieux, le
problème est réglé" (et, invariablement, le dernier snapshot ne
règle rien, ou apporte d'autres problèmes encore plus pénibles).
C'est un comportement dont je constate encore aujourd'hui la
continuité dans le temps. Le truc bizarre, c'est que c'est plutôt la
spécialité des Macounets, habituellement ("mais si, le prochain
MacOS X ira vite, c'est juste que la version actuelle n'a pasété
optimisée afin d'avoir plus de fonctionalités et d'être plus
stable"-- répété à chaque version, ça lasse).
On attends tes patches ...
Indépendamment des histoires d'IPv6 et du GUI (et force est de
reconnaître que le manque d'IPv4 via IPv6 a un look un peu
arbitraire et pénible, vu que les autres BSD savent faire), le
Ah oui effectivement, les autres se jettent de la falaise alors
forcement il faut forcement que je fasse pareil. A priori meme les
informaticiens ont l'instinct gregaire.
testeur montre quand même un certain nombre de mesures où OpenBSD ne
monte pas bien en puissance, et je ne vois pas beaucoup de gens qui
regardent effectivement le code pour dire "mais non, le gars s'est
trompé, regardez l'algo, on est en O(1), pas O(n)".
C'est clair que vu le debut du test beaucoup n'ont pas cherche plus loin.
On Tue, 21 Oct 2003 09:04:28 +0000 (UTC) (Thomas Pornin) wrote:
Le test, il vaut ce qu'il vaut, et on peut faire dire beaucoup de chosesà quelques malheureux chiffres ; mais quand je vois les OpenBSDistes se mobiliser comme ça pour dire du mal du testeur, je trouve ça louche et je me dis qu'il y a peut-être alors un peu de vrai dans cette histoire de performances qui ne sont pas à la hauteur. En plus, ça m'évoque irrésistiblement les piailleries des Linuxiens quand Netcraft a déclaré que Windows allait plus vite que RedHat.
Il me semble que le projet OpenBSD n'a jamais cache qu'il preferait la securite aux performances. Il ne me semble pas non plus qu'il ai ete dit qu'OpenBSD rivalisait sans probleme avec les autres Os en termes de performances. Bref je te trouve toujours petit joueur sur le troll.
D'ailleurs, chaque fois que je crois Marc et qu'on cause de son logiciel du moment (egcs, OpenBSD...), je lui fait part des problèmes que j'ai eu avec (l'egcs pond du code 10% plus lent et met deux fois plus de temps, l'OpenBSD sur Alpha il a pas de libs dynamiques et ça raaaaaame), il me répond invariablement "ah mais faut prendre le tout dernier snapshot CVS, ça va beaucoup mieux, le problème est réglé" (et, invariablement, le dernier snapshot ne règle rien, ou apporte d'autres problèmes encore plus pénibles). C'est un comportement dont je constate encore aujourd'hui la continuité dans le temps. Le truc bizarre, c'est que c'est plutôt la spécialité des Macounets, habituellement ("mais si, le prochain MacOS X ira vite, c'est juste que la version actuelle n'a pasété optimisée afin d'avoir plus de fonctionalités et d'être plus stable"-- répété à chaque version, ça lasse).
On attends tes patches ...
Indépendamment des histoires d'IPv6 et du GUI (et force est de reconnaître que le manque d'IPv4 via IPv6 a un look un peu arbitraire et pénible, vu que les autres BSD savent faire), le
Ah oui effectivement, les autres se jettent de la falaise alors forcement il faut forcement que je fasse pareil. A priori meme les informaticiens ont l'instinct gregaire.
testeur montre quand même un certain nombre de mesures où OpenBSD ne monte pas bien en puissance, et je ne vois pas beaucoup de gens qui regardent effectivement le code pour dire "mais non, le gars s'est trompé, regardez l'algo, on est en O(1), pas O(n)".
C'est clair que vu le debut du test beaucoup n'ont pas cherche plus loin.
mips
mips
On Wed, 22 Oct 2003 09:38:36 +0200 (Emmanuel Dreyfus) wrote:
mips wrote:
Franchement je pense que peu de vrais BSDistes ont vraiment frole l'hysterie. Ce papier repose sur une mauvaise base ce qui fait qu'on ne peut qu'ignorer les resultats. L'hysterie est plutot la frenesie avec laquelle les trolleurs s'emparent du sujet, n'est ce pas Manu ?:)
Comme pour le papier, hein? Quand tu ne peux plus t'en prendre aux idées, tu t'en prends aux personnes, mmm?
Mauvais joueur :)
mips
On Wed, 22 Oct 2003 09:38:36 +0200
manu@netbsd.org (Emmanuel Dreyfus) wrote:
mips <anti@spam.gov> wrote:
Franchement je pense que peu de vrais BSDistes ont vraiment frole
l'hysterie. Ce papier repose sur une mauvaise base ce qui fait
qu'on ne peut qu'ignorer les resultats. L'hysterie est plutot la
frenesie avec laquelle les trolleurs s'emparent du sujet, n'est ce
pas Manu ?:)
Comme pour le papier, hein? Quand tu ne peux plus t'en prendre aux
idées, tu t'en prends aux personnes, mmm?
On Wed, 22 Oct 2003 09:38:36 +0200 (Emmanuel Dreyfus) wrote:
mips wrote:
Franchement je pense que peu de vrais BSDistes ont vraiment frole l'hysterie. Ce papier repose sur une mauvaise base ce qui fait qu'on ne peut qu'ignorer les resultats. L'hysterie est plutot la frenesie avec laquelle les trolleurs s'emparent du sujet, n'est ce pas Manu ?:)
Comme pour le papier, hein? Quand tu ne peux plus t'en prendre aux idées, tu t'en prends aux personnes, mmm?
Mauvais joueur :)
mips
mips
On Wed, 22 Oct 2003 09:38:35 +0200 (Emmanuel Dreyfus) wrote:
Étienne 'Tinou' Labaume wrote:
D'ailleurs, il n'y a pas un OpenBSDiste chevronne dans le coin qui voudrait refaire les tests pour son OS sur une becane configuree par ses soins ? On aurait peut-etre une idee plus fiable apres ...
Ca ne changera rien: quand on a des algos en O(n), on a un résultat en O(n).
De toute facon le test etait base sur un Os fraichement installe sans optimisation. De plus les tests ne seront pas valables vu qu'ils ne seront pas effectues sur la meme machine.
mips
On Wed, 22 Oct 2003 09:38:35 +0200
manu@netbsd.org (Emmanuel Dreyfus) wrote:
D'ailleurs, il n'y a pas un OpenBSDiste chevronne dans le coin qui
voudrait refaire les tests pour son OS sur une becane configuree
par ses soins ? On aurait peut-etre une idee plus fiable apres ...
Ca ne changera rien: quand on a des algos en O(n), on a un résultat
en O(n).
De toute facon le test etait base sur un Os fraichement installe sans
optimisation. De plus les tests ne seront pas valables vu qu'ils ne
seront pas effectues sur la meme machine.
On Wed, 22 Oct 2003 09:38:35 +0200 (Emmanuel Dreyfus) wrote:
Étienne 'Tinou' Labaume wrote:
D'ailleurs, il n'y a pas un OpenBSDiste chevronne dans le coin qui voudrait refaire les tests pour son OS sur une becane configuree par ses soins ? On aurait peut-etre une idee plus fiable apres ...
Ca ne changera rien: quand on a des algos en O(n), on a un résultat en O(n).
De toute facon le test etait base sur un Os fraichement installe sans optimisation. De plus les tests ne seront pas valables vu qu'ils ne seront pas effectues sur la meme machine.
mips
manu
mips wrote:
Ca ne changera rien: quand on a des algos en O(n), on a un résultat en O(n). De toute facon le test etait base sur un Os fraichement installe sans
optimisation. De plus les tests ne seront pas valables vu qu'ils ne seront pas effectues sur la meme machine.
J'ai pas vraiment l'impression de parler à quelqu'un qui m'ecoute. Tu aura beau optimiser ton OpenBSD après installation et faire le test sur la machine la plus performante qui soit, là où tes algos sont O(n), tu aura un résultat en O(n).
La conclusion du papier, telle que je la comprends, c'est que Linux 2.6 est bon car il fait O(1) partout. Les objections que tu lèves sont nulles et non avenues sur ce point. Visiblement nous ne voyons pas la même conclusion au papier
Bon, bien sur, je comprends que c'est plus facile de faire dégénérer en troll un test sur lequel on fait une pietre performance, mais tant qu'à troller, tu pourrais au moins choisir des arguments qui tiennent la route. Quelque exemples, que j'ai peu vu débatus dans cette histoire:
- le test mesure-t-il les bonnes données? L'utilisation d'une machine dans une situation réelle fait jouer tout un tas de parametres, et ces remarquables optimisations de Linux 2.6 se sentent elles autrement qu'en faisant ces tests sur des fonctionnalités de très bas niveau? (c'est une vraie question, je n'en sais rien)
- ces bons résultats obtenus par Linux ont-ils un prix? Est-ce simplement l'usage de meilleurs algos, ou bien y a-t-il une contrepartie, par exemple en terme de mémoire? Ces derniers jours, il y a eu beaucoup d'échanges du coté de NetBSD sur ces problèmes d'optimisation. Le spectre de la surconsommation de mémoire pour accelerer les choses a evidemment surgit. Exemple: de meilleurs performances vallent elles le coup de dépenser plusieurs ko par adresse IP locale?
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
mips <anti@spam.gov> wrote:
Ca ne changera rien: quand on a des algos en O(n), on a un résultat
en O(n).
De toute facon le test etait base sur un Os fraichement installe sans
optimisation. De plus les tests ne seront pas valables vu qu'ils ne
seront pas effectues sur la meme machine.
J'ai pas vraiment l'impression de parler à quelqu'un qui m'ecoute. Tu
aura beau optimiser ton OpenBSD après installation et faire le test sur
la machine la plus performante qui soit, là où tes algos sont O(n), tu
aura un résultat en O(n).
La conclusion du papier, telle que je la comprends, c'est que Linux 2.6
est bon car il fait O(1) partout. Les objections que tu lèves sont
nulles et non avenues sur ce point. Visiblement nous ne voyons pas la
même conclusion au papier
Bon, bien sur, je comprends que c'est plus facile de faire dégénérer en
troll un test sur lequel on fait une pietre performance, mais tant qu'à
troller, tu pourrais au moins choisir des arguments qui tiennent la
route. Quelque exemples, que j'ai peu vu débatus dans cette histoire:
- le test mesure-t-il les bonnes données? L'utilisation d'une machine
dans une situation réelle fait jouer tout un tas de parametres, et ces
remarquables optimisations de Linux 2.6 se sentent elles autrement qu'en
faisant ces tests sur des fonctionnalités de très bas niveau? (c'est une
vraie question, je n'en sais rien)
- ces bons résultats obtenus par Linux ont-ils un prix? Est-ce
simplement l'usage de meilleurs algos, ou bien y a-t-il une
contrepartie, par exemple en terme de mémoire? Ces derniers jours, il y
a eu beaucoup d'échanges du coté de NetBSD sur ces problèmes
d'optimisation. Le spectre de la surconsommation de mémoire pour
accelerer les choses a evidemment surgit. Exemple: de meilleurs
performances vallent elles le coup de dépenser plusieurs ko par adresse
IP locale?
--
Emmanuel Dreyfus
Un bouquin en français sur BSD:
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
Ca ne changera rien: quand on a des algos en O(n), on a un résultat en O(n). De toute facon le test etait base sur un Os fraichement installe sans
optimisation. De plus les tests ne seront pas valables vu qu'ils ne seront pas effectues sur la meme machine.
J'ai pas vraiment l'impression de parler à quelqu'un qui m'ecoute. Tu aura beau optimiser ton OpenBSD après installation et faire le test sur la machine la plus performante qui soit, là où tes algos sont O(n), tu aura un résultat en O(n).
La conclusion du papier, telle que je la comprends, c'est que Linux 2.6 est bon car il fait O(1) partout. Les objections que tu lèves sont nulles et non avenues sur ce point. Visiblement nous ne voyons pas la même conclusion au papier
Bon, bien sur, je comprends que c'est plus facile de faire dégénérer en troll un test sur lequel on fait une pietre performance, mais tant qu'à troller, tu pourrais au moins choisir des arguments qui tiennent la route. Quelque exemples, que j'ai peu vu débatus dans cette histoire:
- le test mesure-t-il les bonnes données? L'utilisation d'une machine dans une situation réelle fait jouer tout un tas de parametres, et ces remarquables optimisations de Linux 2.6 se sentent elles autrement qu'en faisant ces tests sur des fonctionnalités de très bas niveau? (c'est une vraie question, je n'en sais rien)
- ces bons résultats obtenus par Linux ont-ils un prix? Est-ce simplement l'usage de meilleurs algos, ou bien y a-t-il une contrepartie, par exemple en terme de mémoire? Ces derniers jours, il y a eu beaucoup d'échanges du coté de NetBSD sur ces problèmes d'optimisation. Le spectre de la surconsommation de mémoire pour accelerer les choses a evidemment surgit. Exemple: de meilleurs performances vallent elles le coup de dépenser plusieurs ko par adresse IP locale?
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
