[C] Des accolades "just pour le fun" ?

Recherche :

Mot : Pseudo : Filtrer
Page : 1 2 3 Page Suivante Page Précédente Bas de page
Auteur	Sujet : [C] Des accolades "just pour le fun" ?

Sve@r

Reprise du message précédent :

MagicBuzz a écrit :

Je dis donc

Code :

int i, c;
for (int i = 0; i < 10; i++)
{
prout(i, &c);
}
void prout(int i, int *c)
{
*c = i;
// on fait un truc avec *c
}

Est donc plus sale, mais plus optimisé que :

Code :

int i;
for (int i = 0; i < 10; i++)
{
prout(i);
}
void prout(int i)
{
int c;
c = i;
// on fait un truc avec c
}

Certainement franchement plus sale. Rien que pour ça, j'écris la seconde solution qui me parait plus sensée, à savoir "ma fonction déclare les variables qui lui sont utiles pour bosser - si ma fonction est appelée 10000 fois ben tant pis..."

MagicBuzz a écrit :

évidement qu'avec un int, ça n'a aucun intérêt.
quand prout() utilise un uint32[1600][1200] parcequ'il s'agit d'un buffer graphique, ça commence à devenir intéressant de ne pas avoirà gérer un malloc et un free à chaque utilisation de prout().

Dans l'absolu, si ma fonction a besoin de beaucoup de mémoire pour bosser, le raisonnement reste valable; à savoir "ben tant pis, il lui faut de la mémoire elle prend de la mémoire et tant pis si elle est appelée 100000 fois"

