Forums Développement Multimédia

Aller au contenu

Comprehension des Bytes

CODE Actionscript

33 réponses à ce sujet

#1 draad

  • Members
  • PipPipPipPipPipPipPipPip
  • 654 messages

Posté 17 May 2013 - 20:22 PM

Bonjour a tous,

Une question me turlupine ! Je sais qu'utiliser des fichier images dont la taille est un multiple de deux est plus optimise et plus rapide

par exemple 128x128, 256x256, 256x128

Je sais que c'est en rapport avec la facon dont les bytes sont stockes, mais je ne sais pas vraiment pourquoi c'est plus optimise ou rapide d'utiliser une texture de 128x128 plutot qu'une texture de 136x136, apres tout 136 = 128 + 8 qui sont tous deux des multiples de 2 !

Merci pour toute piste :)

#2 Monsieur Spi

  • Community Manager
  • PipPipPipPipPipPipPipPip
  • 7017 messages

Posté 17 May 2013 - 20:28 PM

Salut,

La réponse est "optimisation binaire".

Je n'en suis pas un pro, donc je laisse le soins aux autre de compléter et corriger ce que je vais dire mais pour la base voilà quelques pistes :

Le but est de consommer un minimum de ressources, et ce qui consomme le moins c'est les opérations sur les bits, le langage de base de la machine. Les jeux sont le plus souvent calibrés pour travailler ainsi, le binaire utilise une Base 2, c'est à dire qu'il ne comprend que deux chiffres (0 et 1) rangés en bits (4 chiffres) et en octets (8 chiffres), la plupart des jeux se cale donc sur des valeurs faciles à manipuler et qui sont des multiples puissances de 2.

Les opérations les plus fréquentes sont les multiplications et les divisions, ainsi une multiplication par 16 en Base 10 (celle qu'on utilise tous les jours) correspond à un décalage de 4 bits à gauche en Base 2 ( donc << 4 ). De même une division par 16 correspond à un décalage de 4 bits vers la droite ( donc >> 4 ).

Voyons quelques fondamentaux avec la multiplication (la division est identiques on inverse juste l'opérateur) :

Multiplication par 2 : X << 1
Multiplication par 4 : X << 2
Multiplication par 8 : X << 3
Multiplication par 16 : X << 4
Multiplication par 32 : X << 5
Multiplication par 64 : X << 6
Multiplication par 128 : X << 7
Multiplication par 256 : X << 8
Multiplication par 512 : X << 9
Multiplication par 1024 : X << 10

etc...

Attention, le résultat sera toujours un entier.

A partir de là on comprend mieux pourquoi il est préférable de se caler sur des tailles qu'il est facile de manipuler en binaire, donc pas 136 qui est plus dur à calculer que 128 ou 256. Ainsi une texture que l'on va stocker pixel par pixel dans un tableau sera plus facile à manipuler si on peut optimiser les calculs en binaire car après tout un bitmap est comme son nom l'indique un tableau de bits ( ref : http://fr.wikipedia....Tableau_de_bits ). Il en va de même pour les grilles et tout ce qui peut se réduire simplement à quelques opérateurs, on peut même pousser l'optimisation en utilisant des nombres entier de 32 bits non signés pour stocker les infos, par exemple pour les grilles :

Pour détecter la collision tout ce que nous souhaitons savoir c'est si une case est franchissable ou pas, ce qui peut se traduire par 0 = franchissable ou 1 = infranchissable, tient on dirait du binaire ... ;-) Or en binaire, un nombre entier non signé est une série de bits, si on souhaite écrire une grille de tuiles de 32 cases (par exemple 4 lignes et 8 colonnes) ont peut utiliser un entier non signé de 32 bits :

Voici une grille :

11111111
10000001
10000001
11111111

En binaire cela donne : 11111111 10000001 10000001 11111111
En entier décimal cela donne : 4286677503

Voilà ce que je peux en dire à mon niveau (en espérant ne pas avoir fait d'erreur).

Pour aller plus loin tu peux lire ces sujets :

http://forums.mediab...sation-binaire/
http://forums.mediab.../essais/binaire
http://forums.mediab...essais/binaire3
http://forums.mediab...ateurs_binaires
http://forums.mediab...jeu/tic_tac_toe

#3 Jano 95

  • Moderateur
  • PipPipPipPipPipPipPipPip
  • 4558 messages

Posté 17 May 2013 - 20:54 PM

Salut.

Voir le messagedraad, le 17 May 2013 - 20:22 PM, dit :

...utiliser une texture de 128x128 plutot qu'une texture de 136x136, apres tout 136 = 128 + 8 qui sont tous deux des multiples de 2 !

Je rectifierai en disant qu'il ne s'agit pas de multiple de 2 mais de puissance de 2.
128 = 27
256 = 28

#4 Monsieur Spi

  • Community Manager
  • PipPipPipPipPipPipPipPip
  • 7017 messages

Posté 17 May 2013 - 20:55 PM

+1 Jano

C'est le mot "puissance" qui me manquait, du coup je corrige aussi mon petit laïus, merci ;-)

#5 draad

  • Members
  • PipPipPipPipPipPipPipPip
  • 654 messages

Posté 18 May 2013 - 07:05 AM

Merci pour les explications !

Cependant je ne comprends toujours pas trop pourquoi, si les rangées de 0 et de 1 sont organisées en lot de 8 par exemple, il est plus optimisé d'utiliser 32 bytes que 24, 32 etant une puissance de 2, et 24 un multiple seulement.

En fait, si je déclare une texture de 128x128, sans alpha, est-ce que :
a ) chaque pixel est stocké dans un lot de 24 bytes
b ) chaque pixel est stocké dans un lot de 32 bytes avec 12 bytes "perdus"
c ) l'image est stockée dans un lot de 128x128, 16384 bytes ?

