Le tout et rien, mais surtout n'importe quoi ! - Page 216

En même temps, confondre spartiates et gladiateurs...

Cette musique c'est comme celle de Benny Hill, ça donne un truc marrant quelles que soient les images que tu mets dessus

Nil: je vais regarder si quelqu'un n'a pas fait le même genre de montage avec des images du film "Gladiator" et je poste si je trouve

Là, ça irait mieux

http://www.canalplus.fr/c-series/pid3420-c-du-hard-ou-du-cochon.html

apparemment ça à plus d'un an, mais certains comme moi l'ont peut être pas encore vu.
"Heurts Supplémentaires" avec Darren Tulett /Estelle Desanges est juste excellent

Mais ça aurait plus sa place dans le topic Portal.

J'ai trouvé un lointain précurseur de Terriblement efficace : [flash=280,18]http://www.bide-et-musique.com/dewplayer.swf?son=http://www.bide-et-musique.com/stream_7099.php[/flash]

je suis en train de me remettre au C pour faire un outil de traitement de fichier dump redis,

sur tout ce que j'ai codé auparavant, j'utilisais du u32 ou u16, u8 etc, avec un define : #define u32 unsigned int

la gp32 à un proc 32b, mes anciens pc/windows aussi, bref jamais de soucis çà allait jusqu’à 4 milliard et des poussières, sur 4o

la je commence à trifouiller mes pointeurs tout ca, et en plein dans ma mémoire, je veut y caller une valeur u32 via 4 octets
je matte l'offset depuis le début de ma zone mémoire, fait un modulo de 4, avance mon pointeur pour être aligné, et la une question me turlupine, je suis en 64b !

bref, combien fait mon int ??
un sizeof me retourne 4, wtf ? pourquoi c'est pas 8 ?!

si cela avais été 8, aurais je du aligner sur 8o ?

je cherche un peu, matte wikipedia et la je vois que le unsigned int >= 16b, monde de merde, aurais je du utiliser des unsigned long depuis tant d'années ?

le int n'est pas le "mot" basique du proc, celui qui va vite ?

que doit je déclarer pour être certain d'avoir 4o et 2o sur toute les plateformes ??

erf ok, je comprend mieux ces type moche avec des _

donc uint32_t visiblement mais c'est quoi ce délire avec des type pointeur ???

uint32_t * toto ça marche pas ?!! je doit faire uintptr_t toto ?

remplacer simplement mon define par #define u32 uint32_t ne suffira pas ?

r043v (./6463) :
c'est quoi ce délire avec des type pointeur ???

C'est seulement si tu veux pouvoir traiter un pointeur comme en entier, autrement dit en temps normal ça sert à rien.

ok, merci bien :- )

au final les types de bases servent plus à rien alors ?

char pour moi c'est 8b il va faire quoi de plus le int8_t ?
le short aussi est garanti à 16b non ?

tu entend quoi par traiter un pointeur comme un entier ?
c'est le cas ici ou je calcule un nombre d'octet entre deux pointeur char* ?

u32 diff = (keybuf-header);

r043v (./6465) :
char pour moi c'est 8b il va faire quoi de plus le int8_t ? le short aussi est garanti à 16b non ?

Non et non. Relis le K&R.

r043v (./6466) :
tu entend quoi par traiter un pointeur comme un entier ?

Un type d'entier qui est suffisamment grand pour qu'un cast pointeur->entier->pointeur soit valide dans tous les cas (sans perte de données).

r043v (./6466) :
c'est le cas ici ou je calcule un nombre d'octet entre deux pointeur char* ?

tu fais quoi concrètement ?

merde K&R pour moi c'était simplement une manière de mettre des accolades (manière ne me convenant pas donc je ne l'ai jamais lu)

et voila vous allez encore me traiter d’hérétique