Ton idée a du bon... mais on peut pas l'appliquer car on va se prendre la tête. Telle fonction utilise 10M de mémoire est est appelée 100 fois donc on sort la variable qu'on passe en paramètre - Telle autre n'en utilise que 5M mais est appelée 200 fois donc on sort aussi la variable et on la passe aussi en paramètre. Une 3° aussi, et une 4° aussi etc etc. Finallement on se met à tout mettre en global et on n'a plus d'ennui de ce coté... mais on se met à en avoir par ailleurs !!!
Et puis il y a aussi le "static" qui existe qui te permet de ne pas faire du malloc/free à chaque appel (juste un malloc au premier et un free au dernier mais évidemment faut arriver à savoir qu'on est dans le dernier appel)

MagicBuzz a écrit :

Code :

int c;
prout(i, &c); // ou * chais jamais.
...
void prout(int i, int *c)
{
...
}

Pour savoir s'il faut mettre "*" ou "&" lors de l'appel, un truc mnémotechnique tout simple:

"c" est de type "int" or la fonction veut un "int *" donc ça ne va pas. Mais on peut s'imaginer "c" comme de type "& int *" (attention, ce n'est pas la réalité, c'est juste une construction imaginaire pour aider à comprendre tout comme au XVIII° siècle les nombres imaginaires ont aidé à trouver les solutions réelles à des équations du 3° degré) donc si je veux un type "int *" il faut que je mettre le "&" ailleurs car je ne peux pas le perdre donc je le mets devant "c" donc j'appelle ma fonction avec "&c" qui est bien de type "int *"...

Message édité par Sve@r le 10-01-2007 à 17:09:25

---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.

Publicité

0x90

→

MagicBuzz a écrit :

Le GC est un "tiers de confiance".
Le dev n'a pas à se préoccuper de ce qu'il fait ni de comment il fonctionne. A partir de là, il n'y a pas de "garantie".

C'est évidement une philosophie totalement différente du C où on peut aller jusqu'à contrôler quels registres vont être utilisés pour chaque instruction.

Dans l'exemple que j'ai cité, le GC peut tout à fait décider d'allouer 2 espaces mémoire pour deux instances de la fonction "prout()", puis alterner leur réutilisation.
Tout comme il peut aussi décider que ça va être plus coûteux de réutiliser cet espace que de le réallouer à chaque fois, avant de tout désallouer à la fin.

Je comprends que cela puisse être choquant quand on est habitué à tout maîtriser.
Cependant les résultats sont là : autant pour une toute petit appli (calcul du MD5 d'un fichier par exemple) en C on aura certainement des performances infiniment suppérieures au C#, même si c'est MagicBuzz qui a écrit le programme en C, autant dans d'autres cas, le C# sera bien plus rapide qu'un programme C écrit proprement (c'est à dire sans utiliser des optimisation de la mort, genre mise en global de variables internes à des fonctions).

On ne peut pas tirer de cas général, d'autant que le GC va s'adapter à la machine sur laquelle il tourne : sur un PC qui a 4 Go de mémoire libre, le GC va se contenter d'allouer tant qu'il peut de la place pour de nouvelles variables, puis tout désallouer d'un coup quand il aura fini, histoire d'être le plus rapide possible, autant pour un PC très limité en mémoire, le GC va faire de la réutilisation intensive, malgré le coût potentiel, afin d'économiser de la mémoire.
Ca fait partie notamment des fonctionnalités du JITC (just-in-time-compilation) de .NET 2.0 (recompilation systématique du programme lorsqu'il est lancé pour la première fois). En C, ça correspondrait à une compilation conditionnelle qui est effectuée automatiquement en fonction de la machine sur laquelle est lancé le programme.

Le GC apporte en fait un réel gain lorsqu'on travaille avec des objets volumineux dont une partie de l'état peut changer : il est capable de recycler la partie qui n'a pas changé, et n'a donc qu'à réinitiliser que la partie qui a changé.
En C ça peut rapidement devenir la prise de tête pour refaire ça "à la main".

1) un 'non' m'aurait suffit
2) ils sont ou exactement les résultats, tu peut me les montrer ?
3) tu raconte beaucoup de caca dans ton paté

---------------
Me: Django Localization, Yogo Puzzle, Chrome Grapher, C++ Signals, Brainf*ck.

Ace17

MagicBuzz a écrit :

nan, c'est surtout que si un gars qui fait du C voit écrit :

string c = "toto va à la plage";

il pige de suite ceque ça fait.

Mais quedale! C'est du C++ ca, point barre!
Et pour info les variables locales en C sont allouees sur la pile... c'est a dire, temps d'allocation nul.

Sve@r

MagicBuzz a écrit :

c'est quoi ta pile ? une centrale hydraulique ?

[:rofl]

MagicBuzz a écrit :

tu vas coller dans ta pile un array de 1 Mo toi ?

Ben tu peux le faire et même le compiler. Le problème tu l'auras à l'exécution lors de l'appel de ta fonction. Ton ordi gèlera et finalement, le programme s'arrêtera. Et si t'es sous Linux, t'auras un message style "sigseg" ou un truc analogue... Mais ton compilo ne dira absolument rien.

---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.

Sve@r

MagicBuzz a écrit :

...tu peux la flaguer en inline...

On est en C, pas en C++...

MagicBuzz a écrit :

Mais si c'est une fonction appelée un peu partout, t'as deux choix qui s'offrent à toi :
- Délocaliser tes variables internes dans la fonction appelante, et travailler avec des adresse, afin de ne pas les réallouer à chaque appel : dégueux et source de tout un tas de problèmes
- Te retrouver avec un programme non optimisé qui va passer son temps à allouer de l'espace mémoire pour rien

Ben oui mais rien n'est parfait. Tous les prog C savent très bien qu'une fonction qui utilise beaucoup de mémoire dans sa pile et qui est appelée un grand nombre de fois dans une boucle ben c'est tant pis... ou alors ils essayent d'inclure la boucle dans la fonction !

Message cité 1 fois

---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.

el muchacho

Comfortably Numb

Tamahome a écrit :

le gros problème avec les GC (enfin surtout celui de .net, pour java je ne connais pas assez pour dire) c'est la fragmentation mémoire...

C'est vrai pour les non-copying GC, c'est faux pour les copying GC, qui sont plus performants. C'est d'ailleurs un de leurs points forts, parce qu'ils passent leur temps à recopier les données en mémoire, avec toutes les références. Et durant ces recopies, ils font en gros en RAM ce que fait un défragmenteur sur un DD. Leur point faible est justement l'occupation mémoire engendrée par ces recopies, et les pools de mémoire préallouée pour optimiser l'occupation mémoire et l'accès cache. Java et c# ne sont pas connus pour être économes en RAM et la cause principale en est le GC. Grosso modo, un GC a besoin de 2x plus de mémoire pour travailler de façon optimale qu'une allocation manuelle optimale (càd sans memleaks).
L'article de Wikipedia est très complet, comme on peut s'y attendre.

Message cité 1 fois

Emmanuel Delahaye

C is a sharp tool

el muchacho a écrit :

L'article de Wikipedia est très complet, comme on peut s'y attendre.

Il faut donc s'attendre aussi à ce qu'un grognon nous sorte 'les wikis c'est de la merde!" comme d'habitude...

---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/

++fab

victime du syndrome IH

Sve@r a écrit :

On est en C, pas en C++...

Il existe aussi "un inline" en C99.

++fab

victime du syndrome IH

MagicBuzz a écrit :

[...]
Ca fait partie notamment des fonctionnalités du JITC (just-in-time-compilation) de .NET 2.0 (recompilation systématique du programme lorsqu'il est lancé pour la première fois). En C, ça correspondrait à une compilation conditionnelle qui est effectuée automatiquement en fonction de la machine sur laquelle est lancé le programme.

On peut faire ça aussi avec du C ou du C++. LLVM par exemple permet des optimisations au link, à l'install, à l'exécution.

Publicité

Page : 1 2 3

Page Suivante

Page Précédente

Haut de page

FORUM HardWare.fr

Programmation

[C] Des accolades "just pour le fun" ?

Sujets relatifs
just les bases....
Plus de sujets relatifs à : [C] Des accolades "just pour le fun" ?

Page générée en 0.075 secondes