Optimiser des lectures de variables - Page 1

Voilà dans mon moteur 3D je lis les coordonnées des vertices transformés et projetés grâce à un index de faces.
Mais le code pour "extraire" ces coordonnées m'a l'air beaucoup trop lourd d'autant plus qu'il faut l'exécuter autant de fois qu'il y a de faces visibles.
Alors je me demandais si c'était possible de l'optimiser. Je suis déjà passer des triangles aux quadrilatère dans la gestion des polygones, mais il me semble qd même que c'est possible de réduire les accès à la mémoire... Par exemple en faisant une structure avec xa,xb,xc,xd et ya,yb,yc,yd et en faisant en memcpy par exemple ce qui permettrait de recopier en une seul fois le membre "vertex" de la structure Face_List.
Mais je ne sais pas trop comment faire.

typedef struct
{
int x;
int y;
int z;
int visible;
}VertexBuffer;

typedef struct
{
unsigned char color:2; // couleur de la face
unsigned short vertex[4]; // index des trois sommets
unsigned char polygone_type:1;
}Face_List;


int xa = Vertex_Buffer[Faces[i].vertex[0]];
int xb = Vertex_Buffer[Faces[i].vertex[1]].x;
int xc = Vertex_Buffer[Faces[i].vertex[2]].x;
int xd = Vertex_Buffer[Faces[i].vertex[3]].x;
int ya = Vertex_Buffer[Faces[i].vertex[0]].y;
int yb = Vertex_Buffer[Faces[i].vertex[1]].y;
int yc = Vertex_Buffer[Faces[i].vertex[2]].y;
int yd = Vertex_Buffer[Faces[i].vertex[3]].y;

Si vous avez d'autres solutions à me proposer n'hésiter pas à m'en faire part.
Et puis sinon j'aurais une petite question. Est-c'est qu'il est plus lent en C d'utiliser une structure qu'une simple variables ?
Par ex, si on utilise
int x;
int y;
int z;
Est-ce que c'est plus rapide que d'utiliser ? :
typedef struct
{
int x;
int y;
int z;
}ma_structure;
ma_structure structure_1;
...
structure_1.x;
structure_1.y;
structure_1.z;

Raphaël
: Par exemple en faisant une structure avec xa,xb,xc,xd et ya,yb,yc,yd et en faisant en memcpy par exemple ce qui permettrait de recopier en une seul fois le membre "vertex" de la structure Face_List.

Avec un memcpy tu 'iras pas plus vite que là : là tu extrais un à un les membres de ta structure. Un memcpy fait pareil, il copie une à une les données.

Mais je ne sais pas trop comment faire.