la concrètement je fait un utilitaire pouvant trifouiller les dump redis,
redis sauve l'intégralité des clef dans un fichier unique, donc on à tout ou rien :/
mon but est d'avoir de quoi refaire des fichier dump via des requêtes perso, et également dégager certaines clef des dump style dans mon cas le caches des pages de mes sites

dans un premier temps je bosse avec un format de fichier perso, dumpant moi même la base mais plus tard se sera depuis les vrai dump de redis, mais aucune doc n'existe faut reverser..

bref pour répondre vraiment à ta question, étant old school et hérétique je bosse à l'ancienne, juste de la mémoire et des pointeur
u32 nbkey = keys->elements; if(!nbkey){ printf("not any result."); return 1; } printf("%u keys found.",nbkey); char * header = (char*)malloc(nbkey*2056); // 2ko max for key name memset(header,0,nbkey*2056); u32 * p = (u32*)header; *p++ = 0x42424242; // magic *p++ = nbkey; // nbkeys u32 *koffset = p; p += nbkey; u16 *knamesz = (u16*)p; // keys name size u16 *ktype = &(knamesz[nbkey]); // keys type char *knames = (char*)&(ktype[nbkey]); char *keybuf = knames; for(u32 n=0;n<nbkey;n++) { koffset[n] = 0; // clear offset for now knamesz[n] = (u16)(keys->element[n]->len + 1); // write key name length (add the \0) strcpy(keybuf,keys->element[n]->str); // copie name, fill with 0 redisAppendCommand(c,"TYPE %s",keys->element[n]->str); // pipeline get key type //printf("\nkey %u : %s",n,keybuf); keybuf += knamesz[n]; } u32 diff = (keybuf-header); if(diff%4) diff += 4-(diff%4); koffset[0] = diff;

donc concrètement, ici je compte le nombre d'octet entre le début de mon fichier (en mémoire) et la fin de l'header, pour écrire tout ca dans une zone mémoire destiné a recueillir les offset depuis le début du fichier ou se trouve les données de chaque clefs de la base

en gros juste une soustraction de char*

r043v (./6468) :
et voila vous allez encore me traiter d'hérétique

D'hérétique non, de bricoleux très certainement, par contre

Je vois pas ce que tu bricoles avec ton code d'alignement... :

