Indianness -> DMC - Page 1

Bon nouvel épisode de galère... avec ce cher ppc.
ppc: big indian
x86: little indian
format map q3: little indian.

Donc forcément vu que je charge les données à l'aide de
fread(&Header,sizeof(SBspHeader),1,_pFile);
avec

     14         typedef struct
     15         {
     16             char String[4];
     17             int Version;
     18             SBspLumpEntry LumpEntry[17];
     19         } SBspHeader;

et idem pour tout le reste (ce qui fait pas mal de choses), j'ai de gros problèmes d'indianness...

Qqn à déjà fait face à ce problème, et a trouvé une solution simple, rapide et efficace?

Merci

hmm nop perso j'avais même pas cherché à trouver une solution propre, ça a été "ah ouais ? bah fuck les mac" direct; mais pkoi ne pas jeter un coup d'oeil aux sources de q3 pour voir comment ils s'en sont tirés ? (par contre faut prévoir un petit moment pr trouver ce que tu cherches dans ces sources )

Parce que le gars qui a fait le package de source a fait un exe

de quoi un exe ? (pas capté le pb là.. les sources sont dans un .exe ? tu peux pas les ouvrir sur ton pc ?)

sinon la solution que j'ai gardée pr un loader en java (donc où ça aurait été con de se priver d'osx), c'est simplement de se taper la lecture de tous les champs des structures à la main... c'est laid ms j'ai rien trouvé de mieux :/ (et si t'as déjà codé tout ton loader ça risque d'être légerement chiant de tout modifier ^^)

plutot que de les lire 1 a 1 a la main, je pense que c'est quand meme mieux de quand meme lire la structure d'un coup, et de juste swapper les champs un a un apres, ca t'evites quand meme de faire des tonnes de reads de quelques octets chacuns :/ (enfin vu qu'a priori le truc qui prend le plus de temps dans le loading d'un bsp Q3 c'est pas les fread, tu t'en fous probablement )

