Il faudrait que je le relise, mais quand il était sorti, il y avait des trucs qui m'avait fait tiquer, (mais j'ai oublié quoi :).
Il faut connaitre aussi un peu le genre de truc que sortent les compilo C, surtout avec la vectorisation automatique, en changeant un peu son code, le compilo peut faire plus de chose.
De plus, laisser faire le compilo marche bien pour les monstres comme les Intel core. Mais pour des trucs plus simple comme les PPC 603 (et donc les ARM des smartphone), tu te prends tous les problèmes des CPU les plus simple : prédiction de branchement statique, pas de prédiction de saut dynamique (vtable), très peu de write buffer (donc mélanger lecture et écriture est pénalisant), l'alignement mémoire est primordial, etc…
La doc d'AMD parle d'assembleur mais aussi de code C.
Par exemple, un code que l'on trouve dans le kernel linux, n'est pas intuitif :
for (i=0;i<N;tab+=4,i+=4){
tab[0] = tab[0] + n…
tab[1] = tab[1] + n…
tab[2] = tab[2] + n…
tab[3] = tab[3] + n…
}
C'est plus rapide car l'indexation d'un tableau par une constante, génère une seul instruction contrairement à "tab[i]" qui nécessite une addition.
Le cout d’usage des pointeurs est souvent négligé. Tous les codes utilisant des "str->foo" passe très souvent par la mémoire, plutôt que par un registre.
[^] # Re: Linux perf
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 4.
Il faudrait que je le relise, mais quand il était sorti, il y avait des trucs qui m'avait fait tiquer, (mais j'ai oublié quoi :).
Il faut connaitre aussi un peu le genre de truc que sortent les compilo C, surtout avec la vectorisation automatique, en changeant un peu son code, le compilo peut faire plus de chose.
De plus, laisser faire le compilo marche bien pour les monstres comme les Intel core. Mais pour des trucs plus simple comme les PPC 603 (et donc les ARM des smartphone), tu te prends tous les problèmes des CPU les plus simple : prédiction de branchement statique, pas de prédiction de saut dynamique (vtable), très peu de write buffer (donc mélanger lecture et écriture est pénalisant), l'alignement mémoire est primordial, etc…
La doc d'AMD parle d'assembleur mais aussi de code C.
Par exemple, un code que l'on trouve dans le kernel linux, n'est pas intuitif :
for (i=0;i<N;tab+=4,i+=4){
tab[0] = tab[0] + n…
tab[1] = tab[1] + n…
tab[2] = tab[2] + n…
tab[3] = tab[3] + n…
}
C'est plus rapide car l'indexation d'un tableau par une constante, génère une seul instruction contrairement à "tab[i]" qui nécessite une addition.
Le cout d’usage des pointeurs est souvent négligé. Tous les codes utilisant des "str->foo" passe très souvent par la mémoire, plutôt que par un registre.
"La première sécurité est la liberté"