À la limite, ce que tu peux faire, mais je ne suis même pas sûr que ce soit plus rapide, c'est utiliser une union :
typedef struct
{
union
{
struct {short x,y;};
long xylong;
}xy;
union
{
struct {short z,visible};
long zvis;
}zvis;
}VertexBuffer;
(Je ne suis pas sûr de ne pas avoir fait d'erreur de syntaxe, enfin, le principe est là).
Pour recopier, tu peux extraire un long à chaque fois au lieu d'un short.

Et puis sinon j'aurais une petite question. Est-c'est qu'il est plus lent en C d'utiliser une structure qu'une simple variables ?
Par ex, si on utilise
int x;
int y;
int z;
Est-ce que c'est plus rapide que d'utiliser ? :
typedef struct
{
int x;
int y;
int z;
}ma_structure;
ma_structure structure_1;
...
structure_1.x;
structure_1.y; structure_1.z;

Ça prend exactement le même temps.

jackiechan
:

Raphaël
: Par exemple en faisant une structure avec xa,xb,xc,xd et ya,yb,yc,yd et en faisant en memcpy par exemple ce qui permettrait de recopier en une seul fois le membre "vertex" de la structure Face_List.

Avec un memcpy tu 'iras pas plus vite que là : là tu extrais un à un les membres de ta structure. Un memcpy fait pareil, il copie une à une les données.

Sauf qu'il copie short par short alors que memcpy copie long par long. Mais il y a d'autres trucs qui ralentissent avec memcpy (appel de fonction, tests d'alignement).

Et puis sinon j'aurais une petite question. Est-c'est qu'il est plus lent en C d'utiliser une structure qu'une simple variables ?
Par ex, si on utilise
int x;
int y;
int z;
Est-ce que c'est plus rapide que d'utiliser ? :
typedef struct
{
int x;
int y;
int z;
}ma_structure;
ma_structure structure_1;
...
structure_1.x;
structure_1.y; structure_1.z;

Ça prend exactement le même temps.

Pas sûr. Les scalaires sont plus rapides normalement. (Les optimiseurs de GCC ne traîtent pas toujours les structures de manière optimale.)

Kevin Kofler
:

jackiechan
: Avec un memcpy tu 'iras pas plus vite que là : là tu extrais un à un les membres de ta structure. Un memcpy fait pareil, il copie une à une les données.

Sauf qu'il copie short par short alors que memcpy copie long par long. Mais il y a d'autres trucs qui ralentissent avec memcpy (appel de fonction, tests d'alignement).

C'est vrai, c'est pour ça que j'ai proposé un truc après.

Ça prend exactement le même temps.

Pas sûr. Les scalaires sont plus rapides normalement. (Les optimiseurs de GCC ne traîtent pas toujours les structures de manière optimale.)

Je ne comprends pas pourquoi
Imaginons une structure :
struct structrure
{
short a,b;
};

dans une fonction, si on a :
struct structure var;
short c,d;

Pour accéder à var.a ou à var.b ou à c, ou d, on procède de la même façon, puisque les délcarations qu'on a écrites sont équivalentes à :
short a,b,c,d;

Je suis complètement à l'ouest ??

3 mots: "allocation de registres"...

Ah ok.
Je n'y avais pas du tout pensé.
Merci.

Un peu off-topic, mais bon...
Si vous voulez voir les effets d'un compilateur qui ne traite pas les structures de manière optimale (probablement à cause de l'allocation de registres, mais il y a aussi d'autres défauts tels que le move.b/w #0,d(an)), regardez donc l'event handler (attribute 0x4) de l'app interne TITABLED... Ca a l'air d'être pareil sur toutes les versions d'AMS (j'ai regardé avec 1.00, 2.03 et 2.09, le code est semblable), regarder sous AMS 2.xx suffit...
Bien que je n'aie pas vérifié, je pense que GCC ferait quand même mieux.

Un moteur 3D en C

Pourquoi pas?

lol Kevin
Déjà que celui de sBibi en ASM ne peut pas afficher bien vite, alors en C...

Le code généré par GCC n'est pas aussi catastrophique que ça.

Quand même.
Chaque fonction que j'ai dabord écrite en C et que je réécris en ASM se trouve nettement plus rapide en ASM.

Un moteur 3D en C

mdr

Pour la version de mon moteur qui est censé géré les BSP, j'utilise genlib donc pas tellement du C !
En plus je ne vois pas ce qui a de mal à codé le reste en C ?! J'ai augmenté les performance de 25 % en passant aux quadrilatère au passage (sauf que je les découpe en triangles )
Et puis vous trouvez que celui de sBibi il est lent ? Il y en a beaucoup qui disent que 12 Fps sur Ti ça suffit ... bah il y a encore du boulot pour le faire descendre aussi bas, surtout qu'il n'avait pas tout fini.

Chaque fonction que j'ai dabord écrite en C et que je réécris en ASM se trouve nettement plus rapide en ASM.

Oui mais ça ne dérange pas de programmer en bonne partie en C.

Le code généré par GCC n'est pas aussi catastrophique que ça.

C'est vrai que c'est pas si catastrophique que ça
L'idéal serait qu'il gèrent toutes les instructions mais je ne sais pas dans quelles mesures cela est possible.

Sinon je galère toujours pour les BSP (en fait c'est pas grand chose c'est juste rentrer les bonnes coordonnées pour que les feuilles s'affiche dans l'ordre) alors pour l'instant, bah ça s'arrête là.

Raphaël: 12.5 fps pour une animation continue suffisent ... mais pas pour un moteur 3D

Ouais, tu as raison. C'est clair qu'en dessous de 20 fps ça craint un peu.

-

Oui, mais il ,n'affiche pas tres vite par exemple un cube texturé ....

Un jeu en 3D filaire à 50 FPS c'est pas top. Si on veut du texturé, le moteur de sBibi tombe à quelques FPS et... c'est pas top non plus
Je pense qu'on ne pourra jamais faire quelque chose d'intéressant sur TI.

tout à fait, mais le fait qu'il ait essayé et réussi qqch de vraiment correct (~20 fps pour un mode rempli - pas texturé - en nvg) est deja tres bien.

Raphaël
:

Le code généré par GCC n'est pas aussi catastrophique que ça.

C'est vrai que c'est pas si catastrophique que ça L'idéal serait qu'il gèrent toutes les instructions mais je ne sais pas dans quelles mesures cela est possible.

C'est déjà pratiquement le cas. Le problème est qu'il faut avoir "l'idée" de les utiliser dans certaines conditions, ce qui n'est pas toujours le cas pour un compilateur comme GCC.

Il me semble que la dernière version de Trinity n'est pas représentative de ce qu'il pourrait lui faire faire

> L'idéal serait qu'il gèrent toutes les instructions mais je ne sais pas dans quelles mesures cela est possible.
>> C'est déjà pratiquement le cas.
En tout cas, la dernière fois que j'ai maté le code produit par TIGCC, j'ai constaté qu'il avait un mal fou à gérer les champs de bits :
- il ne connaissait pas bset.t
- il faisait autant de or.t qu'il y avait de mises à 1 sur un même mot, alors qu'il aurait pû regrouper ces mises à 1 en un seul or.t
GTC regroupe, lui

Il connaît bset, mais ne l'utilise pratiquement jamais. C'est un bogue connu, et j'essayerai de le résoudre pendant la phase de bêtas de TIGCC 0.95 (mais pas pour la bêta 1).

Quant au regroupement des or, dis-lui ce que tu penses au lieu d'utiliser un champ de bits.

GTC regroupe, lui

Je ne pense pas, si tu parles de flags.folder=1,flags.archived=1;... C'est vraiment le genre d'optimisation qui n'arrive que très rarement, ce serait vraiment une perte de place que de le gérer

Mais effectivement GTC connaît bset je pense

Pollux
:

GTC regroupe, lui

Je ne pense pas, si tu parles de flags.folder=1,flags.archived=1;... C'est vraiment le genre d'optimisation qui n'arrive que très rarement, ce serait vraiment une perte de place que de le gérer

En effet, il suffit de dire ce qu'on pense et mettre symentry->flags.flags_n|=0x0280;.

Bah on perd la clarté de lecture ! c'est ridicule quand on a les moyens d'avoir un compilo qui optimise !

J'espère vraiment que GCC fera cette optimisation.

Pollux
:

GTC regroupe, lui

Je ne pense pas, si tu parles de flags.folder=1,flags.archived=1;... C'est vraiment le genre d'optimisation qui n'arrive que très rarement, ce serait vraiment une perte de place que de le gérer

Merde, raté !
Je disais ça au hazard, en partant du constat "GTC est mieux que GCC"
On va dire que c'est l'exception qui confirme la règle.

> Bah on perd la clarté de lecture !
Il n'y a qu'à utiliser les constantes définies dans l'enum SymFlags. Ton argument -> poubelle.

> c'est ridicule quand on a les moyens d'avoir un compilo qui optimise !
C'est ridicule de se reposer sur le compilateur pour qu'il optimise tout seul un truc que tout le monde comprend, qu'il est trivial de faire à la main (c'est de la paresse que de ne pas le faire à la main).
Je te signale que dans TIFS, tu n'aurais pas le choix (ce qui est à mon avis la meilleure solution).

Je pense de plus que dans TIGCC, SF_HIDDEN devrait vraiment être mis deprecated et SF_INUSE, plus juste, utilisé à la place (c'est la dénomination utilisée dans tiams.h).

> J'espère vraiment que GCC fera cette optimisation.
Aucun intérêt. Pollux (#23) le dit lui-même...


Je me garde bien de commenter la fin de #25.

GTC c'est le meilleur hein XDanger #kiss#

> Il n'y a qu'à utiliser les constantes définies dans l'enum SymFlags. Ton argument -> poubelle.
lol. Mon champ de bits n'avait rien à voir avec les SYM_ENTRY. C'était pour les caractéristiques des symboles d'Azur (je voulais économiser la RAM en foutant les variables booléennes sur 1 bit).
Quand on les moyens d'avoir un compilo qui optimise, parcequ'on n'est pas limité par la mémoire et la vitesse comme sur TI, il faut en profiter pour éviter de complexifier le code (union + OU logiques entre constantes) je trouve. Tu ne vas pas me faire chier avec ça, c'est un point de vue personnel. Il faudrait que t'apprennes à respecter les opinions des autres, mais vu que tu viens du TICTborad -très connu pour son ouverture et sa diversité-, c'est pas gagné

> Aucun intérêt. Pollux (#23) le dit lui-même...
Il parle d'un compilateur limité par la plateforme de compilation (TI68k). Fais gaffe quand tu cites les autres.

> Je me garde bien de commenter la fin de #25.
Il n'y a aucun commentaire à faire, tu es bien le seul à avoir envie d'en faire un. C'est de l'humour, de l'ironie, pour blaguer. Mais tu ne connais pas ça. Normal, on ne t'a jamais vu blaguer

nEUrOO, arrête de le faire exprès juste pour faire chier...

> Il faudrait que t'apprennes à respecter les opinions des autres, mais vu que tu viens du TICTborad -très connu pour son ouverture et sa diversité-, c'est pas gagné
Board dont tu es un des seuls à t'être fait bannir pour ton comportement... Contrairement à certains ânes d'ici, on ne kicke / bannit pas juste après que quelqu'un ait donné une opinion qui n'est pas la nôtre.
Pour le reste, je ne vais pas en rajouter. Il y a au moins une énormité dans la phrase que je cite, j'espère que tu en es conscient, et j'attends que tu la trouves...

> Il parle d'un compilateur limité par la plateforme de compilation (TI68k)
Je ne l'ai pas pris comme ça, car "C'est vraiment le genre d'optimisation qui n'arrive que très rarement" ne s'applique pas qu'au TI-68k...
Ca n'est pas souvent qu'on te voit écrire "limité" à côté de "compilateur", en parlant de GTC. Il n'est pas limité par rapport à TIGCC que par la plateforme de compilation.

> Fais gaffe quand tu cites les autres.
La paille et la poutre, tu connais ? Ca s'applique aussi bien à toi qu'à moi.

> C'est de l'humour, de l'ironie, pour blaguer.
Un smiley après des conneries, pour dire que c'était de l'ironie... Que j'aime bien cette façon de se comporter !

> Mais tu ne connais pas ça. Normal, on ne t'a jamais vu blaguer
Faux. Tu as dû le manquer... Je sais très bien utiliser l'ironie.