mais bon, a part flipper les champs a la main, non, je vois pas trop ce que tu peux faire d'autre... (sauf en passant par des macros, ca serait peut etre plus pratique si t'as beaucoup de structures comme ca a lire... par contre tu devras te taper la declaration de ta structure en macros aussi, et bon... on aime ou pas (mais d'un autre cote, apres, t'as juste une ligne a ecrire pour flipper l'endian de la structure entiere, donc ca sert certes a rien si tu dois la flipper qu'une fois quand tu la lis, mais ca peut devenir interessant si tu dois le faire a plusieurs endroits !=, genre si tu lis _et_ que t'ecris ta structure.. hmm.. bref...)

tiens, un exemple de ce que je voulais dire par utiliser des macros:

qqch du genre:

/*
**
*/

#define	FLIP_ENDIAN_0(v)
#define	FLIP_ENDIAN_1(v)
#define	FLIP_ENDIAN_2(v)	SWAP_16(v)
#define	FLIP_ENDIAN_4(v)	SWAP_32(v)

#define	GLUE(a, b)		__GLUE(a, b)
#define	__GLUE(a, b)		a ## b

#define	DECL_FILE_FIELD(type, name, flip_code)	type	name;
#define	FLIP_FILE_FIELD(type, name, flip_code)	GLUE(FLIP_ENDIAN_, flip_code)((FLIP_FILE_FIELD_STRUCT_SYM).name)




// declaration de la structure dans le .h:

#define	EN_SPACE_FILE_HEADER_FIELDS			\
	FILE_FIELD(BYTE, id[4], 0),			\
	FILE_FIELD(WORD, version, 2),			\
	FILE_FIELD(float, curvature, 4),		\
	FILE_FIELD(HH_UINT32, seed, 4),			\
	FILE_FIELD(t_en_space_constants, constants, 0)

#define	FILE_FIEDL	DECL_FILE_FIELD
typedef struct
{
  EN_SPACE_FILE_HEADER_FIELDS;
}			t_en_space_file_header;
#undef	FILE_FIELD



// et pour s'en servir:

{
  t_en_space_file_header	pwet;

  fread(&pwet, sizeof(pwet), 1, fp);

#define	FILE_FIEDL			FLIP_FILE_FIELD
#define	FLIP_FILE_FIELD_STRUCT_SYM	pwet

  EN_SPACE_FILE_HEADER_FIELDS;

#define	FLIP_FILE_FIELD_STRUCT_SYM
#undef	FILE_FIELD

}

(bon ca marche probablement pas tel quel, mais l'idee est la )
(et c'est certes legerement moins lisible qu'une declaration "normale" , mais ca peut devenir tres pratique selon l'utilisation que t'en fais...)

tiens, sinon, une version peut etre un peu moins chiante:

/*
**
*/

__forceinline	flip_endian(void *ptr, int size)
{
  switch (size)
    {
      case	2:
	SWAP_16(ptr);
      case	4:
	SWAP_32(ptr);
      case	0:
      case	1:
      default:
	return;
    }
}

#define	DECL_FILE_FIELD(type, name, flip_code)	type	name;
#define	FLIP_FILE_FIELD(type, name, flip_code)	flip_endian(&((FLIP_FILE_FIELD_STRUCT_SYM).name), sizeof(type));

// declaration de la structure dans le .h:

#define	EN_SPACE_FILE_HEADER_FIELDS			\
	FILE_FIELD(BYTE, id[4]),			\
	FILE_FIELD(WORD, version),			\
	FILE_FIELD(float, curvature),			\
	FILE_FIELD(HH_UINT32, seed),			\
	FILE_FIELD(t_en_space_constants, constants)

(au fait..
"#define FLIP_FILE_FIELD(type, name, flip_code) flip_endian(&((FLIP_FILE_FIELD_STRUCT_SYM).name), sizeof(type)); "

pas

"#define FLIP_FILE_FIELD(type, name, flip_code) flip_endian(&((FLIP_FILE_FIELD_STRUCT_SYM).name), sizeof((FLIP_FILE_FIELD_STRUCT_SYM).name)); "

sinon ca merderait pour les trucs du genre "BYTE plop[4]", ou a priori tu veux pas que ca les flippe...)

sBibi :
plutot que de les lire 1 a 1 a la main, je pense que c'est quand meme mieux de quand meme lire la structure d'un coup, et de juste swapper les champs un a un apres, ca t'evites quand meme de faire des tonnes de reads de quelques octets chacuns :/ (enfin vu qu'a priori le truc qui prend le plus de temps dans le loading d'un bsp Q3 c'est pas les fread, tu t'en fous probablement )

ça dépend de l'implémentation de fread ou fgetc, mais si elle est bien foutue (par exemple si le compilo est capable d'inliner, ou alors si on utilise getc() qui est défini pour être une macro) ça sera au contraire plus performant sur des structures qui tiennent pas dans le cache, parce que ça évite de devoir stocker avec le mauvais endianness en ram puis de devoir relire/réécrire entièrement

personnellement j'implémenterais ça avec des macros qui permettent à la fois de définir la structure et les fonctions de (dé)sérialisation ^^

Pollux> hum.. je sais pas trop ce que font exactement les fread/getc, mais a priori, que ca soit inline ou pas, j'aurais eu tendance a penser que ce qui etait problematique c'etait le tres probable appel systeme / acces au fichier? (sauf evidemment si il est mmappe... a moins que ca soit justement le comportement par defaut, mais...) enfin si ca se trouve le simple fait que fread soit inline peut etre suffisant, j'en sais rien, mais ca m'etonne quand meme

mais de toute façon il doit y avoir un buffer du côté de la libc pour éviter de faire 4k appels systèmes quand on lit un fichier de 4ko ^^ (et au pire même si les fonctions de stdio ne sont pas inlinées on peut toujours rajouter son propre buffer, si la performance est si importante que ça...)

mais de toute façon il doit y avoir un buffer du côté de la libc pour éviter de faire 4k appels systèmes quand on lit un fichier de 4ko ^^

bah wai, mais dans ce cas le cache se fait trasher aussi quoi que tu fasses si tu fread() trop d'un coup non? (que ca soit trop de fread() ou un fread() trop gros (EDIT: par la je veux dire, que ca soit le cache pour ta structure, ou pour le buffer interne de la libc))
mais.. oui, decouper la lecture de la structure en plusieurs freads chacun un peu plus petit que la taille du cache ca doit etre bon... (d'un autre cote, pour que ta structure tienne pas dans le cache, elle doit etre belle a voir , et le coup du swap des champs (sauf si c'est une structure de 10000 chars et 1 int32 ), est sans doute plus eleve que celui d'un trash de cache (en tout cas, dans le cas de Jackosking, si j'ai bonne memoire, il n'y aucune structure dans le format bsp de Q3 qui approche, meme de loin, la taille d'un cache normal...))

