Y a-t-il des modifications qui pourraient être apportées aux processeurs pour les rendre plus performants pour des exécutions simultanées comme Rust? Par exemple, y a-t-il des changements dans les implémentations de prédiction de branche ou les tailles de cache qui pourraient aider les exécutions simultanées?
J'ai l'impression que les conceptions actuelles du processeur pourraient être optimisées davantage pour des exécutions procédurales comme C. Si nous allions plutôt optimiser pour des exécutions simultanées, en quoi les processeurs seraient-ils différents?
Par exemple, la prédiction de branche a été mise en œuvre sur la base de généralisations établies dans des articles de recherche analysant les codes procéduraux. Je me demande si l'abstraction de concurrence ajoutera un ensemble de travail significatif à l'exécution qui aura un impact négatif sur les algorithmes de prédiction de branche existants. Par exemple, prédire dans une boucle for est une chose, mais lorsque la cible de la branche est toujours une nouvelle portion de mémoire (graphique, texte, etc.), ce sera toujours un échec de cache, et il n'y aura jamais de branche histoire pour elle-- parce que ni l'ont encore touché.
C'est probablement une question stupide parce que le contenu, bien qu'il puisse toujours être en RAM, sera ramifié à un ordre de grandeur inférieur à celui qu'il sera utilisé (une fois qu'il a été chargé dans le cache) ... mais quand même, il devrait être une limite temporelle observable aux contextes stockés dans le cache et les prédicteurs de branche dans un runtime procédural, qui se manifesterait comme une limite d'abstraction dans un environnement plus parallélisé. Je me demande donc ... Ces limites ont-elles été observées? Des articles de recherche ont-ils analysé cela?
Les architectures CPU sont-elles orientées vers le code procédural par rapport au code concurrent; ou les processeurs modernes sont-ils suffisamment polyvalents pour qu’un langage hautement simultané ne souffre pas?