Discussion :

[Chaka_Sobek]

Bonjour à tous,
Je me permets de vous poster mon problème (étant néophyte du langage C).
J'ai essayé de lancer un script déjà rédigé par quelqu'un concernant la compression - décompression LZW. Cependant, je n'arrive pas à l’exécuter, ici est le problème ! J'ai essayé de faire un gcc ./lzw.c c texte.html sans succès... Je vous mets ci-joint le lien du github du script : https://github.com/radekstepan/LZW
En espérant avoir des retours.
Merci par avance !!

Chaka_Sobek

[edgarjacobs]

Hello,

Tu dois d'abord créé l'exécutable en chargeant les sources sur ta machine, puis en exécutant gcc.

Ensuite, quand tu auras lzw.exe (ou .a), tu pourras faire lzw c input.html à l'invite de commande.

Mais, perso, je ne ferais pas confiance à un programmeur qui inclut des .c dans des .c

[chrtophe]

J'ai essayé de faire un gcc ./lzw.c c texte.html sans succès

Normal, ça n'a pas de sens.

Il te faut compiler via :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

gcc lwc.c

tu peux passer des paramètres supplémentaires pour avoir notamment un fichier avec un autre nom que a.out, le nom pr défaut.

Etant néophite, je précise que normalement, quand tu as plusieurs fichiers .c, il faut tous les compiler et donc les fournir à gcc.
ce n'sst pas le cas ici, car si tu regardes le fichier lwc.c, tu vois qu'il y a un #include d'au moins un des fichiers.

Mais, perso, je ne ferais pas confiance à un programmeur qui inclut des .c dans des .c

C'est vrai que ce n'est pas la façon de faire normale

[kaitlyn]

Salut,

Mais, perso, je ne ferais pas confiance à un programmeur qui inclut des .c dans des .c

C'est vrai que ce n'est pas la façon de faire normale

Ça s'appelle une amalgamation (fusion). Elle permet un gain de performance non négligeable. L'exemple le plus représentatif que je connais est Sqlite.

[Bousk]

https://en.wikipedia.org/wiki/Unity_build

Mais dans le cadre d'un projet aussi petit, c'est sûrement juste pour simplifier la compilation en compilant un unique fichier.

[Chaka_Sobek]

Merci à tous les 4 pour vos retours !
J'ai donc essayé ce qui était indiqué par chrtophe (et je t'en remercie!). Le script à l'air de bien se dérouler mais, si j'ai bien compris, ici il travaille dans le vide car je ne lui donne pas de fichier en entrée. J'ai donc ensuite essayé en faisant gcc lzw.c texte.html (comment ce qui était indiqué dans les codes, de ce que j'ai lu) et cela me renvoie "file format not recognized". J'ai donc essayé de faire gcc lzw.c c texte.html comme ce que le créateur avait écrit dans son README mais sans succès : error c aucun fichier ou dossier de ce type... comme si il prennait mon c pour un argument de type fichier alors qu'il est censé uniquement indiqué le mode compression ou décompression (c & d).
Je me tourne donc vers vous pour savoir comment je pourrais tester ce satané algo sur un exemple quelconque (et si le texte est forcément en .html ou bien .txt est valable).
Encore désolé pour ses questions de bas niveau.
Merci par avance à ceux qui prendront la peine de me répondre, étant un tout jeune débutant... :/
Bonne soirée.

Chaka_Sobek

[chrtophe]

Tu ne dois en aucun cas passer "texte.html" à gcc, uniquement les fichiers .c à compresser et dqns ce cas particulier uniquement lzw.c.

Ce qui t"induis en erreur, c'est qu'une fois le fichier source compilé avec gcc, derrière l’exécutable, tu dois utiliser le 1er paramètre "c" pour indiquer que tu souhaites compresser (ou d pour décompresser) puis en second paramètre le fichier à compresser ou décompresser, texte.html dans l'exemple.