EDIT: soit dit en passant, Jackosking, en fait dans le ./7 ca marche pas pour des structures, comme la structure 'constants' dans l'exemple, si le sizeof de la dite structure est == 2 ou == 4 (ou == 8), mais qu'a l'interieur il y a des variables separees dont le sizeof est != de celui de la structure..

mais.. oui, decouper la lecture de la structure en plusieurs freads chacun un peu plus petit que la taille du cache ca doit etre bon...

ben, oui, ou même nettement inférieurs à la taille du cache, du moment que ça suffit à rendre l'overhead de l'appel à fread() négligeable (sachant qu'il y a un facteur 60 entre la lecture d'un fichier à coup de fgetc() et à coup de fread() qui tiennent dans le cache, un buffer d'un peu plus de 256 octets devrait suffire à masquer l'overhead)

sBibi :
et le coup du swap des champs (sauf si c'est une structure de 10000 chars et 1 int32 ), est sans doute plus eleve que celui d'un trash de cache

euh, c'est tellement coûteux de thrasher le cache que je vois pas vraiment comment on pourrait se débrouiller pour avoir un swap encore plus coûteux que ça

~/desktop $ gcc -std=c99 -Dop=not -O2 x.c -o x && time ./x
./x 0.37s user 0.23s system 73% cpu 0.828 total
~/desktop $ gcc -std=c99 -Dop=swap -O2 x.c -o x && time ./x
./x 0.33s user 0.28s system 68% cpu 0.886 total

(et swap() est tout sauf optimisée)

ah oue... soit... (pour le cout des swap (tu peux poster le code de tes .c par curiosite? parceque ca m'etonne quand meme que re-remplir une cache line soit plus couteux que de swapper toutes les donnees qu'elle contient.. (hormis si le CPU a une instruction speciale pour, a la limite la ok.. mais.. ))

et si c'est un enorme tableau de structures qui tient pas du tout dans le cache, que tu dois retoucher apres, evidemment, la je suis tout a fait d'accord sur l'impact sur les perfs que ca aurait de faire un enorme fread, puis de re-modifier toutes les structures unes a unes... la evidemment qu'il vaut mieux faire des freads() par blocs (par multiples de, et alignes avec, la taille des cache lines, tant qu'a faire...), mais bon, je me suis appercu que tu voulais probablement parler de ca seulement apres avoir lu ton ./12

(hum.. legere deviation de topic spotted.. dsl bob )
(au fait, juste comme ca, Jackosking, c'est Endian, pas Indian ^^)

sBibi :
ah oue... soit... (pour le cout des swap (tu peux poster le code de tes .c par curiosite? parceque ca m'etonne quand meme que re-remplir une cache line soit plus couteux que de swapper toutes les donnees qu'elle contient.. (hormis si le CPU a une instruction speciale pour, a la limite la ok.. mais.. ))

euh, je parlais du cas où ça tient pas dans le cache justement (c'est bien ce que tu voulais dire par "thrash de cache", non ?), et là c'est assez normal que le swap soit négligeable par rapport au transfert à partir de la ram ^^

sBibi :
(au fait, juste comme ca, Jackosking, c'est Endian, pas Indian ^^)

mais sinon tu peux dire ça en termes de MSB first ou LSB first, histoire qu'on comprenne de quoi il s'agit (pq en fait entre little endian et big endian je ne me souviens jamais lequel est lequel (si tant est que je l'aie jamais su). Bon certes en pratique on s'en fout de savoir lequel est lequel, ce qui est important c'est de savoir si c'est le même ou si c'est l'autre, mais quand même )

Pollux :
euh, je parlais du cas où ça tient pas dans le cache justement (c'est bien ce que tu voulais dire par "thrash de cache", non ?), et là c'est assez normal que le swap soit négligeable par rapport au transfert à partir de la ram ^^

vi vi.. c'est ca que je voulais dire, et.. t'as raison, aller chercher 64 octets en ram tous les 32 ou 16 swaps doit etre largement plus lourd effectivement, je sais pas a quoi je pensais , et je suis d'accord avec le coup de bufferiser tes freads par blocs pour rendre l'overhead du fread negligeable quand tu lis de grosses structures, ou en tout cas de gros tableaux de structures...

(mis a part que c'est un gros bordel )

mais c'est pas ce sur quoi je discuttais la...
c'est juste que si tu veux pas sortir l'artillerie lourde, et que tu dois choisir entre un fread par champ + swap, ou un gros fread de ta structure (meme si elle est tellement gargntuesque qu'elle trashe le cache entier), voire un fread par structure si tu dois lire un tableau de structures, la derniere option est, a mon avis, et en toute apparence, et ce independamment de si la libc inline quoi que ce soit, ou de si fread() bufferise quoi que ce soit, meilleure que la premiere...

c'est quoi le mieux?
un seul gros fread qui s'etend sur plusieurs cache lines et qui induit un load de cache lines pour chacune d'elles, puis 16 ou 32 swaps par cache line, avec, dans la majorite des cas, aucun cache miss vu que le fread aura deja produit les eventuels cache misses qui auront loade les donnees dans le cache, et dans le pire des cas, un load de cache line + 16 ou 32 swaps par cache line.

ou bien, pour chaque cache line, un load de cache line + 32 ou 16 paires de freads + swaps?

je dirais le premier hein...

Sally
:

sBibi :
(au fait, juste comme ca, Jackosking, c'est Endian, pas Indian ^^)

mais sinon tu peux dire ça en termes de MSB first ou LSB first, histoire qu'on comprenne de quoi il s'agit (pq en fait entre little endian et big endian je ne me souviens jamais lequel est lequel (si tant est que je l'aie jamais su). Bon certes en pratique on s'en fout de savoir lequel est lequel, ce qui est important c'est de savoir si c'est le même ou si c'est l'autre, mais quand même )

de mémoire, MSB first == big endian ^^

ouais mais voilà, c'est pas intuitif, dans "endian" y a "end" donc big endian tu crois que ça veut dire que le gros (donc le MSB) est à la fin (donc en dernier), et en fait c'est le contraire... ils auraient pu appeler ça big startian ça serait plus clair

je sais juste que le x86 est little endian et le 68000 ainsi que le pcc big endian

moi je sais juste que le 68k est dans le bon sens pour le Z-code et que donc il n'y a pas de conversion à faire dans foblub

"end" ça veut aussi dire "bout" (mais c'est pas très informatif )

(si, ça veut dire que sur une architecture 64 bits ils ne mettent jamais l'octet de poids fort en plein milieu )

(sauf justement quand on parle de "middle-endian" d'ailleurs ça s'applique aussi aux architectures 32 bit, hein ^^)

euh ah tiens oui dans 32 bits y a 4 octets, c'est vrai ça

et puis je pense pas que bcp d'architectures 64 bits soient middle-endian, ils ont dû comprendre que c'était un peu suicidaire ^^

ben c'est ce que je pense aussi, d'où le

ouais mais voilà, c'est pas intuitif, dans "endian" y a "end" donc big endian tu crois que ça veut dire que le gros (donc le MSB) est à la fin (donc en dernier), et en fait c'est le contraire...

En fait c'est pas construit comme ça. C'est "big-end" pour dire que le gros morceau passe en premier, auquel a été collé "ian" pour en faire un adjectif.
Et ce qui est marrant, ce que une fois le terme construit comme ça a été accepté, un nom commun en a été redérivé pour donner "endianness"

Euh sinon pour les structures, on m'a toujours dit que c'était mal d'écrire des structures dans un fichier sans les sérialiser. Déjà rien qu'avec un compilateur différent, les champs ne seront pas forcément aux mêmes offset dans la structure il me semble ?

http://www.catb.org/~esr/jargon/html/N/NUXI-problem.html

Euh sinon pour les structures, on m'a toujours dit que c'était mal d'écrire des structures dans un fichier sans les sérialiser.

j'ai un doute sur la signification du terme "serialiser" la... tu veux dire sans ecrire les champs 1 a 1?
avec des settings de compilateurs != pour l'alignement des champs, a priori oui, ca sera pas au meme endroit, il les paddera pas pareil (par contre il me semble que les normes C/C++ interdisent de reorganiser les champs des structures (mais j'en suis pas sur du tout)), mais tu peux forcer temporairement le packing du compilateur pour ecrire une structure en bloc dans un fichier:

#include "pack1.h"

typedef struct
{
 [...]
} t_pwet;

#include "packp.h"

avec:

pack'n'.h ('n' == 1 || 2 || 4 || 8, etc...)

#if defined(__GNUC__)
#  pragma pack(push, 'n')
#else
#  if (_MSC_VER >= 800 && !defined(_M_I86)) || defined(_PUSHPOP_SUPPORTED)
#    pragma warning(disable:4103)
#    if !(defined(MIDL_PASS)) || defined(__midl)
#      pragma pack(push, 'n')
#    else
#      pragma pack('n')
#    endif
#  else
#    pragma pack('n')
#  endif
#endif

et packp.h:

#if defined(__GNUC__)
#  pragma pack(pop)
#else
#  if (_MSC_VER >= 800 && !defined(_M_I86)) || defined(_PUSHPOP_SUPPORTED)
#    pragma warning(disable:4103)
#    if !(defined(MIDL_PASS)) || defined(__midl)
#      pragma pack(pop)
#    else
#      pragma pack()
#    endif
#  else
#    pragma pack()
#  endif
#endif

mais c'est quand meme fortement deconseille d'utiliser des structures packees octet par octet au runtime oui...
si t'as que des chars dedans, tu t'en fous, mais certaines instructions ne peuvent pas lire des types 32 bits qui ne sont pas alignes sur 32 bits, ou des types 64 bits pas alignes sur 64 bits, etc... (certaines plantent (notemment certaines instructions SIMD), d'autres sont seulement plus lentes (il me semble, pas teste...), et toutes risquent d'etre ralenties de facon significative si elles doivent lire un bloc de donnees qui chevauche deux cache lines).
bref, dans la plupart des cas, a moins d'ecrire a la main de l'asm qui contient des instructions SIMD sensibles, vu que le compilateur les generera pas lui meme si il sait que la structure n'est pas alignee (enfin en tout cas VC le fait pas, et GCC non plus, peut etre qu'il y a des compilateurs autistes qui font pas gaffe ceci dit...), y a pas de risques de plantages, juste de ralentissements de ton code...

mais en tout cas, lorsque tu ecris ou lis une structure en un bloc d'un fichier, il faut qu'elle soit correctement packee, sinon ca fera de la merde...

j'ai un doute sur la signification du terme "serialiser" la... tu veux dire sans ecrire les champs 1 a 1?

Oui [edit: euh je viens de relire la phrase et je suis plus sûr de ce que j'ai lu. Je veux dire écrire récursivement les données l'une après l'autre]

avec des settings de compilateurs != pour l'alignement des champs, a priori oui, ca sera pas au meme endroit, il les paddera pas pareil

Et d'un compilateur à un autre ça sera pire, les réglages n'ayant pas la même influence. Sans compter que même sans problème de bytesex ta structure sera pas paddée pareil sur une autre architecture.

(par contre il me semble que les normes C/C++ interdisent de reorganiser les champs des structures (mais j'en suis pas sur du tout))

En effet.

mais tu peux forcer temporairement le packing du compilateur pour ecrire une structure en bloc dans un fichier

Pas standard, ça dépend de fonctionnalités spécifiques au compilateur. Donc tu auras tout de même le problème en recompilant avec un autre compilo. Sans compter les autres inconvénients d'une telle méthode, que tu as déjà cités donc je vais pas le refaire.