- si tu te fous que ce soit portable, l'alignement n'a aucune importance (sauf pour les perfs) vu qu'en x86 tu peux lire un entier à n'importe quelle adresse, même impaire (à de rares exceptions près, y'a quelques instructions SSE qui demandent un alignement)

- si ça doit être portable, tu ne connais pas les contraintes d'alignement et d'endianness de la machine hôte, donc t'es obligé de lire les entiers de plus de 8 bits qui proviennent d'une source extérieure manuellement, en lisant octet par octet.

histoire d'enculer 2/3 mouches:

(à de rares exceptions près, y'a quelques instructions SSE qui demandent un alignement)

plutot, _toutes_ les instructions SSE qui ont des memory-ops s'attendent a recevoir de la memoire alignee, SAUF les movups (unaligned load/store)

r043v (./6466) :
tu entend quoi par traiter un pointeur comme un entier ?
c'est le cas ici ou je calcule un nombre d'octet entre deux pointeur char* ?

u32 diff = (keybuf-header);

la tu ferais plutot, a priori: ptrdiff_t diff = keybuf - header;
(ptrdiff_t, c'est en gros un int dont le sizeof est == sizeof(void*) <-- cette simplification est probablement sujette a un autre enculage de mouche par quelqu'un d'autre )

[nosmile]bah j'ai surtout fait du C sur la gp, c'est un arm faut aligner, je ne savais pas pour le x86 c'est lui l’hérétique en fait mais c'est bon à savoir ^^

rien n'existe pour faire ce que je veut, donc le but est d'envoyer ça sur github et que ca servent au max de monde, donc la compatibilité est plus ou moins importante, plus ou moins car un serveur == recent enfin je pense ^^

ici la seule source extérieure, est -pour l'instant- redis lui même, du moins sont client C qui j'espère me donne un truc aligné, et de toute façon j'utilise ce qu'il me donne via du strcpy et du memcpy

'fin bon je vais aligner tout de même ca me plait pas ^^

le malloc me garantie t'il une allocation aligné ou suis obligé d'utiliser un prama pack ?

pfff j’étais très bien moi sur ma machine embarqué, ici faut faire gaffe à plein de truc en dehors de la logique même

> sizeof est == sizeof(void*)
après légère réflexion tout rabbat que je suis, tout dépend de si j'ai + 4go de ram en fait ?!

'tin pourquoi je me prend la tête au lieu de chanter moi ?

je ne savais pas pour le x86 c'est lui l’hérétique en fait

.. ouii
je suis completement pour les alignements stricts. les loads memoires non-alignes qui fonctionnent de facon transparente, c'est mal: ca te donne l'impression que ca marche bien, alors qu'il y a potentiellement plein de penalites de perfs derriere...

apres t'as les PowerPC qu'ont un modele un peu different des loads alignes x86: les load des vector units sont des loads alignes a 16 octets, mais l'instruction ignore les 4 bits de poids faible, donc 'snap' ton adresse automatiquement... (et tu implemente manuellement un load non-aligne avec deux loads alignes des deux blocs contigus de memoire, et une combinaison de rotates ou shifts, et un select ou un or.. la au moins tu te rends bien compte du cout supplementaire, et ca fait sauter aux yeux l'acces aux deux lignes de cache contigues lors d'un load qui overlap les bords des cachelines, donc les deux cache miss potentiels au lieu d'un seul).

le malloc me garantie t'il une allocation aligné ou suis obligé d'utiliser un prama pack ?

un pragma pack ne changera strictement rien.
le malloc n'a aucune information sur le type que tu veux allouer, donc sur l'alignement, donc sur les pragma packs, donc sur les attributes aligned des structs/types
il faut imperativement que tu alignes manuellement la memoire du malloc, ou que tu utilise aligned_malloc (defini il me semble dans un des headers SSE sur x86, je sais plus exactement lequel), ou que tu t'en recode un qui wrappe malloc()

après légère réflexion tout rabbat que je suis, tout dépend de si j'ai + 4go de ram en fait ?!

heu bah non rien a voir... c'est de la memoire virtuelle, peu importe quelle ram physique t'as. tu peux tres bien avoir un systeme avec des pointeurs 64 bits, mais seulement 2 ou 3 Go de ram physique. en plus le layout de la memoire virtuelle differe totalement de celle de la memoire physique, il y a plein de plages memoires en dur reservees par l'OS dans le layout de la memoire virtuelle... bref... tu pourrais aussi avoir 30 Go de ram mais des pointeurs 32 bits, ca a pas de rapport... (tu serais effectivement limite a 4 Go de memoire adressable par process, et encore, moins en pratique pour ton appli, en enlevant les dites plages memoires reservees)

btw, perso jle trouve un peu sale ton code d'alignement (pas que, mais bon )
u32 diff = (keybuf-header); if(diff%4) diff += 4-(diff%4); koffset[0] = diff;

pourquoi pas tout simplement:
u32 diff = (keybuf-header); koffset[0] = (diff + 3) & -4;

ou:
static const ptrdiff_t kAlignment = 4; ptrdiff_t diff = (keybuf-header); koffset[0] = (diff + (kAlignment - 1)) & -kAlignment;

(les static const ou les enums pour les constantes, c'est bien, c'est plus explicite que des constantes entieres immediates dans le code, et ca rend plus simple et safe les modifications ulterieures de constantes (t'as envie de changer ton alignement? tu change ta constante a un seul endroit plutot qu'aux 5/6 endroits dans ton code ou elle apparait, et tu risque pas d'en oublier une et d'avoir des bugs bizarres.. et au final ca reste une constante que le compilateur peut simplifier a outrance, et ca te donne le meme code optimal que si t'avais balance les valeurs precalculees a la main partout)

intéressant

u32 diff = (keybuf-header); koffset[0] = (diff + 3) & -4;

houla ca me dépasse la je verrais après avoir évacué mon litre.5 actuel en fait vraiment bas niveau je suis pas au top, surement pour ca que je me suis jamais vraiment mis à l'asm { d'allieurs depuis qq jour j'ai de nouvelle chiottes, Folco je te ferais une photo avec le bouquiin quant je l'aurais retrouvé"

le truc des const est pas bète, j’avoue ne jamais m'"en être servie ou en de rare occas pour éviter des cast

'tin faut vraiment que je me remete au C !!

en fait le truc c'est que je codait vraiment que sur gp et que mes gp sont toute mortes sauf celle que m'avais offert mon ex ! xD bref comme un con j'ai dis ce detail et depuis interdit #arf# mais la on à déménagé, nouvelle règles tout ça , coup de pression, je peu d nouveau m'en servir ! muhuhuhahahhaha je vais pouvoir [s]finir[/s ] refaire mon moteur de Mr driller aka mr, dill my hair ! avec des phase horizontales, en fait un mélange de falldown d'un coté avec un vrai jeux de plateforme, ca va poutrer mais je m'égare

sinon, ton paragraphe sur le powrer pc ma encore mis ujne claque qui me dit pauvre con fait de l'asm !

bref, en 3 mots, monde de merde, ca tombe bien, ma boite se nomme m2m, et c'est pas vraiment pour médiation multimédia :! xD

pour sauver l'honneur :

pfff désespérant

dans chez plus quel sujet je disais que weed + code ==,rulez, au contraire de l'alcool, je me crayonne sévère
depuis tout à l'heure j'ai juste fait

#define u32 uint32_t #define u16 uint16_t

en rajoutant # inslude sdtint.h !

et le truc pwa c'est que ca compile héhé

et si voius ête pas daccord je vous invite à coder def et à coder bourré !

lol...

et a propos de ca:

(diff+3) & -4

le & -4 fait un & 0xFFFFFFFC --> ca clear les deux derniers bits --> ca aligne l'adresse a l'adresse multiple de 4 la plus proche, mais ca sera l'adresse inferieure, vu que ca degage les derniers bits. et c'est pas ce que tu veux, utiliser l'adresse quelques octets en dessous de ce qui est retourne par malloc, c'est sans doute pas une bonne idee


le + 3 est la pour snapper a l'adresse alignee superieure. 3 comme (4 - 1), ou (alignement - 1), c'est plus clair dans la version avec la constante nommee justement

- si t'as une adresse deja alignee, les 2 derniers bits sont deja a 0, le +3 les passe a 1, le & -4 les re-clear -> adresse alignee identique a celle d'origine.
- si t'as une adresse pas alignee, soit avec 1, 2, ou 3 dans les 2 derniers bits, le +3 passera au dessus de l'adresse alignee suivante, le & -4 la realignera.

bref, un alignement d'adresse quoi

bearbecue (./6473) :
il faut imperativement que tu alignes manuellement la memoire du malloc

En fait pas toujours, le pointeur renvoyé par malloc() est toujours suffisamment aligné pour n'importe quel type de base. Bon après ça ne prend pas en compte les trucs que le compilateur ne peut pas deviner, genre les contraintes particulières du SSE.

dsl, c'est vrai... j'ai tendance a un peu trop raisonner automatiquement avec le code vectoriel
quoique pour le malloc de la CRT, c'est pas certain qu'il renvoie de la memoire alignee sur des bounds de 8 octets (--> ya les doubles qui sont un type de base et 8 octets), il me semble bien que ca se limite a 4 octets sur x86 (apres, pas verifie sur x64, c'est ptet aligne a 8..)