Ça s'appelle une amalgamation (fusion). Elle permet un gain de performance non négligeable

Je ne comprend pas en quoi il y a un gain de performance (mais je ne suis pas développeur, donc quelque chose m'échappe probablement), car si j'inclus lzw.c dans un projet plus important, avec plusieurs fichiers sources et un makefile, il va recompiler la partie lzw à chaque fois. Par contre la technique a un intérêt pour facilement intégrer le code à un autre projet. C'est du moins ce que je déduis.

[dalfab]

Je ne comprend pas en quoi il y a un gain de performance (mais je ne suis pas développeur, donc quelque chose m'échappe probablement), car si j'inclus lzw.c dans un projet plus important, avec plusieurs fichiers sources et un makefile, il va recompiler la partie lzw à chaque fois. Par contre la technique a un intérêt pour facilement intégrer le code à un autre projet. C'est du moins ce que je déduis.

Avoir une seule unité de compilation permet une meilleure optimisation globale. Sur des unités différentes, il est difficile bien que possible de réoptimiser au moment de l'édition des liens.

[WhiteCrow]

[...]


Je ne comprend pas en quoi il y a un gain de performance (mais je ne suis pas développeur, donc quelque chose m'échappe probablement), car si j'inclus lzw.c dans un projet plus important, avec plusieurs fichiers sources et un makefile, il va recompiler la partie lzw à chaque fois. Par contre la technique a un intérêt pour facilement intégrer le code à un autre projet. C'est du moins ce que je déduis.

Dans le cas Sqlite, l'amalgamation est le fait de réunir dans un seul et unique source l'entièreté du projet. Cela permet d'inclure ce fichier dans son propre projet pour bénéficier de Sqlite.

Les alternatives seraient d'utiliser Sqlite via

• une bibliothèque dynamique. Les résolutions de noms se font alors au runtime, on utilise les fonctions de la bibliothèque dynamique avec les avantages (partage de code entre processus, bénéfices des màj, …) et les inconvénients (disponibilité au moment du runtime, bug introduits par une màj, problèmes dues à une version différentes de la version de dèv, …). Il est impossible à la chaîne de compilation d'optimiser quoi que ce soit ;
  
• une bibliothèque statique. Du point de vue de la chaîne de compilation on a la main sur les paramètres de compilation de la bibliothèque. Il lui est possible d'optimiser pour une cible particulière cette bibliothèque. Les avantages sont nombreux car on aura forcément la même version en dèv et en prod. On se retrouve au final avec une partie du projet optimisée à part de la bibliothèque avec peu d'optimisations sur les liens entre les deux parties, bien que les linker avec LTO (link time optimization) soient de plus en plus performants ;
  
• l'amalgamation. Ici il n'y a plus les deux parties et on peut partir en full optimisation si on veut. Au lieu d'une bibliothèque on aura un simple fichier objet à gérer, comme n'importe quel autre et la chaîne de compilation pourra bien mieux optimiser la sortie avec parfois le problème de l'augmentation de sa taille.

Là on va (normalement) de l'option la plus lente à la plus rapide.

[kaitlyn]

Attention @chrtophe, lzw est ici une application, pas une bibliothèque (lib).

En complément des messages qui précèdent, pour l'amalgamation, une de ses conséquences est qu'elle favorise ou dope l'IPO (interprocedural optimization), mais le mieux est peut-être de renvoyer vers ce que dit Sqlite à ce sujet. Personnellement je connaissais la technique sous ce nom, mais là je me demande justement s'il n'a pas été introduit par Sqlite dans ce contexte et que peut-être je le tiens de là, parce que dans le lien de @Bousk, jumbo build ça me parle, unity build, trop généraliste pour moi, beaucoup moins. Je fouillerai dans ma mémoire à l'occasion, sauf si quelqu'un à une réponse à ça.

Bref, je cite juste le passage sur la performance qui donne une indication sur ce qu'on peut en attendre

And because all code is in a single translation unit, compilers can do better inter-procedure optimization resulting in machine code that is between 5% and 10% faster.

Ce qui est vraiment important, la réelle valeur ajoutée de cette affirmation, c'est que Sqlite est testé sur la plus gande diversité de machines et surtout compiler avec les outils les plus divers qui soient.


@Chaka_Sobek

Il te faut construire l'application lzw avant de pouvoir l'utiliser, c'est à ça que sert gcc. En partant du principe que tu travailles sur Windows, la ligne de commande la plus simple pour le faire serait gcc -o lzw.exe lzw.c Une fois l'opération terminée, il convient de tester l'application nouvellement générée, en essayant juste d'afficher son aide en ligne, donc ici en tapant seulement son nom lzw Si tout est OK alors elle pourra être utilisée pour compresser et décompresser des fichiers, respectivement avec les commandes lzw c fichier.txt et lzw d fichier.txt.lzw (fichier.txt pouvant être n'importe quoi d'autre).

[Chaka_Sobek]

Bonjour tout le monde,
Et merci pour vos retours !!!

Pour répondre à l'aide de kaitlyn, j'ai essayé gcc -o lzw.exe lzw.c puis lzw cependant mon terminal me retourne que la commande n'a pas été trouvée (j'ai essayé de même avec lzw.exe sans succès non plus...). Je tiens à préciser que je travaille sur Ubuntu depuis peu... Saurais-tu m'indiquer comment résoudre ce problème ?

Merci par avance pour vos retours.
Bonne journée.

Chaka_Sobek

[xdelatour]

Bonjour,

Pour répondre à l'aide de kaitlyn, j'ai essayé c]gcc -o lzw.exe lzw.c[/c] puis [c]lzw[/c cependant mon terminal me retourne que la commande n'a pas été trouvée (j'ai essayé de même avec lzw.exe sans succès non plus...). Je tiens à préciser que je travaille sur Ubuntu depuis peu... Saurais-tu m'indiquer comment résoudre ce problème ?

Si l'exécutable généré s'appelle lzw.exe, il faut le lancer avec ./lzw.exe, c'est normal que lzw ne soit pas trouvé, le nom complet doit être précisé, il n'est pas possible sous Linux d'omettre l'extension du fichier exécutable, et il faut également préciser qu'il se trouve dans le chemin courant, d'où le './' devant son nom.

[Chaka_Sobek]

Bonjour,



Si l'exécutable généré s'appelle lzw.exe, il faut le lancer avec ./lzw.exe, c'est normal que lzw ne soit pas trouvé, le nom complet doit être précisé, il n'est pas possible sous Linux d'omettre l'extension du fichier exécutable, et il faut également préciser qu'il se trouve dans le chemin courant, d'où le './' devant son nom.

Merci beaucoup !! Je viens d'essayer en ouvrant directement un terminal dans le dossier contenant tous les .c !!

Bonne journée à tous

[kaitlyn]

Sous Linux on compile généralement les utilitaires sans extension, pour lzw, à titre d'illustration, ça aurait été gcc -o lzw lzw.c

[Sve@r]

Bonjour

j'ai essayé

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

gcc -o lzw.exe lzw.c

... Je tiens à préciser que je travaille sur Ubuntu depuis peu...

Les conventions pour un exécutable sous Linux sont pas d'extension (pas de ".exe"). Donc gcc -o lzw lzw.c et le programme se nommera "lzw".

cependant mon terminal me retourne que la commande n'a pas été trouvée

Pour qu'une commande (un programme) soit trouvée, il faut donner à Linux sa position (le dossier qui le contient). D'où le post de xdelatour quand il te demande de préciser "./" devant son nom, "." étant un raccourci signifiant "le dossier dans lequel je me trouve" ce qui est donc bel et bien un dossier. Car même si le programme se trouve au même endroit que toi, Linux ne le cherchera pas si tu ne le lui dis pas de façon explicite (question de sécurité).