#6 Monsieur Spi

  • Community Manager
  • PipPipPipPipPipPipPipPip
  • 7017 messages

Posté 19 May 2013 - 11:39 AM

Quelques infos à lire sur le sujet de la résolution des textures :

http://en.wikipedia....BMP_file_format
http://fr.wikipedia....issance_de_deux
http://www.game-corp...esentation.html
http://jeux.developp...res_puissance_2
http://fr.wikipedia....iki/MIP_mapping
http://www.oocities....ming/bitmap.htm
http://www.iut-arles...-%20texture.pdf

Après, comme je l'ai dit plus haut, ce n'est pas ma tasse de thé, donc certains aurons certainement des explications plus claires et plus précises que les miennes ;-)

#7 dldler

  • Community Manager
  • PipPipPipPipPipPipPipPip
  • 4163 messages

Posté 19 May 2013 - 12:48 PM

NB :
Je me dois de cautionner ta qestion et ta surpris sur le 32 bits.
Mais il y a toutefois une réponse…


Les processeurs (le coeur du calculateur de l'ordi) ont été en 8 bits.
Avec 8 bits, on pouvait stocker une palette de 256 couleurs. C'était peu, mais en l'adaptant en cours d'exécution, on s'en sortait.
Pour aller au delà on s'est demandé combien de couleurs il fallait pour être "tranquille". Et l'équilibre qualité/coût des calculs a été chois à 256 valeurs par composantes. Comme il y a 3 composantes en video (R,V et B) on est arrivé au 24 bits. Mais il manquait encore la notion de transparence qui est très pratique. On a rajouté une couche et l'on est passé au 4x256 valeurs == 4x8 == 32 bits.
Le super calculateur s'est adapté pour être efficace. Et depuis on continu de doubler cette valeur : 64 bits et maintenant 128 bits.

L'info est donc traitée par "paquets" de 32 bits principalement pour gérer la couleur qui est très gourmande en calculs.

J'espère ne pas avoir raconté trop d'âneries des infos que j'ai accumulé au fil de l'évolution e l'informatique. :-)

#8 hubeert

  • Members
  • PipPipPipPipPipPipPipPip
  • 925 messages

Posté 19 May 2013 - 19:29 PM

coucou;
as tu des exemples ? plus rapide que quoi?et dans quel contexte.. ?(quel genre de traitement par exemple)
chaque pixel a une info sur 24 bit (3 octet)
en cas de couche alpha on rajoute un octet sois 8 bit par pixel.
Byte ca signifie octet dans la plupart des cas mais pas forcement lol
l'image est stockée dans 128*128 * par 24 ou 32 bit selon le cas
Une petite erreur..
"Voyons quelques fondamentaux avec la multiplication (la division est identiques on inverse juste l'opérateur) :

Multiplication par 2 : X >> 1
Multiplication par 4 : X >> 2"

c'est << , pour la multiplication

#9 draad

  • Members
  • PipPipPipPipPipPipPipPip
  • 654 messages

Posté 20 May 2013 - 21:49 PM

Merci pour les réponses, je vais lire et digérer tous les liens de Mr Spy avant de poser d'autres questions !

@ Hubeert, je n'ai pas d'exemple, on m'a dit et j'ai appris bêtement ce qu'on m'a dit, c'est pourquoi à présent je souhaite non plus faire bêtement mais connaître la raison du pourquoi :)

#10 hubeert

  • Members
  • PipPipPipPipPipPipPipPip
  • 925 messages

Posté 20 May 2013 - 22:27 PM

coucou;
Je ne sais pas; mais je n'ai jamais entendu parler de ca. A part la compression qui relève cependant d'un autre domaine. Je ne vois pas en quoi cela jouerai. Mais il a surement une explication..

#11 Monsieur Spi

  • Community Manager
  • PipPipPipPipPipPipPipPip
  • 7017 messages

Posté 21 May 2013 - 10:19 AM

Salut,

Citation

Mais il a surement une explication..
C'est de moi que tu parle en disant "il", ou il manque juste un "y" dans la phrase ?

Si c'est le cas, ce n'est pas moi qui ait dit que c'était plus optimisé et "rapide", mais Draad ;-)
Je ne fais que faire une association entre "binaire" et "puissance de 2" tirée de : http://fr.wikipedia....issance_de_deux

Citation

Je sais qu'utiliser des fichier images dont la taille est un multiple de deux est plus optimise et plus rapide

Ça me semble aussi logique, surtout si on reprend nos précédentes discutions où tu conseille de passer par des opérateurs binaires à chaque fois, si ça marche pour les calculs de base sur des listes ou des tableaux, je ne vois pas pourquoi ça ne marcherai pas pour les opérations sur les images (bitmap). Après je ne cache pas que le binaire ce n'est pas forcément un truc que j'utilise tous les jours, donc si ça se trouve ça n'est pas pertinent, je ne fais que donner des pistes qui me semblent logiques et appuyées par quelques recherches. Maintenant ce que l'on peut constater c'est qu'effectivement les textures sont généralement calées sur des résolutions qui sont une puissance de 2, c'est qu'il doit bien y avoir une raison...

Pour le "d'où ça vient", cela semble être expliqué ici : http://www.game-corp...esentation.html

Citation

L'un des points les plus importants pour une texture lorsque l'on en créer une c'est de suivre des résolutions « standard ». C'est à dire l'utilisation d'une résolution de puissance de 2, par exemple, 8x8 ; 32x32 ou encore 1 024x1 024. Pourquoi cela me dirait vous ? À cela 2 raisons précise. Tout d'abord, la première qui est la moins importante et est une questions de compatibilité ; en effet certain ancien hardware ne peuvent pas supporter des divisions autre qu'un multiple de deux. Cependant il est maintenant très rare de tomber sur du matériel aussi ancien. L'autre raison est elle est tout simplement matérielle là aussi, mais pour un réel gain de performances. En effet de nombreux hardwares actuels supportent des calculs de façon automatique, disposant d'information dans leur architecture qui évitent de faire le calcul (car connaissant déjà la réponse), le gain est plus qu'important !
Donc maintenant, pensez bien à régler vos images en conséquences. Il faut savoir qu'il est possible bien évidement de créer une texture ayant pour résolution 2 multiples de 2 différents, par exemple 256x512 reste dans les contraintes données.

Les cartes graphiques actuelles obtiennent des résultats plus rapides grâce à leurs architectures basées sur ces calculs.

Et pour le genre d'opération à mener, tu as l'exemple du MIP mapping : http://fr.wikipedia....iki/MIP_mapping

Citation

Le but du MIP mapping est d'éviter la pixelisation lorsqu'on s'éloigne d'une texture.

Le niveau de détail des textures est adapté à la distance de l'objet. Ainsi, un objet proche affichera des textures en haute résolution tandis qu'un objet lointain se verra attribuer une texture de faible taille. Différents niveaux de détails, dit MIP map levels, peuvent être choisis. Le MIP mapping consiste à envoyer au GPU des échantillons de texture de résolutions décroissantes qui seront utilisés à la place de la texture originale, en fonction de la distance du point de vue à l'objet texturé et du niveau de détails nécessaire. Le GPU n'a alors plus qu'à appliquer les bonnes textures sur les bons objets suivant leur éloignement, réadaptant la texture chaque fois que l'objet se rapproche. La texture utilisée lors du rendu sera alors celle dont la résolution est la plus proche de celle de l'objet sur l'image projetée.

Par exemple, à partir d'une image d'une taille de 256x256 pixels seront produits les mêmes images aux résolutions de 128x128 pixels, 64x64, 32x32, 16x16, 8x8, 4x4, 2x2 et 1x1. Si la taille de l'objet sur l'image projetée à l'écran est de 30x30 pixels, la texture utilisée sera alors celle de résolution 32x32 pixels.

Que le calcul soit automatique quand on a un GPU qui sait le faire, ou qu'il faille le faire soit même (cas de Flash sans Stage3D), il semble effectivement qu'utiliser des résolutions calées sur une puissance de 2 soit plus efficace qu'une résolution exotique.

Maintenant c'est vrai que de nos jours on peut utiliser des textures qui n'ont pas une résolution calée sur une puissance de 2, comme cela est expliqué ici : http://jeux.developp...ssance2_support

Mais il est toujours recommandé de rester calé sur des puissances de 2, comme expliqué ici : http://jeux.developp...res_puissance_2

Citation

Ces hardwares sont probablement obsolètes aujourd'hui donc ce n'est pas la raison pour laquelle on préfère toujours les dimensions en puissance de deux.
Les deux autres raisons sont la performance et la compatibilité avec toutes les fonctionnalités. Certaines opérations comme la division et les modulos sont beaucoup plus rapides en puissance de deux, et quasiment gratuites quand elles sont précablées sous forme de transistors ; ce qui fait que beaucoup de hardwares graphiques ne supportent la totalité des opérations que sur ce genre de textures pour économiser des transistors. [....]

Maintenant c'est plutôt toi l'aficionado du binaire ;-) à toi de nous dire si cela te semble pertinent.

