Je comprends bien ce que tu veux dire, mais changer la fréquence, ça se voit, surtout sur un CPU fanless. Tu peux mesurer la consommation, la fréquence des bus, avec des outils externes. Je fais une réponse globale à tout tes messages, en gros pour moi, tu confonds benchs GPU et CPU, je dis pas que tu as complètement tords, je m'explique :
Certains drivers de GPU propriétaires ont des profiles en fonction de l'application que tu utilises, tu peux vraiment changer le comportement du pipeline et les performances pour 3 raisons (et demi) :
Les instructions exécutées par le pipeline ne sont pas accessibles à l'utilisateur final (on peut compiler dans un language intermédiaire, mais tu ne peux pas débugger ou tracer les compteurs HW associés aux unités), sur les cartes ayant de la RAM dédiée. L'utilisateur code des shaders, qui sont traduits par un compilateur dont on a pas les sources, il est possible de procéder à de nombreuses optimisations, pas générique, qui fournissent un résultat correcte. ÇA c'est de la triche.
Le GPU dispose de très nombreuses unité de calcul, idem, on a pas accès aux détails de ce qu'il se passe, hors l'implémentation des transistors et la localité des unités de calcul, font que tu as une énorme marge de manœuvre en terme de fréquence des unités et de désactivation d'unités.
Le switch de contexte sont bien moins nombreux, donc ça permet d'avoir un contexte qui soit bien plus complexe et qui porte plus d'info de customisation entre les applications.
Enfin, la demie raison, c'est qu'avec les anciennes API, avant DX10 et Vulkan, les drivers étaient de grosses machines à état, le potentiel d'optimisation était énorme...
Maintenant pour les bench CPU, le contexte est totalement différent, même si tu n'as pas accès aux sources de l'OS et du compilateur, tu as accès aux instructions, aux compteurs HW et tu peux analyser et tracer très facilement ce que tu veux.
Alors bien sûr, tu peux faire plein de micro-optimisations, comme (je vais te donner des idées) :
Changer la taille des pages ;
Changer l'affinité d'une thread avec un core ;
éviter l'éviction du cache de certaines données/instructions (je sais pas si c'est possible) ;
Même faire du prefetch
Tu peux faire tout cela, en effet, l'OS peut aussi changer le CAS de la mémoire directement, ou la fréquence du CPU...
Mais on peut aussi faire cela sous Linux! Alors que sur un Bench GPU, avec un driver propriétaire, tu ne peux rien faire.
Je veux bien admettre qu'Apple joue à ce petit jeux, mais je crois que personne ne se prive de le faire, et il n'y a pas grand chose de magique dans les benchs CPU, contrairement aux benchs GPU.
[^] # Re: quel forceur ce Martoni
Posté par YBoy360 (site web personnel) . En réponse au journal Le retour du RiscPC ?. Évalué à 3. Dernière modification le 02 novembre 2020 à 08:31.
Je comprends bien ce que tu veux dire, mais changer la fréquence, ça se voit, surtout sur un CPU fanless. Tu peux mesurer la consommation, la fréquence des bus, avec des outils externes. Je fais une réponse globale à tout tes messages, en gros pour moi, tu confonds benchs GPU et CPU, je dis pas que tu as complètement tords, je m'explique :
Certains drivers de GPU propriétaires ont des profiles en fonction de l'application que tu utilises, tu peux vraiment changer le comportement du pipeline et les performances pour 3 raisons (et demi) :
Les instructions exécutées par le pipeline ne sont pas accessibles à l'utilisateur final (on peut compiler dans un language intermédiaire, mais tu ne peux pas débugger ou tracer les compteurs HW associés aux unités), sur les cartes ayant de la RAM dédiée. L'utilisateur code des shaders, qui sont traduits par un compilateur dont on a pas les sources, il est possible de procéder à de nombreuses optimisations, pas générique, qui fournissent un résultat correcte. ÇA c'est de la triche.
Le GPU dispose de très nombreuses unité de calcul, idem, on a pas accès aux détails de ce qu'il se passe, hors l'implémentation des transistors et la localité des unités de calcul, font que tu as une énorme marge de manœuvre en terme de fréquence des unités et de désactivation d'unités.
Le switch de contexte sont bien moins nombreux, donc ça permet d'avoir un contexte qui soit bien plus complexe et qui porte plus d'info de customisation entre les applications.
Enfin, la demie raison, c'est qu'avec les anciennes API, avant DX10 et Vulkan, les drivers étaient de grosses machines à état, le potentiel d'optimisation était énorme...
Maintenant pour les bench CPU, le contexte est totalement différent, même si tu n'as pas accès aux sources de l'OS et du compilateur, tu as accès aux instructions, aux compteurs HW et tu peux analyser et tracer très facilement ce que tu veux.
Alors bien sûr, tu peux faire plein de micro-optimisations, comme (je vais te donner des idées) :
Tu peux faire tout cela, en effet, l'OS peut aussi changer le CAS de la mémoire directement, ou la fréquence du CPU...
Mais on peut aussi faire cela sous Linux! Alors que sur un Bench GPU, avec un driver propriétaire, tu ne peux rien faire.
Je veux bien admettre qu'Apple joue à ce petit jeux, mais je crois que personne ne se prive de le faire, et il n'y a pas grand chose de magique dans les benchs CPU, contrairement aux benchs GPU.