Reprise du message précédent :

ben tiens  
 
Le code dit tel quel "if(true) return true; else return false;

Un branchement de moins car pas de test?

Ben ça se code en  
return (x>box.x1 && x<box.x2 && y>box.y1 && y<box.y2);
On évite un if, tout simplement.
Ca ne va pas changer grand-chose, mais des petits trucs comme ça, il y en a partout, et comme dans ce genre de source, tout compte, on a vite fait de grapiller quelques % par-ci par là.

 
oui enfin pkoi moi ?
 
J'ai uen vie de merde

bien sur que si y'a un test

 
le code dit  
 
si (x <= box.x1) return false;
si (x >= box.x2) return false;
si (y <= box.y1) return false;
si (y >= box.y2) return false;
 
return true;
 

 
Bienvenu au club, tu veux un prozac ?
 
Ou deux ?
 
Ou trois boites  ? http://rincevent.dyndns.org/kilombo/cachets.jpg

Non, l'optimiseur est bien au dessus de tout ça...
Ca se compte en mode debug, peut-être, mais sans plus.

pas de if, voulais-je dire (si tu considères les comparaisons comme des tests)

Et puis ca enleve 2 lignes de code    
Là ou j'étudie on nous conseille dans ce cas de nous passer du if.

 
ca veut rien dire, ca, pas de if
t'as des comparaisons meme la ou on le dirait pas a premiere vue (genre un cast)
 

tu penses qu'en assembleur y'a une différence entre "if (machin && machin2) return true" et "return (machin1 && machin2)" ?

 
nan je veux mourrir

 
Ok, au temps pour moi. Mauvais exemple.

 
 
oué tu peux remplacer dans le dernier le cmp/je par cmp/cmove (cela dit VS le fait pour toi)

bordel, mais le C++ est suffisamment illisible comme ça pour ne pas rajouter davantage de spaghettis

 
oula karho defie mask en asm

 
 
on se demande c'est qui l'etudiant

ca va pas plus vite, mais c'est plus élégant

 
sisi, et oublie pas de remplacer tes /4 par >>2 hein ? c'est plus optimisé

tu m'otes les mots de la bouche

Je le fais en Java pour le moment

Si vous vous faites chier, je vous invite tous à venir m'optimiser le code de photophoria, hein (d'ailleurs, faudra que je m'y remette un de ces quatre... (smiley qui se gratte la tête)) .

 
moi aussi. Tous les jours, de mon 7eme étage au bureau, je regarde le sol en béton en bas. Tous les jours, je me demande si je vais réussir à franchir le rebord de la fenêtre, et y aller une bonne fois pour toute. En rentrant en voiture, je croise le regard de chaque platane. Il m'appelle, mais j'ose pas y aller. Je me dit qu'un jour, ça ira peut être mieux. Je me dit qu'il y a un espoir. Peut être...
 
C'est pour ça que le désespoir est aussi dur : c'est le moment où il n'y a plus d'espoir, le moment où tu te dit que ça y est, il n'y aura plus de changement.

 
bin file des routines, un jour de mauvais temps, qui sait

Le pb, c'est que je trouve qu'il fait un peu trop confiance à l'optimiseur à mon goût, notamment sur sa capacité à détecter des invariants dans les boucles (il y a plein de calculs redondants). Perso, j'évite de faire ce genre d'assomptions.

le compilo le fait à ma place

Parfois d'ailleurs, il faut se montrer très patient (expérience inside)

 
faut aussi savoir faire la balance entre optimisation et lisibilité (et enculage de mouche)
 
pour les calculs redondant, fait voir ? y'a des outils d'optimisations plus que couillu la dessus

Tutut. Ma version est plus propre, la remarque est fondée.

 
toi tu utilises pas gcc

 
Non, question de gout je prefere la sienne. Votre remarque etait idiote car tainté d'une sorte de leger mépris stupide.  
Recalé.

que Dieu m'en préserve  

 
Tiens, si je compilais gcc avec un vrai compilo, il sertait peut être moins long à compiler

mon chef attrape des boutons quand il lit ta construction favorite  Perso je m'en fous un peu, mais je pense que je vais lui en reparler la prochaine fois qu'il me sort ça

 
la derniere fois que j'ai dit ca, on m'a dit que je comprenais rien et que stait super important la compil sur amiga

 
mieux, compiles ton code avec un vrai compilo

 
J'(utilise le visual actuellement, j'ai tellement gueulé pour ne plus être sous nulix que j'ai eut gain de cause

+1 Et genre en VB, c'est beaucoup plus lisible...

La suivante est à mon humble avis, plusse meilleure. C'est beaucoup plus parlant je trouve...

 
 
je suis jaloux

 
et tu te plains de ta vie alors que moi je dois utiliser un bsd pourri

Y a le décodeur huffman pour les thumbnails qui prend grosso-modo 80% du temps CPU dans 2 fonctions:
void jpeg_decoder::decode_next_row(void);
inline uint jpeg_decoder::get_bits_2(int numbits);
 
Y a le denoiser, qui profiterait bien de SSE ou de MMX. Et pareil pour le gaussian blur. Dans les deux cas, le noyau de convolution doit être modifiable pour être d'une taille multiple de 4, pour simplifier le tout.
Le gaussian-blur irait beaucoup plus vite avec un encodage par "tile", ou même en utilisant une state-machine. (le gaussian blur est à la base de pas mal de filtres).
 
Et pis y a le décodeur jpeg standard à tester sur une machine pourvue de SSE2.
 
Et pis y a des machins plus violents, comme encoder les thumbnails sous forme de mip-maps pour ne pas tout charger lorsque la taille d'affichage n'est que du 64x64 par exemple.
 
Et plein d'autre trucs comme ça. Ce projet ne finira jamais.