Ruby ?? - Page 3

Quelqu'un qui écrit des horreurs comme a = a << 3; ou a = a * 8; dans ses programmes est quelqu'un qui ne connaît pas le C.

sondage corrigé pour faire plaisir à kk.

Perso je fais ça a = a + a + a + a + a + a + a + a;

C'est lent non ?
Il ne vaut pas mieux faire :

a+= a;
a+= a;
a+= a;

?
Ce qui reste plus lent que a<<=3;

Une addition seule sera toujours plus lente qu'un décalage. Bref une opération arithmétique est plus lente que n'importe quelle opération logique.

C'est faux. Une addition est plus rapide qu'un lsl #1, et 2 additions peuvent être plus rapides qu'un lsl #2 aussi. (En revanche, 3 additions sont toujours plus lentes qu'un lsl #3.)

C'est faux. geogeo généralise sur l'ensemble des microprocesseurs, il parle pas du M68000.

Ça ne change pas que son "toujours" est faux, étant donné que c'est faux pour le 68k.

perso qqn qui me montre un <<3 pour un multiplié par 8, je dis que c'est un boulet.
Quand aux nombres non signés, ils sont parfois très mal géré par certains compilateur.
Enfin je pense pas que le résultat de la rom de ti soit critiquable pour le publique qu'elle vise -> ils ont fait le bon choix

Rien à voir (pour éviter de créer 100 topics), mais si quelqu'un voulait bien troquer une solution au problème du gars de chez TI contre son checkout CVS de CAS Software ça nous arrangerait http://discussions.apple.com/thread.jspa?messageID=5921727#5921727

Ximoon (./60) :
Ça dépend dans quel contexte :
Si c'est de la manipulation binaire : a <<8.
Si c'est de l'arithmétique, a*8.

Quant à a<<=8... J'ai dû le faire parfois, mais franchement c'est illisible...

Perso je fais:

//Multiplie par 8
a <<= 3;

Ca résoud les problèmes

Ben ça sert vraiment à rien du coup parce que tu passes du temps à écrire un commentaire qui serait inutile si tu écrivais directement i = i * 8;

En fait c'est une question de vitesse. Par contre je suis d'accord que c'est plus long qu'écrire a = a << 3, mais comme c'est pas clair non plus je devrais de toute façon le commenter

Brunni (./73) :
Perso je fais:

//Multiplie par 8
a <<= 3;

Ca résoud les problèmes

Ca je je trouve ça un peu dommage par contre. Rendez votre documentation exécutable ! (une macro ferait l'affaire en l'occurence)

Pourquoi rendre la documentation exécutable ? (pour permettre au développeur d'écrire à la fois du code et de la doc ?)

Pourquoi ne pas écrire x8 et laisser le compilateur savoir ce qui est le plus rapide ?

Parce que x8 n'est pas forcément remplacé par << 3, parce que c'est seulement dans certains cas que ça diffère, mais on sait lesquels et en l'occurence ça ne nous gène pas, il nous faut la solution la plus rapide.
M'enfin je suis d'accord avec vous, j'aime pas trop ce genre d'optimisations, parce que ça "scelle" le code pour modification / débogage futur. Donc j'évite sauf s'il faut vraiment des performances maximales et que c'est une section de code critique (et dans ce cas je commente, justement). En général je cherche plutôt à améliorer l'algorithmique si possible, mais parfois un algorithme vicieux, même commenté est plus compliqué à comprendre qu'un bon code asm (même si c'est un peu tiré par les cheveux, je l'avoue)

asm: je ne me ferais jamais aux forums TI...

mais parfois un algorithme vicieux, même commenté est plus compliqué à comprendre qu'un bon code asm

Tant qu'il est beau...

Brunni (./79) :
Parce que x8 n'est pas forcément remplacé par << 3 parce que c'est seulement dans certains cas que ça diffère,

Quand est-ce que ca diffère ?

C'est pour >> que ça diffère.

Hum oui c'est vrai. Faudra que je vérifie à l'occas ce que fait GCC dans ces cas-là. M'enfin c'est un mauvais exemple, on pourrait prendre le modulo fait avec un AND aussi, le problème reste le même ^^

-> D'où l'intérêt de laisser le compilateur réaliser lui-même les bonnes optimisations (puisque tu te trompes et que ton code est moins lisible)

Sasume (./77) :
Pourquoi rendre la documentation exécutable ? (pour permettre au développeur d'écrire à la fois du code et de la doc ?)

Dans l'absolu pour être plus concis, éviter le code inutile et permettre au compilateur de valider la documentation, mais dans ce cas précis je ./78.

Brunni (./73) :
Perso je fais:

//Multiplie par 8
a <<= 3;

AMHA, ce commentaire est tout aussi inutile que:

// Rajoute 1 à a
a++;

ou même:

// Rajoute 1 à a
a = a + 1;

Tout le monde sait que <<=3 multiplie par 2³ et que 2³=8. (Si on n'a pas ces connaissances de base des Mathématiques, on n'est pas capable de programmer correctement. )

Sasume (./84) :
-> D'où l'intérêt de laisser le compilateur réaliser lui-même les bonnes optimisations (puisque tu te trompes et que ton code est moins lisible)

Si je remplace les & 15 du moteur de collisions de mon Sonic par des % 16 ou pire les >> 4 par des / 16 je peux te jurer qu'il tourne *carrément* moins bien niveau vitesse, même si le résultat est exactement le même visuellement parce que je ne tombe jamais dans les cas limite...
Y'a des fois où t'as pas le choix...
Et pour te répondre Kevin non c'est pas évident, surtout si ton algorithme est déjà pas simple à comprendre, on sait pas vraiment ce que t'es en train de faire...
De la même manière un ldrne pc, [r1, r0, lsl#2] est absolument évident (saut à r1[r0 * 4] si pas égal) autant sans commentaire ça m'est impossible de m'y retrouver moi-même dans mon code (qu'est-ce que j'ai foutu dans r1? ha j'ai fait aussi des calculs sur r0, c'est le résultat de quoi déjà? j'ai fait un adds avant, donc ça veut dire que ma condition c'est que le résultat d'avant soit pas nul...), alors j'imagine pas les autres qui n'ont pas l'algo en tête...
Le coup du ldr est un peu vicieux, mais le C peut être encore pire niveau lisibilité puisqu'on peut combiner ce genre d'opérations en une expression.

Brunni (./88) :
Si je remplace les & 15 du moteur de collisions de mon Sonic par des % 16 ou pire les >> 4 par des / 16 je peux te jurer qu'il tourne *carrément* moins bien niveau vitesse, même si le résultat est exactement le même visuellement parce que je ne tombe jamais dans les cas limite...

Tu utilises bien des entiers non signés ? Et avec les bonnes optimisations ?

+1 Thepro.
/16 -> >>4 ne devrait rien changer au code - ou alors, le compilo a besoin d'une amélioration