Voilà une série de benchmarks comparant Ubuntu et W7
http://www.tuxradar.com/node/33
Mais voilà, les tests ont été fait sur un W7 sans installation de
drivers, laissant ceux fournis
En fait, il semble que dans le monde Linux, on se tappe pas mal des
drivers, utilisant ceux livrés, alors que dans le monde Windows, les
drivers par défaut sont toujours mauvais
Cumbalero , dans le message <gmopi0$si7$, a écrit :
Ca change rien au fait qu'un programme instable ne peut être qualifié de performant.
Ça change que ta réponse était complètement à côté de la plaque.
Richard Delorme
Nicolas George a écrit :
Cumbalero , dans le message <gmol1t$ron$, a écrit :
Et? Si tu as un code de merde, tu peux le compiler comme tu veux, tu auras un programme de merde.
Pourquoi passes-tu ton temps à dire des conneries alors que manifestement tu n'y connais rien ?
Il y a une quantité considérable de code qui fonctionne en pratique parfaitement mais qui peut être qualifié de code « de merde » parce qu'il fait, implicitement et sans que le programmeur en ait conscience, des hypothèses sur la manière dont le compilateur, l'OS et le processeur fonctionnent. On peut citer des exemples innombrables : stocker un entier dans un pointeur ou réciproquement, aller lire une valeur dans une structure qui vient d'être libérée, compter sur des extensions de signe ou des troncatures implicites, accéder à la représentation interne de certains types, manipuler des objets non alignés, etc.
Si un programmeur n'a pas conscience qu'il utilise des comportements non définis, c'est quand même grave... Je n'ai rien contre leur utilisation qui est parfois bien pratique, voire inévitable, mais il faut le faire en connaissance de cause et avec un minimum de précaution.
Ces hypothèses sont évidemment vérifiées dans les circonstances où le programme est normalement utilisé (gcc -O2 + glibc + Linux + x86, typiquement), sinon ça se traduirait par un bug visible et ce serait corrigé. Donc en pratique le programme marche très bien.
Là c'est le fonctionnement anormal du programme qui tombe en marche.
Mais si on s'aventure à changer les circonstances : remplacer le -O2 par un -O3, lier avec la µClibc, faire tourner sur un processeur Sparc, etc., alors c'est la catastrophe.
Là c'est le fonctionnement normal du programme.
En toute prudence, un programme devrait être testé sur un minimum d'architecture différente, avec des compilateurs différents, des outils de contrôle de conformité (genre splint, ou au minimum pour gcc avec les options -Wextra -Wall). S'il a besoin d'un certain nombres d'hypothèses, il doit les vérifier à la compilation ou au démarrage du programme.
-- Richard
Nicolas George a écrit :
Cumbalero , dans le message <gmol1t$ron$1@writer.imaginet.fr>, a écrit :
Et? Si tu as un code de merde, tu peux le compiler comme tu veux, tu
auras un programme de merde.
Pourquoi passes-tu ton temps à dire des conneries alors que manifestement tu
n'y connais rien ?
Il y a une quantité considérable de code qui fonctionne en pratique
parfaitement mais qui peut être qualifié de code « de merde » parce qu'il
fait, implicitement et sans que le programmeur en ait conscience, des
hypothèses sur la manière dont le compilateur, l'OS et le processeur
fonctionnent. On peut citer des exemples innombrables : stocker un entier
dans un pointeur ou réciproquement, aller lire une valeur dans une structure
qui vient d'être libérée, compter sur des extensions de signe ou des
troncatures implicites, accéder à la représentation interne de certains
types, manipuler des objets non alignés, etc.
Si un programmeur n'a pas conscience qu'il utilise des comportements non
définis, c'est quand même grave... Je n'ai rien contre leur utilisation
qui est parfois bien pratique, voire inévitable, mais il faut le faire
en connaissance de cause et avec un minimum de précaution.
Ces hypothèses sont évidemment vérifiées dans les circonstances où le
programme est normalement utilisé (gcc -O2 + glibc + Linux + x86,
typiquement), sinon ça se traduirait par un bug visible et ce serait
corrigé. Donc en pratique le programme marche très bien.
Là c'est le fonctionnement anormal du programme qui tombe en marche.
Mais si on s'aventure à changer les circonstances : remplacer le -O2 par un
-O3, lier avec la µClibc, faire tourner sur un processeur Sparc, etc., alors
c'est la catastrophe.
Là c'est le fonctionnement normal du programme.
En toute prudence, un programme devrait être testé sur un minimum
d'architecture différente, avec des compilateurs différents, des outils
de contrôle de conformité (genre splint, ou au minimum pour gcc avec les
options -Wextra -Wall). S'il a besoin d'un certain nombres d'hypothèses,
il doit les vérifier à la compilation ou au démarrage du programme.
Cumbalero , dans le message <gmol1t$ron$, a écrit :
Et? Si tu as un code de merde, tu peux le compiler comme tu veux, tu auras un programme de merde.
Pourquoi passes-tu ton temps à dire des conneries alors que manifestement tu n'y connais rien ?
Il y a une quantité considérable de code qui fonctionne en pratique parfaitement mais qui peut être qualifié de code « de merde » parce qu'il fait, implicitement et sans que le programmeur en ait conscience, des hypothèses sur la manière dont le compilateur, l'OS et le processeur fonctionnent. On peut citer des exemples innombrables : stocker un entier dans un pointeur ou réciproquement, aller lire une valeur dans une structure qui vient d'être libérée, compter sur des extensions de signe ou des troncatures implicites, accéder à la représentation interne de certains types, manipuler des objets non alignés, etc.
Si un programmeur n'a pas conscience qu'il utilise des comportements non définis, c'est quand même grave... Je n'ai rien contre leur utilisation qui est parfois bien pratique, voire inévitable, mais il faut le faire en connaissance de cause et avec un minimum de précaution.
Ces hypothèses sont évidemment vérifiées dans les circonstances où le programme est normalement utilisé (gcc -O2 + glibc + Linux + x86, typiquement), sinon ça se traduirait par un bug visible et ce serait corrigé. Donc en pratique le programme marche très bien.
Là c'est le fonctionnement anormal du programme qui tombe en marche.
Mais si on s'aventure à changer les circonstances : remplacer le -O2 par un -O3, lier avec la µClibc, faire tourner sur un processeur Sparc, etc., alors c'est la catastrophe.
Là c'est le fonctionnement normal du programme.
En toute prudence, un programme devrait être testé sur un minimum d'architecture différente, avec des compilateurs différents, des outils de contrôle de conformité (genre splint, ou au minimum pour gcc avec les options -Wextra -Wall). S'il a besoin d'un certain nombres d'hypothèses, il doit les vérifier à la compilation ou au démarrage du programme.
-- Richard
Nicolas George
Richard Delorme , dans le message <499005ad$0$28677$, a écrit :
Si un programmeur n'a pas conscience qu'il utilise des comportements non définis, c'est quand même grave...
Oui, mais c'est le cas de facilement neuf programmeurs sur dix, pour ne pas dire 99 sur 100, alors ça redéfinit ce qu'on appelle « normal » dans ce domaine.
Richard Delorme , dans le message
<499005ad$0$28677$7a628cd7@news.club-internet.fr>, a écrit :
Si un programmeur n'a pas conscience qu'il utilise des comportements non
définis, c'est quand même grave...
Oui, mais c'est le cas de facilement neuf programmeurs sur dix, pour ne pas
dire 99 sur 100, alors ça redéfinit ce qu'on appelle « normal » dans ce
domaine.
Richard Delorme , dans le message <499005ad$0$28677$, a écrit :
Si un programmeur n'a pas conscience qu'il utilise des comportements non définis, c'est quand même grave...
Oui, mais c'est le cas de facilement neuf programmeurs sur dix, pour ne pas dire 99 sur 100, alors ça redéfinit ce qu'on appelle « normal » dans ce domaine.
remy
Nicolas George a écrit :
Richard Delorme , dans le message <499005ad$0$28677$, a écrit :
Si un programmeur n'a pas conscience qu'il utilise des comportements non définis, c'est quand même grave...
Oui, mais c'est le cas de facilement neuf programmeurs sur dix, pour ne pas dire 99 sur 100, alors ça redéfinit ce qu'on appelle « normal » dans ce domaine.
pas d'accord
peut être et encore pour le c, la réf en la matière pour le côté pernicif vu sur l'angle (piège à con)
mais les 2/3 des programmes ne sont pas écrits en c même pour l'embarqué l'on a j2me et java card
donc comme tu dis, définis mieux le contexte l4g tout ça ...
-- http://remyaumeunier.chez-alice.fr/
Nicolas George a écrit :
Richard Delorme , dans le message
<499005ad$0$28677$7a628cd7@news.club-internet.fr>, a écrit :
Si un programmeur n'a pas conscience qu'il utilise des comportements non
définis, c'est quand même grave...
Oui, mais c'est le cas de facilement neuf programmeurs sur dix, pour ne pas
dire 99 sur 100, alors ça redéfinit ce qu'on appelle « normal » dans ce
domaine.
pas d'accord
peut être et encore pour le c, la réf en la matière pour le côté
pernicif vu sur l'angle (piège à con)
mais les 2/3 des programmes ne sont pas écrits en c
même pour l'embarqué l'on a j2me et java card
donc comme tu dis, définis mieux le contexte
l4g tout ça ...
Richard Delorme , dans le message <499005ad$0$28677$, a écrit :
Si un programmeur n'a pas conscience qu'il utilise des comportements non définis, c'est quand même grave...
Oui, mais c'est le cas de facilement neuf programmeurs sur dix, pour ne pas dire 99 sur 100, alors ça redéfinit ce qu'on appelle « normal » dans ce domaine.
pas d'accord
peut être et encore pour le c, la réf en la matière pour le côté pernicif vu sur l'angle (piège à con)
mais les 2/3 des programmes ne sont pas écrits en c même pour l'embarqué l'on a j2me et java card
donc comme tu dis, définis mieux le contexte l4g tout ça ...
-- http://remyaumeunier.chez-alice.fr/
Richard Delorme
Nicolas George a écrit :
Richard Delorme , dans le message <499005ad$0$28677$, a écrit :
Si un programmeur n'a pas conscience qu'il utilise des comportements non définis, c'est quand même grave...
Oui, mais c'est le cas de facilement neuf programmeurs sur dix, pour ne pas dire 99 sur 100, alors ça redéfinit ce qu'on appelle « normal » dans ce domaine.
Ce taux d'inconscience est possible, mais ce niveau de normalité est tout de même très grave.
-- Richard
Nicolas George a écrit :
Richard Delorme , dans le message
<499005ad$0$28677$7a628cd7@news.club-internet.fr>, a écrit :
Si un programmeur n'a pas conscience qu'il utilise des comportements non
définis, c'est quand même grave...
Oui, mais c'est le cas de facilement neuf programmeurs sur dix, pour ne pas
dire 99 sur 100, alors ça redéfinit ce qu'on appelle « normal » dans ce
domaine.
Ce taux d'inconscience est possible, mais ce niveau de normalité est
tout de même très grave.
Richard Delorme , dans le message <499005ad$0$28677$, a écrit :
Si un programmeur n'a pas conscience qu'il utilise des comportements non définis, c'est quand même grave...
Oui, mais c'est le cas de facilement neuf programmeurs sur dix, pour ne pas dire 99 sur 100, alors ça redéfinit ce qu'on appelle « normal » dans ce domaine.
Ce taux d'inconscience est possible, mais ce niveau de normalité est tout de même très grave.
-- Richard
Richard Delorme
remy a écrit :
peut être et encore pour le c, la réf en la matière pour le côté pernicif vu sur l'angle (piège à con)
Si l'on maitrise bien le langage, chose assez facile pour le C vu la concision du langage, il n'y a pas beaucoup de pièges inévitables.
mais les 2/3 des programmes ne sont pas écrits en c même pour l'embarqué l'on a j2me et java card
Comme s'il n'existait pas de pièges à con dans le langage Java, des livres tel que :
Java Pitfalls (John Wiley & Sons, 2000) E. Monk, J.P. Keller, K. Bohnenberger & M.C. Daconta
seraient-il publiés ?
-- Richard
remy a écrit :
peut être et encore pour le c, la réf en la matière pour le côté
pernicif vu sur l'angle (piège à con)
Si l'on maitrise bien le langage, chose assez facile pour le C vu la
concision du langage, il n'y a pas beaucoup de pièges inévitables.
mais les 2/3 des programmes ne sont pas écrits en c
même pour l'embarqué l'on a j2me et java card
Comme s'il n'existait pas de pièges à con dans le langage Java, des
livres tel que :
Java Pitfalls (John Wiley & Sons, 2000) E. Monk, J.P. Keller, K.
Bohnenberger & M.C. Daconta
peut être et encore pour le c, la réf en la matière pour le côté pernicif vu sur l'angle (piège à con)
Si l'on maitrise bien le langage, chose assez facile pour le C vu la concision du langage, il n'y a pas beaucoup de pièges inévitables.
mais les 2/3 des programmes ne sont pas écrits en c même pour l'embarqué l'on a j2me et java card
Comme s'il n'existait pas de pièges à con dans le langage Java, des livres tel que :
Java Pitfalls (John Wiley & Sons, 2000) E. Monk, J.P. Keller, K. Bohnenberger & M.C. Daconta
seraient-il publiés ?
-- Richard
remy
Richard Delorme a écrit :
remy a écrit :
peut être et encore pour le c, la réf en la matière pour le côté pernicif vu sur l'angle (piège à con)
Si l'on maitrise bien le langage, chose assez facile pour le C vu la concision du langage, il n'y a pas beaucoup de pièges inévitables.
mais les 2/3 des programmes ne sont pas écrits en c même pour l'embarqué l'on a j2me et java card
Comme s'il n'existait pas de pièges à con dans le langage Java, des livres tel que :
le seul moyen d'avoir un comportement non cohérent que je connaisse avec ce langage c'est d'aller tripatouiller les fichiers class
par nature il y a séparation des données et du code les allocations sont dynamiques pas de recouvrement maintenant, que le garbage collector ne fasse pas toujours aussi vite qu' on le souhaite son taf je veux bien l'entendre mais cela n'a rien à voir avec un piège à con
le C en est rempli NG en a cité que quelques uns et comme je ne code plus en C je lui laisse sa liste en l'état
maintenant si tu as quelques exemples je suis preneur pour une mise à niveau des pièges à con concernant java
Java Pitfalls (John Wiley & Sons, 2000) E. Monk, J.P. Keller, K. Bohnenberger & M.C. Daconta
seraient-il publiés ?
-- http://remyaumeunier.chez-alice.fr/
Richard Delorme a écrit :
remy a écrit :
peut être et encore pour le c, la réf en la matière pour le côté
pernicif vu sur l'angle (piège à con)
Si l'on maitrise bien le langage, chose assez facile pour le C vu la
concision du langage, il n'y a pas beaucoup de pièges inévitables.
mais les 2/3 des programmes ne sont pas écrits en c
même pour l'embarqué l'on a j2me et java card
Comme s'il n'existait pas de pièges à con dans le langage Java, des
livres tel que :
le seul moyen d'avoir un comportement non cohérent que je connaisse
avec ce langage c'est d'aller tripatouiller les fichiers class
par nature il y a séparation des données et du code
les allocations sont dynamiques pas de recouvrement
maintenant, que le garbage collector ne fasse pas toujours aussi vite
qu' on le souhaite son taf
je veux bien l'entendre mais cela n'a rien à voir avec un piège à con
le C en est rempli
NG en a cité que quelques uns
et comme je ne code plus en C je lui laisse sa liste en l'état
maintenant si tu as quelques exemples je suis preneur pour une
mise à niveau des pièges à con concernant java
Java Pitfalls (John Wiley & Sons, 2000) E. Monk, J.P. Keller, K.
Bohnenberger & M.C. Daconta
peut être et encore pour le c, la réf en la matière pour le côté pernicif vu sur l'angle (piège à con)
Si l'on maitrise bien le langage, chose assez facile pour le C vu la concision du langage, il n'y a pas beaucoup de pièges inévitables.
mais les 2/3 des programmes ne sont pas écrits en c même pour l'embarqué l'on a j2me et java card
Comme s'il n'existait pas de pièges à con dans le langage Java, des livres tel que :
le seul moyen d'avoir un comportement non cohérent que je connaisse avec ce langage c'est d'aller tripatouiller les fichiers class
par nature il y a séparation des données et du code les allocations sont dynamiques pas de recouvrement maintenant, que le garbage collector ne fasse pas toujours aussi vite qu' on le souhaite son taf je veux bien l'entendre mais cela n'a rien à voir avec un piège à con
le C en est rempli NG en a cité que quelques uns et comme je ne code plus en C je lui laisse sa liste en l'état
maintenant si tu as quelques exemples je suis preneur pour une mise à niveau des pièges à con concernant java
Java Pitfalls (John Wiley & Sons, 2000) E. Monk, J.P. Keller, K. Bohnenberger & M.C. Daconta
seraient-il publiés ?
-- http://remyaumeunier.chez-alice.fr/
Claude PARMENTIER
On Mon, 09 Feb 2009 08:22:08 +0100, Cumbalero wrote:
G-raison a écrit :
On peut aussi choper des saloperies rue St Denis à Paris. Mais c'est plus cher. :-)
"Software is like sex, it's better when it's free"...
A+ JF
Desolé mais niquer un manchot gratuitement ca m'inspire pas..
On Mon, 09 Feb 2009 08:22:08 +0100, Cumbalero
<cumbalero@NOSPAM.yahoo.fr> wrote:
G-raison a écrit :
On peut aussi choper des saloperies rue St Denis à Paris.
Mais c'est plus cher. :-)
"Software is like sex, it's better when it's free"...
A+
JF
Desolé mais niquer un manchot gratuitement ca m'inspire pas..
