Discussion :

[barbsbou]

Bonjour,

Je suis sur un projet de developpement en C avec un binome. Que ca soit lui comme moi on a un peu l'habitude developper en C. Notre projet contient plusieur niveaux :
c'est-a-dire 6 .o avec les .h associés. ce qui est fait que nous avons un certains nombres de fonctions.

Pendant les cours de C on a aidé pas mal nos petits camarades, et la on est en "competition" avec un autre binome que nous avons un peu aidé sur le meme projet. Au final avec mon binome apres avoir un peu optimisé notre source on a developez noter projet en essayant detre le plus rapide en sans regarder la complexité memoire...
Nos "concurrents" ont plutot obtés pour l'inverse : optimisé la complexité memoire sans essayer detre trop rapide...mais eu ils on tout developé dans un meme fichiers (tres tres consequent et limite illisible....).

Et au final leur algo a un bytes rate de 1.5Mo/s tandis que nous ca tourne autour de 1Mo/s.

Alors ma question est ce que la programmation fonctionnelle dans des fichiers separé peut etre en parti la cause de cet ecart....????

Merci a lavance.

[Franck.H]

Alors ma question est ce que la programmation fonctionnelle dans des fichiers separé peut etre en parti la cause de cet ecart....????

Aucunement, une fois le linker passé sur les fichiers objets, tout est dans un seul fichier exécutable.

[DaZumba]

Aucunement, une fois le linker passé sur les fichiers objets, tout est dans un seul fichier exécutable.

Si les furieux qui ont tout mis dans le meme fichier n'ont qu'une seule fonction (i.e. main()), alors ils economisent le cout des appels de fonctions. Mais c'est assez negligeable de nos jours.

Je ne sais pas ce que veux dire "optimiser la complexite memoire", mais s'ils ont optimise l'algorithme, alors il y a de bonnes chances qu'il soit plus rapide. Mais je ne mettrais pas une bonne note a quelqu'un qui met tout le programme dans un seule unite de compilation.

[Franck.H]

Si les furieux qui ont tout mis dans le meme fichier n'ont qu'une seule fonction (i.e. main()), alors ils economisent le cout des appels de fonctions. Mais c'est assez negligeable de nos jours.

Je ne sais pas ce que veux dire "optimiser la complexite memoire", mais s'ils ont optimise l'algorithme, alors il y a de bonnes chances qu'il soit plus rapide. Mais je ne mettrais pas une bonne note a quelqu'un qui met tout le programme dans un seule unite de compilation.

Oui ca va de soi, économiser je ne sais combien de fonctions ca permet d'éviter au processeur de créer autant de changement de contexte etc... mais je ne sais pas si un tel écart serait vraiment visible même en procédant aussi salement que ca.

Ils ont peut-être sans le vouloir amélioré l'algo du côté de la rapidité d'exécution

[barbsbou]

je vous remercie de votre reponse.

[droggo]

Gio,

S'ils ont suffisamment optimisé l'utilisation mémoire, ils optimisent en partie la vitesse, car ils auront moins d'erreurs de cache pour le processeur.

[DaZumba]

Oui ca va de soi, économiser je ne sais combien de fonctions ca permet d'éviter au processeur de créer autant de changement de contexte etc...

Ce n'est pas un changement de contexte au sens de context switch (lorsque le CPU passe d'un processus a un autre), mais plutot une copie des arguments sur la pile (s'il y a une pile, evidemment).

mais je ne sais pas si un tel écart serait vraiment visible même en procédant aussi salement que ca.

L'appel de fonction a un cout, sinon les fonctions inline seraient inutiles. Mais ce n'est pas de ce cote que j'irais voir d'abord, c'est sur.

[Mat.M]

Et au final leur algo a un bytes rate de 1.5Mo/s tandis que nous ca tourne autour de 1Mo/s.

Alors ma question est ce que la programmation fonctionnelle dans des fichiers separé peut etre en parti la cause de cet ecart....????

Sans code source on ne peut porter aucun jugement..
c'est très subjectif ce que tu écris là
Donne-nous un code source et après on pourra juger