Sauf si vous bosser avec un CPU des années 80 ou sur un proc embarqué , vous ne pouvez pas prédire le temps d’exécution des instructions.
Un branchement sur x86 varie entre 0.5 et plus de 20 cycles.
Les pointeurs explicite pareil , pas regardé , mais les calculs d'adresses doivent eux aussi varier entre 0.25 et 5 cycles.
Les ARM 64 doivent être dans le meme ordre de grandeur mais ils ont moins de pénalité sur les branchements.
Sinon les dernières version de C# , le JIT est relativement performant et pas sur qu'on voit beaucoup de différence entre les deux , comme toujours celà dépend de l'implémentation.
Par contre non comment le C code et l'asm , y'a un petit monde ,surtout si on active les optimisations , seul le -O0 semble presque faire une traduction littéral.
Par contre c'est pas le C qui est proche de l'asm ,c'est plutôt l'inverse nombre de constructeur ont fait en sorte que les CPU fonctionne proche de ce que peut générer un compilateur , et encore c'est pas suffisant , quelque fois il faut une analyse poussé du code C pour faire les bonne optimisations.
Par contre juste un truc qui me fait tiquer :
Cette phrase n'a aucun sens , une fréquence est un intervalle dans le temps , elle ne sont pas de nature différente.parce qu'on écrit dans le cache à fréquence CPU plutôt qu'en RAM à fréquence mémoire.
Le cache CPU et la RAM ont certes une fréquence différente, mais ce n'est pas ça qui explique la différence d’accès (ça peut l'expliquer en partie).
Je sais comment fonctionne l'exécution dans un OS , niveau CPU ou software, ce n'était pas ma question.Bon, j'ai essayé de rendre ça compréhensible mais il suffit de retenir que les attaques ont lieu au runtime et non pas au design time.
Je comprenais pas le rapport avec le C.
Mais je pense pas qu'on parle de cybersécurité,que Rust ne résout en rien.
On parle de sécurité du code que le code s’exécute sans comportement indéfini.
Partager