Citation

Une petite erreur..
"Voyons quelques fondamentaux avec la multiplication (la division est identiques on inverse juste l'opérateur) :

Multiplication par 2 : X >> 1
Multiplication par 4 : X >> 2"

c'est << , pour la multiplication

Tout à fait exact, merci de le soulever, erreur d'opérateur de ma part, je corrige mon précédent post pour ne pas semer la confusion.

#12 hubeert

  • Members
  • PipPipPipPipPipPipPipPip
  • 925 messages

Posté 21 May 2013 - 10:54 AM

coucou;
Non il manque un y ; lol;je ne parle jamais de quelqu'un en disant il; c'est un peu trop condescendant..Il n'y a rien contre toi Monsieur Spi; je t'ai d'ailleurs deja dis mon respect et admiration pour ton travail et le partage que tu en fais.
J'ai simplement un jour pensé et écris que doué comme tu l’étais tu saurais tirer parti efficacement des Opérateurs sur le bit.(Mais il faut pas le prendre mal ; comme si j'etais le grand manitou "qui sait tout" et qui dispense ses conseils :roll: )
Après draad parle de fichier image j'ai compris bitmap.. Et pas texture ni maping.. lol Et a ce sujet merci pour les liens et les diverses explications.

"Maintenant c'est plutôt toi l'aficionado du binaire ;-) à toi de nous dire si cela te semble pertinent." Lol (tu me prête des connaissances que je n'ai pas).

#13 Monsieur Spi

  • Community Manager
  • PipPipPipPipPipPipPipPip
  • 7017 messages

Posté 21 May 2013 - 11:02 AM

Citation

Non il manque un y ; lol;je ne parle jamais de quelqu'un en disant il; c'est un peu trop condescendant..
Je m'en doutais mais je préférai préciser ;-)

Citation

je t'ai d'ailleurs deja dis mon respect et admiration pour ton travail et le partage que tu en fais.
Merci, mais comme beaucoup j'apprends aussi tous les jours.

Citation

Mais il faut pas le prendre mal
Je ne le prend pas mal lol, mais c'est vrai que tu en sais bien plus que moi sur les opérations binaires, un domaine que je maîtrise mal. Ce n'est pas une question de "tout savoir" mais d'en savoir plus que moi à ce niveau, ce que je respecte tout à fait ;-)

Citation

Après draad parle de fichier image j'ai compris bitmap.. Et pas texture ni maping.. lol
C'est pareil en fait, quelles que soient les images (bitmap) que tu veux utiliser tu sera confronté à des opérations à mener dessus, à moins de les utiliser à l'état brut sans aucune modification, ne serait-ce qu'une modification de taille, un déplacement, un scrolling, du placage de texture, etc....

Citation

"Maintenant c'est plutôt toi l'aficionado du binaire ;-) à toi de nous dire si cela te semble pertinent." Lol (tu me prête des connaissances que je n'ai pas).
Aficionado dans sa définition stricte, c'est à dire "amateur" (intéressé, curieux, ...) ;-)

#14 draad

  • Members
  • PipPipPipPipPipPipPipPip
  • 654 messages

Posté 21 May 2013 - 17:02 PM

NB : je n'ai aps encore lu tous les liens fournis par Mr Spy, excusez moi donc si ces derniers contiennent des informations importantes concernant ce que je vais dire plus bas, je lis tout ca peu a peu :)

Citation

Après draad parle de fichier image j'ai compris bitmap.. Et pas texture ni maping..

En fait, lorsque je load une texture, je stocke son bitmapData afin de pouvoir l'utiliser et le dupliquer a mon bon vouloir. C'est pourquoi je m'interresse de plus pres a la notion de Bytes et a comment optimiser l'utilisation de ces derniers.

Ensuite comme l'explique didier plus haut, on peut rajouter des "lots de 8 bytes".
8 c'est , 2 a la puissance 3, on est bien dans un schema de puissance de 2.
8 + 8 = 16, c'est aussi 2 puissance 4, toujours dans un schema de puissance de 2

Avant de reflechir a la suite la question serait de savoir si dans le fond, 16 est un lot de 16 bytes ou deux lots de 8 bytes.
Quelle difference ? Celle-ci se jouerait sur le 24 bytes par exemple. 24 bytes n'est pas une puissance de deux, toutes fois c'est bien le packetage de 3 lots de 8 bytes. Ainsi, si l'optimisation est d'utiliser un produit de 8, c'est nettement different que d'utiliser une puissance de deux.

Ma vision est peut-etre fausses, mais j'ai comme l'impressions que les lots sont de tailles fixes. Imaginons un lot de 8 bytes, si j'en utilise 6 alors j'en ai "perdu" 2, si j'en utilise 10, alors l'ordinateur couple deux lots de 8 et j'en "perds" 6.
Mais peut-etre qu'en verite, ils sont de tailles fluctuante. Ainsi un lot peut tres bien contenir, 2,4,8,32 ou 64 bytes dependement de ce qu'il doit stocker.

Comprenez vous ce qui me trouble?

#15 dldler

  • Community Manager
  • PipPipPipPipPipPipPipPip
  • 4163 messages

Posté 21 May 2013 - 17:19 PM

Je vais finir par avoir des doutes moi… :-)

Mais enfin…
-> Processeurs 32 bits : ça veut bien dire que le processeur traite des "mots" de 32 bits en une seule instruction. Un seul "cycle". D'où l'intérêt d'utiliser le plus possible de paquets de 32 bits… Sachant qu'une compatibilité 16 bits à été gardée, donc les "mots" de 16 bits restent très efficaces…



-> Processeurs 64 bits : des "mots" de 64 bits en une seule instruction. Un seul "cycle".
D'où l'intérêt d'utiliser le plus possible de paquets de 64 bits… sachant qu'une compatibilité 32 bits à été gardée, donc les mots de 32 etc…

etc

Non ?

#16 draad

  • Members
  • PipPipPipPipPipPipPipPip
  • 654 messages

Posté 21 May 2013 - 18:19 PM

Du coup, sur un processeur 32 bits :

Admettons une image de 1px * 1 px, si un pixel est une donnee couleur codee en couches de 8 bytes, alors il n'est pas plus optimise d'utiliser une image sans alpha (24bytes), que avec alpha (32 bytes), car le processeur est efficace sur 16 et 32, mais pas 24.

Parcontre une image de 3px * 1px avec alpha consommera la meme quantite de bytes qu'une image de 4px * 1px sans alpha (96bytes), ce qui nous fait gagner 1px, ou 32 bytes tous les 3 pixels ... *commence a avoir mal a la tete*


PS : D'ailleur, si tout ne se resume qu'aux bytes au final, pourquoi se soucier de la taille en pixel d'une image par exemple, au fond si l'ordinateur convertis l'image pour la stocker, 258 px * 254 px prennent le meme nombres de bytes que 256x256, non?

PS 2 : 256 pixels, dont chaque pixel vaux 24 bytes, c'est un total de 6144 bytes, qui n'est pas une puissance de deux. Une texture de 256x256 occuperait donc 37 748 736 bytes, ce qui n'est pas non plus une puissance de deux, les puissance de deux les plus proches sont 33 554 432 et 67 108 864.
Par contre 256 pixels dont chaque pixel vaux 32 bytes font un total de 8192 qui est une puissance de deux. Et donc 256x256 = 8192 x 8192 qui est aussi une puissance de deux

Ce qui voudrait dire que creer une texture de 256x256 en 24 bytes serait contre performant, et qu'il faudrait toujours utiliser le canal d'alpha, meme si celui ci doit etre vide. Ou alors trouver les tailles qui, multipliees par 24, aboutissent a une puissance de 2.

#17 dldler

  • Community Manager
  • PipPipPipPipPipPipPipPip
  • 4163 messages

Posté 21 May 2013 - 21:38 PM

1 :
258*254==65 532
256*256==65 536
Non, ce n'est pas pareil :-)

2:
Tu t'occupes de la somme totale des données. Je pense que c'est ça ton problème.
Ce qui compte, ce n'est pas la somme totale mais la longueur des "mots" de bits sur lesquels on fait des opérations. Tous les calculs sont saucissonnées en "types". Pour les valeurs ARVB en uint par exemple. Une valeur ARVB utilise 32 bits. Quand on fait une opération sur une valeur ARVB on utilise tous les bits, donc tout le temps de calcul est utile.
Bref, si on utilise pleinements les bits d'un mot, on exploite 100% du temps de calcul. Si on ne se sert que de 50% des bits du mot, on n'exploite que 50% du temps de calcul.

Après, je vois clairement comment le proc fait pour faire une addition de couleurs, de nombres entiers. Mais au delà, je suppose juste qu'il y a le même genre d'optimisations. Par exemple, pour déplacer un motif de 256, je sais que sa position est de 1, décalé de 8 bits * sa position dans la grille… Soit une opération sur les bits putôt qu'une multiplication. C'est plus rapide.
Si j'avais à la faire de façon optimisée :

- je copie le motif en position 1<<8 en x == j'obtiens un motif de 256*512
- je copie ce nouveau motif en position 1<<8 en y == j'obtiens un motif de 512*512

- je copie ce nouveau motif en position 1<<9 en x == j'obtiens un motif de 1024*512
- je copie ce nouveau motif en position 1<<9 en y == j'obtiens un motif de 1024*1024

etc.

Pas de multiplication, que des opérations sur les bits… Tu ne peux pas faire ça avec un motif de 258x254

#18 draad

  • Members
  • PipPipPipPipPipPipPipPip
  • 654 messages

Posté 21 May 2013 - 21:55 PM

Citation

1 :
258*254==65 532
256*256==65 536

Non, ce n'est pas pareil :-)

En fait ma logique c'etait plus :
258 * 32 + 254 * 32 = 16 384 bytes
256 * 32 + 256 * 32 = 16 384 bytes
258x254 px = 256x256 px = 16 384 bytes d'un cote comme de l'autre.


Mais effectivement, si ma vue du nombre de bytes total est fausse, alors toute ma logique va de travers.

#19 lilive

  • Moderateur
  • PipPipPipPipPipPipPipPip
  • 2993 messages

Posté 22 May 2013 - 09:40 AM

Salut tous,

Voir le messagedraad, le 17 May 2013 - 20:22 PM, dit :

Une question me turlupine ! Je sais qu'utiliser des fichier images dont la taille est un multiple de deux est plus optimise et plus rapide

Voir le messagehubeert, le 19 May 2013 - 19:29 PM, dit :

as tu des exemples ? plus rapide que quoi?et dans quel contexte.. ?(quel genre de traitement par exemple)

Voir le messagedraad, le 20 May 2013 - 21:49 PM, dit :

je n'ai pas d'exemple, on m'a dit et j'ai appris bêtement ce qu'on m'a dit, c'est pourquoi à présent je souhaite non plus faire bêtement mais connaître la raison du pourquoi :)

J'ai la même question que hubeert. Il me semble que ça mériterait un test.
Une recherche sur google ne m'a pas dit grand chose http://www.google.fr...22power+of+2%22 , j'y ai trouvé le conseil de faire ceci pour AIR sur android, mais sans explications, et puis ceci http://help.adobe.co...90204-7d5b.html
Ce dernier article semble dire qu'utiliser des bitmaps aux bonnes dimensions, et à condition de mettre leur propriété smoothing à false, va favoriser l'usage des mipmaps, ce qui sera intéressant si on affiche ces bitmaps à des tailles bien inférieures à celles de leur taille d'origine (peut-être même 50% et plus petit). L'intérêt est donc peut-être limité, et je trouve qu'il faudrait avoir plus de documentation ou faire des tests pour vérifier que ça vaut le coup de se préoccuper de la taille des bitmaps utilisés.

#20 draad

  • Members
  • PipPipPipPipPipPipPipPip
  • 654 messages

Posté 23 May 2013 - 17:00 PM

Citation

Quand on fait une opération sur une valeur ARVB on utilise tous les bits, donc tout le temps de calcul est utile.
Bref, si on utilise pleinements les bits d'un mot, on exploite 100% du temps de calcul. Si on ne se sert que de 50% des bits du mot, on n'exploite que 50% du temps de calcul.

Donc si le processeur est en 32 Bytes, et que je stocke la valeur RVB d'un pixel, je vais utiliser 24 bytes d'un mot de 32 bytes, ce qui fera 8 bytes "perdus" (j'entends par perdu, 8 bytes qui sont utilises et calcules mais n'ont aucune valeur)?

Pour le moment, je ne m'interresse pas tant aux operateurs que l'on peut appliquer aux bytes mais plus a savoir comment les donnes sont stockees.

Si je cree un une variable uint sur une machine en 32 bytes, alos l'uint prendra-t-il un mot de 32 bytes alors que sur une machine a 16 bytes il n'en prendra que 16 ? Est-ce possible de creer des mots de 8 bytes sur une machine en 32 bytes ?

Citation

L'intérêt est donc peut-être limité, et je trouve qu'il faudrait avoir plus de documentation ou faire des tests pour vérifier que ça vaut le coup de se préoccuper de la taille des bitmaps utilisés.

C'est tout a fait mon questionnement, et la piste se trouve peut-etre dans la comprehension profonde de comment la memoire est allouee. Comme dit plus haut, si je perds 8 bytes sur chaque pixel parceque j'utilise du 24 bytes par mot au lieu de 32 ... et que j'ai des milliers de pixels a stocker ... cela peut faire une grosse difference a la fin. Dans un autre sens, si ces 8 bytes restants ne sont pas perdus mais restent de la place disponible pour stocker des donnees, cela est un enorme gain.


Je n'ai pas d'exemple precis, cela reste purement theorique dans mon esprit pour le moment. Peut-etre qu'au fond 1 000 000 de bytes c'est un gros chiffre mais que c'est tres peu de performance, je n'en sais rien. Cependant, l'optimisation m'interresse, et l'optimisation c'est gratter un peu par ici, un peu par la ...

Au final comme dirait Raymond Devos :

Citation

Rien, c'est rien.
2 fois rien, bon c'est toujours rien
Mais 3 fois rien, c'est deja quelque chose


#21 Benzouye

  • Members
  • PipPipPipPipPipPipPipPip
  • 583 messages

Posté 23 May 2013 - 17:30 PM

Attention Draad, 1 byte = 1 octet = 8 bits
1 bit étant une valeur 0 ou 1 (ce qui permet la gestion par un transistor de la machine qui ne dispose que de deux etats).
1 pixel d'une image sera codé sur 3 ou 4 octets (bytes) selon si tu stockes l'alpha ou pas.

Une machine 32 bits (et pas bytes) pourra en un cycle d'horloge ( les fameux GHz ) travailler sur 32 bits = 4 octets de données avec le processeur (ou les sur un multicoeur).
Ceci est simplifié mais en gros juste.
Benzouye
Travaille avec FlashDevelop 4 + Flex SDK 4.6 open source

#22 dldler

  • Community Manager
  • PipPipPipPipPipPipPipPip
  • 4163 messages

Posté 23 May 2013 - 17:32 PM

Tu as raison de bien distinguer stockage et calcul, je crois.

Le stockage, bien fait, ne perds pas de bits. Les bits sont "poussés" dans un byteArray.
Du moment que le nombre de bits utilisé par valeur est constant, on tronçonne selon les besoins.

Si seul le stockage t'intéresse, alors il n'y a pas de différence entre un motif et un autre de même surface.
L'optimisation via des puissances de 2 ne concerne que les calculs processeurs et pas le stockage.

Si seul le stockage t'intéresse, un bitmapdata en RVB est plus léger que le même en ARVB

Si tu veux stocker le bitmapdata via un vector.<uint>, par contre, ça sera le même poids pour un RVB et un ARVB…
Là, c'est la logique du type qui s'applique. Et en AS, il n'y a que des types 32 bits, (uint, int, Number…). Dans d'autres langages c'est différent, il y a des short, des longs…

C'est pour ça que ta question :

Citation

Donc si le processeur est en 32 bytes bits, et que je stocke la valeur RVB d'un pixel, je vais utiliser 24 bytes bits d'un mot de 32 bytes bits, ce qui fera 16 bytes bits "perdus" (j'entends par perdu, 16 bytes bits qui sont utilises et calcules mais n'ont aucune valeur)?
…devrait plutôt être posée comme ceci :

Citation

Donc si me sers d'un type utilisant 32 bits pour stocker la valeur RVB d'un pixel, je vais utiliser 24 bits d'un mot de 32 bits, ce qui fera 16 bits "perdus"


#23 draad

  • Members
  • PipPipPipPipPipPipPipPip
  • 654 messages

Posté 23 May 2013 - 17:42 PM

Merci pour vos reponses !

Citation

Attention Draad, 1 byte = 1 octet = 8 bits
Haaaaa voila qui change deja pas mal la donne et denoue un des premiers noeuds de ma cervelle !

Citation

Et en AS, il n'y a que des types 32 bits
Cela veut-il dire que l'AS3 nest pas supporte sur les plateformes 8 et 16 bits ?
Et dans ce cas, utiliser un uint au lieu d'un Number n'est en rien plus optimise en AS3 ? Seule la valeur maximum pouvant etre stockee change ?

#24 dldler

  • Community Manager
  • PipPipPipPipPipPipPipPip
  • 4163 messages

Posté 23 May 2013 - 17:57 PM

Cela veut-il dire que l'AS3 nest pas supporte sur les plateformes 8 et 16 bits ?
Je n'en sais rien. C'est possible, mais ce n'est pas non plus obligatoire. Ça doit incomber au compilateur de gérer les types.- plus courts et plus longs que le "mot" du processeur.


Citation

Et dans ce cas, utiliser un uint au lieu d'un Number n'est en rien plus optimise en AS3 ? Seule la valeur maximum pouvant etre stockee change ?
Arrrrrgh :-)
Pas du tout. Toute la différence est là.
- question stockage, le poids en bits est identique.
- côté calculs, le processeur est beaucoup plus rapide pour gérer certains calculs sur les uint et les int, parce que chaque bit à le même rôle : il vaut la puissance de 2 de son rang. Alors qu'avec le type Number, certains bits ont un rôle différent : position de la virgule, mantisse, etc. Du coup le processeur doit décomposer bit-à-bit pour comprendre la valeur stockée avant de la traiter.

