Reprise du message précédent :
Bon :
 
CA MARCHE !
 
J'ai testé pour deux, trois et quatre arguments et le gain est de bien 35%. Je suis pas a 50% de plus bicose les tests et le fait que j'ai pas MPT les tuples mais c deja encourageant
 
MERCI !!!!

plus le vecteur est grand, plus le surcout est négligeable. je savais bien que je déconnais pas tout à l'heure
edit: tu as fait avec des tuples ? si oui tu a gardé ma solution ou tu as fait un truc avec des références et tie ?

j'ai pas réfléchi, j'ai pris les tuples.
par contre les tuples boost s'arretent à 10 éléments. Va falloir que j'edite ca pour en avoir plus.
 
En clair je peut gagner 30-40% sur avant
bref maintenant j'ecris du code clair (r =x+y/2*ln(z)) et je profite de 70% de l'accéléeration max (x3 à x12)

cool. en effet pour les tuples. les boost::tuples sont vraiment chouettes

par contre tu as gardé comme moi des fonctions normales pas templates avec des numéros pour travailler les tuples ? par ce que sinon:
1) faut mettre un paramètre template Tuple en plus du numéro, pour Tuple, à moins de mettre la liste des 10args de Tuple, bref, la merde
2) la spécialisation partielle des fonctions n'étant pas possible, faut faire une classe
3) faut faire des t. template get<0>(), gaffe de pas oublier
4) et doit y avoir d'autres merdes ...

tu m'offres un bi-G4 ?

Je suis dessus
 

j'ai vu mais bon si je faitune classe avec les fonctions
en static ca devrait aller.
 

oui    
 

 
hmmm la je vois pas, je pense plutto que ca va etre a mon code
de se plier a sa.
 
 
Pour le bi-G4 y en a un en rab au labo mais on le agrde  

dernières remarques:
 
1) on peut manipuler mes UniqueLoader::Shared directement, en remplaçant la classe par un typedef et en faisant une fonction load(shread_ptr<Shared> )
 
2) quand y a pas beaucoup d'éléments ça va, la méthode benête des comparaisons fonctionnes, mais le cout est fonction de (N! / 2!) pour N>2 si je ne m'abuse. alors un joli DesignPattern Stratégie, une joli surcahrge de < et == (en utilisant les adresses), et à partir d'une certaine limite, on créer tous les UniqueLoader, on fout tout en conteneur, on trie, on parcours en fusionnant (affectation pour partager l'implémentation) les éléments égaux.  
l'algo à la con que j'ai filé, est bête et inefficace, (il doit y avoir plusieurs fois les meme comparaisons), mais il a le mérite de s'écrire facilement et l'invocation est simple (UniqueN(tuple)). ça serait interessant quand meme de voir si le compilo est pas capable de détecte les comparaisons en trop.
 
donc:
si y a beaucoup -> tri + affectation
sinon, la solution N² comme un tri par bulles: comparaison avec chaque élément, et si ==, on partage l'implémentation
 
le problème de ces solutions, c'est que l'allocation. il faut un truc genre tuple, bref un truc indexable et initialisable ( (obligatoirement, les reférences impose cela, à moins de fonctionner avec des adresses). avec un Array<N>, on peut std::sort, mais on ne peut pas initialiser (à moins de passer par des pointeurs), mais avec un Tuple, on doit passer par la méthode N² de comparaisons (pas d'itérations possibles). donc: soit passer à un fonctionnement avec des pointeurs directement, comme ça on peut faire un Array<UniqueLoader, N> et le remplir tranquillement, puis le std::sort ou N²; soit garder nos sympatiques tuples et garder la N².
 
le tout est donc de bien estimer les 3 méthodes: N!, N², et std::sort, en terme de cycle et de mémoire. N² me semble la plus appropriée, j'ai un peu peur de std::sort, à déterminer expérimentalement.

mon dernier mot