Pour ce qui est du cout du bound check (en C++) avec des entiers non signés, c'est une opération:
k < n et avec des entiers non signés, c'est aussi une seule opération
static_cast<unsigned int>(k) < static_cast<unsigned int>(n) Comme le passage de int à unsigned int est une opération qui n'en n'est pas une pour le processeur, le cout est exactement le même. Il n'y a donc qu'un seul bound à vérifier. Je te promet que l'utilisation des entiers non signés n'a que des inconvénients et aucun avantage par rapport à des entiers signés.
Je pense que là où on ne se comprends pas est que tu parles souvent de collection et je parle de tableau. Qu'on traverse une liste chainée ou un tableau avec des itérateurs, on ne voit aucune différence dans le code source. Cela fait plaisir aux adaptes de la programmation générique, mais cela me gêne si on veut avoir une bonne image de la performance de ce qu'on écrit. Traverser une liste chainée est une catastrophe au niveau du cache alors qu'un tableau est la structure de donnée qui est la plus facile à traiter pour pour ce dernier.
Pour les mêmes raisons, l'utilisation d'OpenMP est basée sur l'indexation avec des entiers et ne marchera jamais avec des itérateurs tout simplement car cette abstraction fait qu'on oublie qu'on travaille avec un tableau.
Dans mon domaine (calcule scientifique), les itérateurs ne sont donc jamais utilisés. C'est aussi la raison pour laquelle le Fortran est encore très populaire dans ce domaine : c'est le langage qui a la meilleure implémentation des tableaux.
Sinon, question performance, j'aime beaucoup les conférences de Chandler Carruth qui s'y connait bien car il a travaillé longtemps sur l'optimiseur de LLVM : https://www.youtube.com/watch?v=fHNmRkzxHWs . Son discours se résume en une phrase : "Utilisez au maximum les tableaux".
[^] # Re: Une chose que j'ai oublié d'ajouter
Posté par InsideLoop . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 2.
Pour ce qui est du cout du bound check (en C++) avec des entiers non signés, c'est une opération:
k < n
static_cast<unsigned int>(k) < static_cast<unsigned int>(n)
Je pense que là où on ne se comprends pas est que tu parles souvent de collection et je parle de tableau. Qu'on traverse une liste chainée ou un tableau avec des itérateurs, on ne voit aucune différence dans le code source. Cela fait plaisir aux adaptes de la programmation générique, mais cela me gêne si on veut avoir une bonne image de la performance de ce qu'on écrit. Traverser une liste chainée est une catastrophe au niveau du cache alors qu'un tableau est la structure de donnée qui est la plus facile à traiter pour pour ce dernier.
Pour les mêmes raisons, l'utilisation d'OpenMP est basée sur l'indexation avec des entiers et ne marchera jamais avec des itérateurs tout simplement car cette abstraction fait qu'on oublie qu'on travaille avec un tableau.
Dans mon domaine (calcule scientifique), les itérateurs ne sont donc jamais utilisés. C'est aussi la raison pour laquelle le Fortran est encore très populaire dans ce domaine : c'est le langage qui a la meilleure implémentation des tableaux.
Sinon, question performance, j'aime beaucoup les conférences de Chandler Carruth qui s'y connait bien car il a travaillé longtemps sur l'optimiseur de LLVM : https://www.youtube.com/watch?v=fHNmRkzxHWs . Son discours se résume en une phrase : "Utilisez au maximum les tableaux".