#25 Benzouye

  • Members
  • PipPipPipPipPipPipPipPip
  • 583 messages

Posté 23 May 2013 - 18:46 PM

Voir le messagedldler, le 23 May 2013 - 17:57 PM, dit :

Cela veut-il dire que l'AS3 nest pas supporte sur les plateformes 8 et 16 bits ?

Oui, je ne sais pas si des plateformes fonctionnelles existent encore en 8 ou 16 bits, mais le compileur mxmlc (.exe 32 bits) n'y fonctionnerait pas, et le flash player non plus ...

Voir le messagedraad, le 23 May 2013 - 17:42 PM, dit :

utiliser un uint au lieu d'un Number n'est en rien plus optimise en AS3 ? Seule la valeur maximum pouvant etre stockee change ?

Voir le messagedldler, le 23 May 2013 - 17:57 PM, dit :

côté calculs, le processeur est beaucoup plus rapide pour gérer certains calculs sur les uint et les int, parce que chaque bit à le même rôle : il vaut la puissance de 2 de son rang. Alors qu'avec le type Number, certains bits ont un rôle différent : position de la virgule, mantisse, etc. Du coup le processeur doit décomposer bit-à-bit pour comprendre la valeur stockée avant de la traiter.

Oui, excellente réponse de didier que je complèterais avec une différence entre le uint et le int, rendant le uint plus "performant" au calcul : le compileur devant interpréter le bit donnant le signe de l'entier et l'intégrer dans les calculs suivants, ce qui n'est pas le cas avec les uint ...
Benzouye
Travaille avec FlashDevelop 4 + Flex SDK 4.6 open source

