2670

[offtopic]
Kochise>
ah ben encore heureux que le cache fasse son effet.. t'as une idee du cout en cycles d'un cache-miss, meme sur le L1? grin
le probleme c'est que c'est quand meme un acces memoire, et meme si c'est deja en L1, tu te farcis un stall systematique, meme si tu loade 20 fois la meme adresse
et je suis pas sur de savoir de quoi tu parle en disant ecriture en copy-back ? tu parle d'un load-hit-store, ou de si le cache se fait invalider par un autre core qui ecrit a la meme adresse / a une adresse qui se fait mapper dans la meme banque du cache?
(enfin dans le premier cas, yen a pas, et dans le second, faudrait quand meme le faire expres pour que ca arrive en synchro avec les iterations de la boucle grin (et l'impact serait autrement plus important))

et heu, ouai, les offsets 10h,20h,30h, c'est parceque c'est un float4 qui est loade, donc 16 octets a la fois, ca c'est rien de particulier, c'est dans le code d'origine de toutes facons, et oui la memoire est alignee, sinon ca serait des movups au lieu de movaps (meme si en pratique la difference de perfs entre les deux est assez negligeable sur les CPU recents)

bref la le gros probleme c'est que l'acces memoire produit un stall du pipeline d'execution a chaque instruction, cache ou pas cache.
(btw, vu que tu parle de cache, dans le cas concret de cette boucle, ca sert a rien de prefectch manuellement, vu que le pattern d'acces a la memoire est tres previsible (totalement lineaire, avec les memes offsets a chaque fois, et une cache-line par boucle), l'auto-prefetch du cpu fonctionne mieux que les prefetch manuels)
[/offtopic]
avatar
HURRRR !

2671

(contextee
)<@Zeph> mdr le casque audio lumineux
<@Zeph> j'aimerais bien avoir les gants luminothérapiques aussi, je sens que mes mains 
        manquent de lumière, elles sont tristes et du coup moi aussi
<@Zeph> mais au moins, ça a un avantage énorme ce casque
<@Zeph> ça highlighte les cons
<@Zeph> c'est une premièr
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

2672

trisotfl
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

2673

2674

excellent grin

2675

<Folco>     http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Pointer-Arith.html#Pointer-Arith
<Folco>      sizeof (void*) == 1
<Zerosquare> euh non, ça c'est pas normal
<Zerosquare> sizeof(void) = 1
<Zerosquare> mais sizeof(void *), ça ne devrait pas l'être
<Folco>      Ah, alors c'est moi qui déconne
<Folco>      J'ai beau avoir la tête dans les étoiles, j'en ai raté une visiblement %)
C'est mignon mimi
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

2676

2677

Putain, de la poésie avec du C, c'est beau :'(
avatar

2678

Zerosquare (./2675) :
sizeof(void) = 1


C'est possible, mais pas obligatoire, ça peux être 4
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

2679

Est-ce que ça peut être 5 ?

2680

Pourquoi pas. De toute façon on s'en fout complètement. smile

2681

trop pas non.

c'est pratique que ça vaille 1, ça permet de copier des octets sans avoir a caster tous les void* en char*.

2682

Godzil (./2678) :
C'est possible, mais pas obligatoire, ça peux être 4
Je parlais pour GCC uniquement, cf le lien posté juste avant smile
squalyl (./2681) :
c'est pratique que ça vaille 1, ça permet de copier des octets sans avoir a caster tous les void* en char*.
Ouais mais ton code ne sera pas portable si tu fais ça.
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

2683

c'est ptet le but...
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

2684

heuuuuu, c'est standard ca, pouvoir faire une addition sur un void* ? trifus
parcequ'autant que je sache, normalement une addition de pointeur sur un void*, c'est pas valide, mais meme sizeof(void), c'est pas valide...
enfin c'est ptet une "feature" de gcc...
avatar
HURRRR !

2685

(ah ben j'etais pas alle voir le lien dans le quote, mais ouai ok, c'est tout sauf standard... super tritop surtout vu ce que ca apporte...)
avatar
HURRRR !

2686

sizeof(void) je l'ai jamais vu mais de l'arithmétique avec des void*, oui grin

je crois que c'est une extension GNU

d'ailleurs je crois qu'on peut demander à gcc un warning quand ça arrive et que VS doit faire le warning par défaut.

2687

nan nan, sous visual c'est une erreur, c'est juste pas valide (enfin, en C++, mais en C aussi a priori, vu que t'es cense pouvoir build du C en C++)

"error C2036: 'void *' : unknown size"
avatar
HURRRR !

2688

2689

C'est la taille d'un objet élémentaire pointé, donc c'est pas idiot non plus. C'est une extension, ça se désactive, donc ce n'est que proposé, et c'est parfois très commode.

2690

bah, j'imagine que tout depend comment tu utilises void*

pour moi, cette extension, c'est assez stupide dans le sens ou ca casse la securite que tu as de ne PAS pouvoir faire d'arithmetique de pointeurs avec du void* (deja que c'est un type dangereux, vu qu'il ne represente rien), ca devient source d'erreurs potentielles et de bugs sournois.
si tu as un pointeur qui est cense pointer vers une zone de donnees/octets brute, dans ce cas, t'utilise pas un void*, mais genre un unsigned char *, ou un unsigned __int8 *. un void *, ca pointe vers un endroit abstrait. ca peut tres bien etre un pointeur sur fonction, une classe, un tableau de donnees compressees, une liste de coordonnees dans l'espace en float3, une vtable, un offset dans un vertex buffer, un handle quelconque qui est en fait un index, bref. tout et rien a la fois.
si tu decide de manipuler du void*, l'implementation interne des trucs qui le manipulent devraient le caster _explicitement_ vers le vrai type, et pas se baser sur l'assomption que c'est en fait un char* deguise...
la tu dois de toutes facons quand meme faire un cast explicite pour lire/ecrire dedans, donc je vois franchement pas a quoi ca sert. ca rend le void un type batard entre l'ancien void et le char/unsigned char.

a mon humble avis -> poubelle.

mais ok, on peut le desactiver... (encore heureux tsss)
avatar
HURRRR !

2691

le vrai but de void* a été de pouvoir déclarer une fonction memcpy() sans avoir à faire des versions pour chaque type grin

le cast en void* est automatique, mais l'inverse ne devrait pas l'être.

2692

sauf que même ça, c'est devenu faux avec le C++ qui est bien plus rigoureux à ce niveau ; du coup pencil momotte
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

2693

bearbecue (./2690) :
si tu as un pointeur qui est cense pointer vers une zone de donnees/octets brute, dans ce cas, t'utilise pas un void*, mais genre un unsigned char *, ou un unsigned __int8 *. un void *, ca pointe vers un endroit abstrait

Je vois pas en quoi un pointeur vers des "données quelconques" devrait plus être un char* qu'un void*, au contraire, cf la suite
bearbecue (./2690) :
la tu dois de toutes facons quand meme faire un cast explicite pour lire/ecrire dedans, donc je vois franchement pas a quoi ca sert

Et c'est justement ça qui est bien : t'es obligé de dire ce que tu vas lire ou écrire via ton void*, tu risques donc pas de faire les erreurs que tu ferais avec un char*.
Un void* est un type incomplet, donc il est normal de le compléter à l'utilisation, et il doit être utilisé pour ce pour quoi il est fait : la désignation d'un lieu où se trove on ne sait pas quoi, contrairement aux autres pointeurs dont le type indique ce qu'il y a au bout.

Et encore une fois, un char* pointe vers un char, pas vers "je sais pas trop quoi", sinon char* ne veut plus rien dire.

Enfin c'est mon avis, je ne suis pas informaticien, on pourra toujours me dire "pour qui tu te prends t'y connait rien", et c'est vrai. Mais je n'arrive pas à comprendre ce qui vous fait coincer.

2694

Hého, c'est pas des meilleures quotes, vos trucs embarrassed
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

2695

voilà :
Folco (./2693) :
bearbecue (./2690) :
si tu as un pointeur qui est cense pointer vers une zone de donnees/octets brute, dans ce cas, t'utilise pas un void*, mais genre un unsigned char *, ou un unsigned __int8 *. un void *, ca pointe vers un endroit abstrait

Je vois pas en quoi un pointeur vers des "données quelconques" devrait plus être un char* qu'un void*, au contraire, cf la suite
bearbecue (./2690) :
la tu dois de toutes facons quand meme faire un cast explicite pour lire/ecrire dedans, donc je vois franchement pas a quoi ca sert

Et c'est justement ça qui est bien : t'es obligé de dire ce que tu vas lire ou écrire via ton void*, tu risques donc pas de faire les erreurs que tu ferais avec un char*.
Un void* est un type incomplet, donc il est normal de le compléter à l'utilisation, et il doit être utilisé pour ce pour quoi il est fait : la désignation d'un lieu où se trove on ne sait pas quoi, contrairement aux autres pointeurs dont le type indique ce qu'il y a au bout.

Et encore une fois, un char* pointe vers un char, pas vers "je sais pas trop quoi", sinon char* ne veut plus rien dire.

Enfin c'est mon avis, je ne suis pas informaticien, on pourra toujours me dire "pour qui tu te prends t'y connait rien", et c'est vrai. Mais je n'arrive pas à comprendre ce qui vous fait coincer.

2696

(Mais enfin, chacun de mes post est une meilleure quote, merde quoi tripo)

!askfork 2677;2678;2679;2680;2681;2682;2683;2684;2685;2686;2687;2688;2689;2690;2691;2692;2693
Mici d'avance smile

2697

Heu Folco, je crois que vous êtes d'accord en fait. Quand tu ne sais pas vers quoi pointe ton pointeur, c'est normal d'utiliser void *, et tu ne peux ni y lire ni y écrire si tu ne complètes pas un peu son type. Ce qu'ajoute bearbecue, c'est que tu ne devrais pas non plus faire de l'arithmétique dessus. En effet, lors d'une addition, on est censé le faire par tailles de l'élément pointé entières, ce qui rend le sizeof(void) = 1 illogique et source de bogues. Il dit aussi que si en fait, tu connais la taille des éléments, tu n'as qu'à utiliser un type de la bonne taille à la place de void.

!askfork 2677;2678;2679;2680;2681;2682;2683;2684;2685;2686;2687;2688;2689;2690;2691;2692;2693;2696
avatar

2698

Tiens qu'avais-je dit que je ne comprends pas, hein, j'avais pas raison ? #triclasse#

2699

Na c'est la raison du plus fort qui est la meilleure, or tu as perdu toute ta force©, donc voilà embarrassed
!askfork 2677;2678;2679;2680;2681;2682;2683;2684;2685;2686;2687;2688;2689;2690;2691;2692;2693;2696;2697;2698

2700

Ce sujet a été coupé en 2 afin de séparer la discussion principale des posts ./2678 ./2679 ./2680 ./2681 ./2682 ./2683 ./2684 ./2685 ./2686 ./2687 ./2688 ./2689 ./2690 ./2691 ./2692 ./2693 ./2694 ./2697 . Pour vous rendre sur le nouveau sujet, merci de cliquer sur ce lien
avatar
Ben, bouh, quoi :D