Optimisation switch... - Page 1

Bon, comme il est question d'optimisation de switchs par ici, ça m'amène à une question... , opcode);     } } J'ai cette fonction : void execute (unsigned short opcode, unsigned short num, unsigned short *param) {     switch (opcode) {         case 0x01 : compare(num, param); break;         case 0x02 : LTE(param[0], param[1]); break;         case 0x03 : GTE(param[0], param[1]); break;         case 0x04 : dec_chk(param[0], param[1]); break;         case 0x05 : inc_chk(param[0], param[1]); break;         case 0x06 : check_loc(param[0], param[1]); break;         case 0x07 : bit(param[0], param[1]); break;         case 0x08 : or(param[0], param[1]); break;         case 0x09 : and(param[0], param[1]); break;         case 0x0a : test_attr(param[0], param[1]); break;         case 0x0b : set_attr(param[0], param[1]); break;         case 0x0c : clr_attr(param[0], param[1]); break;         case 0x0d : put_var(param[0], param[1]); break;         case 0x0e : transfer(param[0], param[1]); break;         case 0x0f : load_word_array(param[0], param[1]); break;         case 0x10 : load_byte_array(param[0], param[1]); break;         case 0x11 : get_prop(param[0], param[1]); break;         case 0x12 : get_prop_addr(param[0], param[1]); break;         case 0x13 : next_prop(param[0], param[1]); break;         case 0x14 : plus(param[0], param[1]); break;         case 0x15 : minus(param[0], param[1]); break;         case 0x16 : multiply(param[0], param[1]); break;         case 0x17 : divide(param[0], param[1]); break;         case 0x18 : mod(param[0], param[1]); break; #ifdef VERSION_QUATRE         case 0x19 : /* version à 2 opérandes de gosub */         case 0x2c : if (STANDARD) goto illegal; /* version à 8 opérandes du même */ #endif                     /* Ici des opcodes V5...*/         case 0x20 : gosub(num, param, 0); break;         case 0x21 : save_word_array(param[0], param[1], param[2]); break;         case 0x22 : save_byte_array(param[0], param[1], param[2]); break;         case 0x23 : put_prop(param[0], param[1], param[2]); break;         case 0x24 : input(param[0], param[1]); break;         case 0x25 : print_char(param[0]); break;         case 0x26 : print_num(param[0]); break;         case 0x27 : pi_random(param[0]); break;         case 0x28 : push(param[0]); break;         case 0x29 : pop(param[0]); break;         case 0x2a : scr_window(param[0]); break;         case 0x2b : scr_set_win(param[0]); break;               /* Ici des opcodes V4...*/         case 0x33 : output_stream(param); break;         case 0x34 : /* input_stream(param[0]); */ break;         case 0x35 : scr_putsound(param[0], param[1], param[2], num); break;         default : #ifdef VERSION_QUATRE   /* 0x2c : forme de gosub avec jusqu'à 8 arguments */       if (ENHANCED) switch (opcode) {         case 0x2d : erase_window(param[0]); return;         case 0x2e : erase_line(param[0]); return;         case 0x2f : set_cursor(param[0], param[1]);                  return;         case 0x30 : get_cursor(param[0]); return;         case 0x31 : scr_font_style(param[0]); return;         case 0x32 : /* buffer_mode(param[0]); */ return;               /* Ici des opcodes V3... */         case 0x36 : read_char(num, param); return;         case 0x37 : scan_table(num, param); return;       } #ifdef VERSION_CINQ       if (ADVANCED) switch (opcode) {          case 0x1b : set_colour(param[0], param[1]); return;         case 0x1c : throw(param[0], param[1]); return;         case 0x38 : not(param[0]); return;         case 0x1a : /* 2 ops */         case 0x39 : /* 8 ops */         case 0x3a : gosub (num, param, DROP_RETURN_VALUE); return;         case 0x3b : tokenise(num, param); return;         case 0x3c : encode_text(param[0], param[1], param[2], param[3]); return;         case 0x3d : copy_table(param[0], param[1], param[2]); return;         case 0x3e : print_table(num, param); return;         case 0x3f : check_arg_count(param[0]); return;       } #endif /* VERSION_CINQ */ #endif /* VERSION_QUATRE */       illegal : error("execute: Invalid Z-code instruction: $%02x"
(pour info, ADVANCED c'est version == 5, STANDARD version == 3 et ENHANCED version >= 4).
Comme je dois gérer différentes versions du Z-code, j'ai coupé la table en plusieurs morceaux mais du coup ça fait des tables à trous.
Serait-il plus intéressant ou non de ne faire qu'un gros switch avec un test de version à chacun des opcodes qui en nécessitent un ? En taille ? en vitesse ?
Sinon, j'ai une possibilité (qui m'ennuie un peu, mais si le gain est vraiment appréciable on peut l'envisager...) qui est de ne pas faire du tout de test de version (sachant qu'en principe les fichiers ne contiennent PAS d'opcodes illégaux :-\)
Qu'en pensez-vous ?

Pour un switch aussi énorme, la méthode linéaire (-Os) va être une perte de temps considérable. Compile en -O2, tu constateras une différence de vitesse si cette fonction est appelée très souvent (dans une boucle par ex.)

Au niveau de la vitesse, il vaut mieux garder ton code tel quel (moins de tests à effectuer s'il ne génère pas de table).

Au niveau de la taille, ta solution est la meilleure, en linéaire. Avec une table, on aurait des "trous" donc une perte de place probable (autant ne pas faire de trous, c'est à dire tout mettre).

Ton code est très bien comme il est. À part le switch sous if (ADVANCED), tous les switches ici sont très denses, donc sont presque optimaux pour la taille des tables de sauts et donneront une table de sauts même en -Os. Donc le commentaire de Thibaut est inexact, -Os ira très bien en vitesse ici (parce qu'il donnera le même code que -O2!).

Le switch sous if(ADVANCED) est un peu plus problématique, parce qu'il y a 3 valeurs consécutives, un gros trou, puis 8 valeurs consécutives. Tu peux peut-être (à essayer) avoir du code meilleur en distinguant les cas opcode<=0x1c et opcode>=0x38 avec un if.

En fait, j'ai jeté un coup d'œil au résultat de la compilation, gcc-3.3pre12 donne trois tables (en -Os) mais la nouvelle version ne donne des tables que pour les deux premiers, et une suite de tests pour la troisième... je vais donc essayer la proposition de Kevin pour voir ce que ça donne (cette fonction est effectivement appelée dans la boucle principale, donc la vitesse est importante). Merci à vous deux.
À part ça, y aurait-il une façon d'utiliser le fait que le numéro de version ne peut pas changer au cours d'une exécution du programme, donc que les tests donnent toujours le même résultat ? j'en doute, mais si vous avez une idée (N.B. : les fonctions appelées par execute sont pour la plupart appelées uniquement à cet endroit et déclarées static inline, je ne peux donc pas jouer avec des pointeurs vers des fonctions...)
Sinon, une idée du gain qu'on aurait si l'on ne vérifiait pas du tout la validité des opcodes (ou seulement de ceux qui seraient susceptibles de crasher la calculette si on les appelle dans de mauvaises conditions, je ne crois pas qu'ils soient nombreux...) ? on aurait alors un seul switch, complètement dense ; j'aimerais savoir si c'est une possibilité à envisager sérieusement ou si le jeu n'en vaut pas la chandelle. (De toute façon, "illegal opcode" est une erreur fatale.)

Bon, donc j'ai essayé ce que proposait Kevin (couper le troisième switch en deux avec un if), et effectivement ça réduit encore la taille (il fait des tests pour 1a, 1b, 1c et une table pour le reste).
Donc l'optimiseur choisit au départ de faire soit une table, soit des tests et ne sait pas mélanger les deux (ce n'est pas une critique, je précise). Je suppose qu'il ne sait pas non plus faire deux tables avec un gros trou entre. C'est bon à savoir...

Finalement, j'ai remis les 3 opcodes qui gênaient dans le premier switch, avec un if (!ADVANCED) goto illegal; à chacun des cas. Ça fait exactement la même taille qu'en les mettant à part sous le if (ADVANCED), et en plus c'est meilleur en vitesse.
Merci pour votre aide.

De rien ma chère