#26 Galacta

    Etudiant Ingénieur

  • Moderateur
  • PipPipPipPipPipPipPipPip
  • 689 messages

Posté 23 May 2013 - 22:08 PM

Voir le messageBenzouye, le 23 May 2013 - 18:46 PM, dit :

Oui, excellente réponse de didier que je complèterais avec une différence entre le uint et le int, rendant le uint plus "performant" au calcul : le compileur devant interpréter le bit donnant le signe de l'entier et l'intégrer dans les calculs suivants, ce qui n'est pas le cas avec les uint ...

Ce que tu dis n'est pas valable dans tout les cas, et dépend de l'architecture utilisé par ton PC. De plus les ALU possédant des circuits de calcul signés / non signés la différence ne se fait pas ressentir. (En C par exemple, la différence est nulle)

De plus en ActionScript l'entier signé est bien plus rapide que l'entier non signé (cf : http://gskinner.com/..._in_as3_in.html)
Word hard, play hard.

#27 Benzouye

  • Members
  • PipPipPipPipPipPipPipPip
  • 583 messages

Posté 23 May 2013 - 22:21 PM

Merci pour la source galacta !

J'avais pourtant lu le contraire chez Thibault Imbert ... sur un benchmark de boucle for ...
Je ne trouve plus la source ...

Bon à savoir !
Benzouye
Travaille avec FlashDevelop 4 + Flex SDK 4.6 open source

#28 hubeert

  • Members
  • PipPipPipPipPipPipPipPip
  • 925 messages

Posté 24 May 2013 - 04:56 AM

coucou;

Malheureusement, le type uint s’avère généralement beaucoup plus
lent, dès lors qu’une opération mathématique est effectuée. En
revanche, le type Number s’avère plus rapide que le type int lors de
division.
Lors de la définition d’une boucle, il convient de toujours préférer
l’utilisation d’une variable d’incrémentation de type int :
var debut:Number = getTimer();
for ( var i:int = 0; i< 5000000; i++ )
{
}
// affiche : 61
trace( getTimer() - debut );
A l’inverse, si nous utilisons un type uint, les performances chutent
de presque 400% :
var debut:Number = getTimer();
for ( var i:uint = 0; i< 5000000; i++ )
{
}
// affiche : 238
trace( getTimer() - debut );
Gardez à l’esprit, qu’en cas d’hésitation, il est préférable d’utiliser le
type Number :
var debut:Number = getTimer();
for ( var i:Number = 0; i< 5000000; i++ )
17 / 36
Thibault Imbert

#29 Benzouye

  • Members
  • PipPipPipPipPipPipPipPip
  • 583 messages

Posté 24 May 2013 - 06:09 AM

OK , j'avais carrément tout de travers ...
Merci pour le redressement ...
Benzouye
Travaille avec FlashDevelop 4 + Flex SDK 4.6 open source

#30 dldler

  • Community Manager
  • PipPipPipPipPipPipPipPip
  • 4163 messages

Posté 24 May 2013 - 08:17 AM

Sauf que le travail de T. Imbert date maintenant et qu'il manque de précisions à mon goût.

1)
Il y a déjà une première chose pour faire un benchmark : utiliser l'instruction trace n'est pas efficace si on utilise le mode "tester l'animation". Sans doute à cause des opérations annexes de contrôle du processus. On obtiens des résultats différents en mode publication.
Pour cela, il vaut mieux utiliser des champs de texte et afficher le bench directement dans le swf.

