Mais j'ai bien compris, concernant mon int8_t, que sur une architecture 32 bits il va y avoir du zéro filling pour rester aligner sur 32 bits
Quand je parle d'alignement et de conception électronique, je parle au niveau des transfert vers ou depuis la mémoire centrale depuis ou vers le cpu. C'est à dire tout les instruction dont une des opérante est une adresse va faire en sorte que le cpu lise ou écrive depuis la mémoire centrale.
PS: Tu parle souvent d'architecture 32 bits mais je pense que de nos jours c'est le 64 bits qui domine, faudrait peut-être faire une petite mise a jours concernant la nouvelle architecture 64 bits, pour mettre a jour ton grand savoir.
4.1.1 Alignment of Words, Doublewords, Quadwords, and Double Quadwords
Words, doublewords, and quadwords do not need to be aligned in memory on natural boundaries. The natural
boundaries for words, double words, and quadwords are even-numbered addresses, addresses evenly divisible by
four, and addresses evenly divisible by eight, respectively. However, to improve the performance of programs, data
structures (especially stacks) should be aligned on natural boundaries whenever possible. The reason for this is
that the processor requires two memory accesses to make an unaligned memory access; aligned accesses require
only one memory access. A word or doubleword operand that crosses a 4-byte boundary or a quadword operand
that crosses an 8-byte boundary is considered unaligned and requires two separate memory bus cycles for access.
note: word = 16bit, double = 32, quad = 64. On peut lire que l'alignement minimum d'un cpu 32 ou 64 bit est 16 bit en utilisant les instructions travaillant avec des opérantes de 16 bits uniquement!!! Il n'est mentionné nul part quel est l'alignement naturel des opérations qui travaillent sur un byte, genre MOVZB. On peut raisonablement penser dire que l'alignement minimum des archi Intel 32 et 64 bit est de 2 octets. Mais bon, peut-être qu'effectivement il n'y a jamais de problème d'alignement en utilisant les instruction avec une "memory operand" de 8 bits. Ensuite le manuel écrit textuellement que pour un accès non aligné le cpu doit réaliser deux accès alignés, ce que j'ai tenté de vous expliquer au moyen d'une illustration.
Par ailleurs il se peut que le compilateur s'arrange pour faire un alignement optimal tout seul. Quand vous utilisez un tableau int8[], ben il ne peut pas ajouter du padding entre chaque élément et vous êtes à peu près sûr que 1 octets sur 2 ne sera pas aligné sur 16 bit, 3/4 sur 32 et 7/8 sur 64. Dans le cas d'une structure il est très facile de "désaligner" certains membres en intercallant des membres plus petits. Une recherche sur "C structure packing alignment" vous donnera des résultats très pertinents à ce sujet. Quant à moi je m'arrête ici dans l'espoir de ne pas vous perturber d'avantage. Je voulais simplement vous donner une réponse à votre question "est-ce qu'utiliser des int8 rend mon code plus rapide", celle-ci est "non sauf si vous avez de grosses contraintes mémoire (et que vous ne faites pas de padding!!!) ou que ces int8 n'entrainent pas un désalignement d'autres variables/membres". Je vous concède que j'aurais peut-être mieux fait de m'abstenir d'entrer dans de telles considérations de micro-optimisation car il est évident que même si utiliser un int8 serait légèrement plus rapide (ce dont je doute très sincèrement mais bon je n'arrive pas à trouver la preuve alors admettons*), vous n'aller rien gagner du tout compte tenu de la complexités des bibliothèques et systèmes graphiques que vous utilisés.
PS1: J'accepte vos excuses mais tâchez quand même d'être moins abrasif envers ceux qui veulent vous faire avancer. Btw je suis aussi un autodidacte, je ne prétend pas avoir la science infuse et je me trompe naturellement assez régulièrement. Je ne vous dois rien si ce n'est le respect. Je vous souhaite donc de persévérer, et dites vous bien que ce qui ne fait pas de sens aujourd'hui en fera sûrement demain.
*: Sur ce document il est montré sur un ensemble de processeurs différents qu'un mov de 32 bit n'est pas plus rapide qu'un de 64 bit, c'est identique voire dans certains cas plus lent...: https://gmplib.org/~tege/x86-timing.pdf
[^] # Re: C++ type et performances
Posté par benja . En réponse au message pre-realease de battle-rage un jeu de combat a la street fighter.. Évalué à 2. Dernière modification le 26 octobre 2016 à 01:10.
Quand je parle d'alignement et de conception électronique, je parle au niveau des transfert vers ou depuis la mémoire centrale depuis ou vers le cpu. C'est à dire tout les instruction dont une des opérante est une adresse va faire en sorte que le cpu lise ou écrive depuis la mémoire centrale.
L'archi 64 bit étant rétro-compatible avec la 32, cela ne change rien, à taille d'opérante ou instruction identique! De plus vous comprendrez qu'il m'a bien fallut trouver un exemple et que je n'ai pas la prétention de vous faire un exposé exhaustif. Je vous renvois donc vers la section du manuel d'intel pour plus de précisions http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf
note: word = 16bit, double = 32, quad = 64. On peut lire que l'alignement minimum d'un cpu 32 ou 64 bit est 16 bit en utilisant les instructions travaillant avec des opérantes de 16 bits uniquement!!! Il n'est mentionné nul part quel est l'alignement naturel des opérations qui travaillent sur un byte, genre MOVZB. On peut raisonablement penser dire que l'alignement minimum des archi Intel 32 et 64 bit est de 2 octets. Mais bon, peut-être qu'effectivement il n'y a jamais de problème d'alignement en utilisant les instruction avec une "memory operand" de 8 bits. Ensuite le manuel écrit textuellement que pour un accès non aligné le cpu doit réaliser deux accès alignés, ce que j'ai tenté de vous expliquer au moyen d'une illustration.
Par ailleurs il se peut que le compilateur s'arrange pour faire un alignement optimal tout seul. Quand vous utilisez un tableau int8[], ben il ne peut pas ajouter du padding entre chaque élément et vous êtes à peu près sûr que 1 octets sur 2 ne sera pas aligné sur 16 bit, 3/4 sur 32 et 7/8 sur 64. Dans le cas d'une structure il est très facile de "désaligner" certains membres en intercallant des membres plus petits. Une recherche sur "C structure packing alignment" vous donnera des résultats très pertinents à ce sujet. Quant à moi je m'arrête ici dans l'espoir de ne pas vous perturber d'avantage. Je voulais simplement vous donner une réponse à votre question "est-ce qu'utiliser des int8 rend mon code plus rapide", celle-ci est "non sauf si vous avez de grosses contraintes mémoire (et que vous ne faites pas de padding!!!) ou que ces int8 n'entrainent pas un désalignement d'autres variables/membres". Je vous concède que j'aurais peut-être mieux fait de m'abstenir d'entrer dans de telles considérations de micro-optimisation car il est évident que même si utiliser un int8 serait légèrement plus rapide (ce dont je doute très sincèrement mais bon je n'arrive pas à trouver la preuve alors admettons*), vous n'aller rien gagner du tout compte tenu de la complexités des bibliothèques et systèmes graphiques que vous utilisés.
PS1: J'accepte vos excuses mais tâchez quand même d'être moins abrasif envers ceux qui veulent vous faire avancer. Btw je suis aussi un autodidacte, je ne prétend pas avoir la science infuse et je me trompe naturellement assez régulièrement. Je ne vous dois rien si ce n'est le respect. Je vous souhaite donc de persévérer, et dites vous bien que ce qui ne fait pas de sens aujourd'hui en fera sûrement demain.
*: Sur ce document il est montré sur un ensemble de processeurs différents qu'un mov de 32 bit n'est pas plus rapide qu'un de 64 bit, c'est identique voire dans certains cas plus lent...: https://gmplib.org/~tege/x86-timing.pdf