Bonjour,
J'ai une question sans grand intéret, mais qui m'embête un peu.
 
hypot(a,b) (dans math.h) est sensé retourner sqrt(a*a + b*b).
Seulement, l'utilisation de hypot() (avec l'option -O3) me donne 163 cycles processeurs (les fonctions d'entrée-sortie sont utiles pour éviter les optimisations inconvenantes.

Maintenant le problème (si c'est réellement un problème), c'est quand je remplace hypot() par dist(), j'obtient 126 cycles processeurs.

A mon avis c'est:
  _Soit une histoire de pipeline.
  _Soit le fait que hypot() travail tout du long avec des double (Il y'a quand même sqrt() dans dist()).
 
Quoi qu'il en soit, si l'on travaille uniquement sur des entiers, c'est visiblement plus efficace de définir sa propre fonction.
 

Puisque tu y es, tu devrais également optimiser pour avoir un sqrt() qui ne travaille qu'avec des entiers. J'veux dire, autant aller jusqu'au bout, hein ?  

plus efficace mais plus limité aussi...
 
teste ta fonction avec a=b=32768 par exemple...

tu ne travaille pas uniquement avec des entiers puisque tu utilises sqrt ...  
 
et comme dis l'autre, bonjour les overflow.
 
si t'en es à faire de la parano de performances alors que t'en es à utiliser scanf, faudrait voir à arrêter la branlette intellectuelle. Fais un programme correct.
 

 
Pour le sqrt(), j'aurais pas du préciser en début de post que srqt() travail avec des double.
Pour les overflow, c'est indéniable... Mais pour des valeurs relativement limitées, ca le fait bien quand même
 
Bien entendu, faut être vraiment stupide pour insérer des operations d'entré-sortie dans une évaluation de temps (ou alors, pour une centaine de cycle, votre scanf est très rapide   <- je ne sais pas de qui viens l'incohérence). Je ne vois vraiment pas pourquoi je me mange tous les blâmes du monde, ca peut énormément servir dans certain cas (pas si rare que ça).
 

 
C'est vrai quoi, ca peut arriver de temps en temps de vouloir calculer la distance euclidienne, et de vouloir rester sur des entiers...  <- bien sûr c'est une blague, y'a qua voire la quantité d'interface graphique ou de wm (par ex,  pour gérer la distance entre 2 fenêtres) qui utilise soit cette fonction, soit une implémentation personnelle plus ou moins efficace. Alors, en 6 lignes de codes,  obtenir le 3/4 du temps d'une fonction (sensé optimisée), c'est bon à savoir, nen? Mais c'est vrai, elle est sur des réels...

Ou alors, histoire d'optimiser le bouzin vers le bas, hypot(a,b) retourne sqrt(pow((double)a, 2.0) + pow((double)b, 2.0))  

Pas la peine, John Carmack est là pour ça    
http://fr.wikipedia.org/wiki/John_Carmac