2)
Ensuite, il faut utiliser des variables de même type pour le compteur et la borne de la boucle for. Sinon, on impose une conversion à chaque boucle et on fausse la comparaison des perfs. Soit : utiliser une borne typée uint si on a un compteur de type uint, une borne de type Number si on a un compteur de type Number, etc.

Comme ceci (avec les valeurs obtenues sur mon poste, publication Flash player 10) :

var debut:uint = getTimer();
var max_i:int=50000000;
var max_u:uint=max_i;
var max_N:Number=max_i;
for ( var i:int = 0; i< max_i; i++ )
{
}
// affiche : 122
t1.text=String( getTimer() - debut );

debut = getTimer();
for ( var j:uint = 0; j< max_u; j++ )
{
}
// affiche : 122
t2.text=String( getTimer() - debut );
debut = getTimer();
for ( var N:Number = 0; N< max_N; N++ )
{
}
// affiche : 192
t3.text=String( getTimer() - debut );
 

… Ou l'on voit que le type uint est aussi efficace que le type int. Le type Number est à la traîne.


PS : infos à prendre de toute façon avec des pincettes puisqu'à chaque sortie d'un nouveau player on obtiens des benchs différents (sans doute selon les pans du compilateur optimisés…).

#31 dldler

  • Community Manager
  • PipPipPipPipPipPipPipPip
  • 4163 messages

