mardi 19 mai 2009

Programmation : 1ère partie, de l'importance de l'optimisation

Pas de billet pour annoncer mon come-back mais restons efficace et pour l'annoncer, quoi de mieux qu'un vrai sujet de fond ?
Ici, il s'agira de l'optimisation en programmation, en deux parties histoire de pas avoir un gros pâté.
En effet, à l'heure actuelle, de nombreux langages existent, tous de plus en plus de haut niveau, ayant un niveau d'abstraction, certes on ne s'occupe plus que de l'essentiel mais de fait, on s'éloigne aussi de plus en plus de la machine et donc de sa logique : java, .net, ruby & co n'en sont que quelques exemples.
Dès lors, les programmeurs ont oublié qu'on pouvait optimiser son code, si si, je le vois tous les jours au boulot, nombreux sont ceux qui ne font qu'utiliser tel et tel framework, hop un tour dans la doc, ok, j'utilise ça pour faire ça etc ... mais personne (ou rares) sont les personnes prenant le temps de la réflexion en se disant si son code est vraiment optimisé.
Si j'en parle c'est que j'ai été confronté à cette problématique.
Je code en ce moment une bibliothèque permettant de décoder de la musique au format soundtrack (mod/xm/s3m & co), il y a une partie qui s'occupe de l'interpolation des échantillons, histoire d'"améliorer" le son (ce format induit souvent ce qu'on appel des "clicks & pops" autrement dit des bruits statiques).
J'utilise différents algorithmes ("au plus proche", "linéaire", "cubic spline" et "fir sinc") et c'est ce dernier, très couteux en cpu (16 points sont calculés pour un échantillon) qui m'a fait tiqué.
En effet, j'ai tout bêtement lancé le gestionnaire des tâches pour constater que le cpu oscillait entre 2 et ... 12% !
Inconcevable pour moi, j'ai tout de même un Q9550@3.4 ghz, j'ose imaginer ce que ça donnerais sur un mono core (même si mon code n'est pas optimisé multi-core) ou avec un cpu @1ghz (oui, je me préoccupe de ces machines :) ).
Vient le temps de la réflexion : comment faire pour optimiser ce fameux code ?
Ca a été vite vu car il n'y a pas 30 000 façon de le faire :
- "penser" cpu : c'est à dire arranger son code pour faire en sorte d'être dans la logique de traitement du cpu (exemple : micro fusion, boucle déroulée, prefetch compliancy ...)
- utiliser le SIMD : j'ai déjà lu pas mal de sujer/code à ce sujet mais je ne l'ai jamais réellement utilisé, d'autant plus que je suis loin d'être un guru en assembleur.

N'écoutant que mon courage, la solution la plus viable à mon niveau est ... la seconde ! Oui, j'aime bien les challenges :p

2 commentaires:

FreddyV a dit…

Rigolo de voir que l'on s'intéresse toujours à ces format.
Quand je pense que j'ai écrit mon premier player de MOD & co il y a plus de 15 an :-)

KarLKoX a dit…

Salut !
En fait, ce n'est pas la première fois que je code un lecteur de mod&xm&co, j'en avait fait un il y a une douzaine d'années sous Linux pour me mettre au C :)
Je sais pas, ça m'a pris comme ça, en portant du code Java --> PureBasic, j'ai ajouté des trucs en plus pis ça a évolué en un moteur qui, ma foi, commence à sonner à peu près bien :D
Sympas de voir qu'il y a encore des personnes qui se souviennent de ces formats :)