Posté 24 May 2013 - 08:30 AM

Et je viens de tester sur les opérations de base, en utilisant le même principe.

Addition, soustraction, multiplication :
- les types int et uint sont à égalité
- le type Number est à la traîne

Et effectivement, je le découvre :
- la division est à l'avantage du type Number
- le type uint est à la traîne du type int pour cette même division
Info intéressante pour certaines optimisations. Merci hubeert pour l'info.

Sinon j'insiste quand même parce que le type uint est déprécié à tors :
Hormis pour la division, les type int et uint sont aussi efficaces.

Code du test :

var debut:uint;
var max_i:int=100000000;
var max_u:uint=max_i;
var max_N:Number=max_i;
var i:int;
var u:uint;
var N:Number;
var t_i:int;
var t_u:uint;
var t_N:Number;
var d_i:int=5;
var d_u:uint=d_i;
var d_N:Number=d_i;

debut = getTimer();
for ( i = 0; i < max_i; i++ )
{
t_i=i+d_i;
}
// affiche : 320
t1.text=String( getTimer() - debut );

debut = getTimer();
for ( u = 0; u < max_u; u++ )
{
t_u=u+d_u;
}
// affiche : 320
t2.text=String( getTimer() - debut );
debut = getTimer();
for ( N = 0; N < max_N; N++ )
{
t_N=N+d_N;
}
// affiche : 390
t3.text=String( getTimer() - debut );
 


#32 hubeert

  • Members
  • PipPipPipPipPipPipPipPip
  • 925 messages

Posté 24 May 2013 - 09:52 AM

coucou;
tu dis qu'il faut utiliser le même type pour le compteur et la borne.. Il me semble que
tu fasses une erreur.

var debut:uint = getTimer();
var max_i:int=50000000;
var max_u:uint=max_i;
var max_N:Number=max_i,
trace (getQualifiedClassName(max_i))
trace (getQualifiedClassName(max_u))
trace (getQualifiedClassName(max_N))
 


#33 dldler

  • Community Manager
  • PipPipPipPipPipPipPipPip
  • 4163 messages

Posté 24 May 2013 - 10:23 AM

Alors, je veux bien répondre mais je re-dis que je n'ai absolument aucune compétences ni formation techniques.
Je ne fais que des constatations.

On a donc :
- un trace du type qui donne toujours int.
- mais malgré cela le temps de traitement des boucles est différent…
Alors ?

Je pencherais sur ceci :
Le trace du type me semble plus douteux que la constatation de la différence de temps de traitement. Non ?
Du coup, j'oserais supposer que quand on fait :
trace (getQualifiedClassName(max_i))
le : (max_i) est une évaluation et que c'est à ce moment que l'on perd le type.
Par contre, quand on fait : un_uint += un_autre uint, le calcul s'effectue typé.

2 autres trucs qui peuvent paraître surprenants, dans le même esprit, mais que je comprends de la même façon :

1
Le type renvoyé par getQualifiedClassName s'adapte à la valeur :
var max_i:int=-5;
var max_u:uint=2500000000;// Au delà de la borne supérieure de int
var max_N:Number=5000000000;// Au dela de la borne supérieure de uint
trace (getQualifiedClassName(max_i)); // int
trace (getQualifiedClassName(max_u)); // Number
trace (getQualifiedClassName(max_N)); // Number

2
Des résultats des différents selon que l'on type ou non une opération :
var un_uint:uint=5;
var un_autre_uint:uint=6;
trace(un_uint - un_autre_uint); // -1
// Mais :
un_uint = un_uint - un_autre_uint;
trace(un_uint); // 4294967295

Voilà. Ce ne sont que suppositions pour tenter d'expliquer les résultats vérifiés.
Sinon comment les expliques-tu ?

#34 hubeert

  • Members
  • PipPipPipPipPipPipPipPip
  • 925 messages

Posté 24 May 2013 - 12:00 PM

coucou
Je n'ai vraiment aucune idée de comment procède getQualifiedClassName(un_truc) et j'ai aucune compétence !! lol
l'utilisation de trace ou de ta manière il y a pas une grosse difference (2 ou trois millième de seconde des fois rien);
chez moi le traitement avec uint est un peu plus long et Number tres long
sinon j'ai pas d'explication.
Je pense aussi qu' Adobe améliore a chaque sorti le player et ceci explique la grosse différence en T.Imbert et tes test.



1 utilisateur(s) li(sen)t ce sujet

0 membre(s), 1 invité(s), 0 utilisateur(s) anonyme(s)