<<
Pourquoi Ironpython est plus lent en C qu'en C# ? Mal optimisé ?
>>
Une partie du gain vient du fait que le CLR peut detecter des organisations de code qu'il peut optimiser a la volee au moment de l'execution, ce que ne peut pas du tout faire le C.
Guido Van Rossum et tous les gens qui bossent sur python dpeuis 10 ans ne sont pas des machots donc je doute que le code C de python soit "mal optimise".
<<
Le C peut aussi bien faire de gros programmes, faut créer les bibliothèques et bien modulariser et bien savoir coder aussi
>>
Donc en fait, ta defense du C est une attaque des programmeurs. "Vous ne savez pas coder, sinon, ca marcherait mieux". C'est plutot minable comme argumentaire.
Sur des tres gros programmes en C, tu es souvent conduit a utiliser par exemple des pointeurs en (void *) car tu dois stocker plusieurs types de donnees dans un pointeur. L'absence de notion de dictionnaire, d'heritage, les notions de tableaux tres limitees, l'absence de notion d'interface font que beaucoup de paradigmes indispensables de programmation sont fait completement a l'insu du compilateur, qui du coup a un champ tres limite pour comprendre les intentions du programmeur et optimiser le code en fonction.
L'utilisation d'un (void *) est le plus flagrant mais tous les parametres jouent ensemble. Un dictionnaire a 3 elements est plus facile a optimiser avec une recherche lineaire, un dictionnaire avec 500 elements est plus facile a optimser avec une table de hashage. C'est une decision que le compilateur pourait prendre plutot que le programmeur.
L'absence de ramasse-miette fait aussi que les programmes en C demandent plus de travail au programmeur. Le ramassage des miettes (== desalllocation des ressources inutilisees) est aussi quelque chose que le compilateur peut faire mieux que le programmeur si on lui passe les bonnes information.
<<
La grammaire du C est complexe ? :o Pourquoi ?
>>
Au hasard et en survol :
- pas de distinction entre un tableau et un pointeur
- un melange entre la declaration de type et le nom de la variable :
<type de la variable> <nom de la variable> <info supplementaire facultative sur le type de la varible>
int a[30];
- le pre-processeur qui peut rendre la grammaire du texte decrivant le code completement irreguliere.
- l'absence de taille predefinies pour les types de bases.
<<
Des manipulations qui cachent ce que veut faire le developpeur ? C'est quoi ?
>>
Pour les plus simples :
- passage d'arguments par void *
- passage de tableaux par pointeur, on perd toute l'information sur la notion de tableau (de toute facon, le C n'est stocke aucune, mais c'est bien la une de ses limitations)
- bidouilles a coup de struct et de pointeurs de fonctions pour faire des interfaces
- pas de liste, pas de dictionnaire donc plein d'optimisations a la portee du compilateur qui sont perdues
<<
Et les outils ne font pas obligatoirement faire de meilleur code ;).
>>
T'as vraiment des arguments a 3 francs. T'as deja reflechi au sujet avant d'ecrire un truc pareil ?
Bien sur que la qualite des outils permettent d'ecrire du code de meilleur qualite et de le faire evoluer de meilleure facon.
Un outil de refactoring en java te permet de faire facilement evoluer ton code par exemple. La meme operation en C oblige a faire un gros grep dans les sources et a faire de modifs a la main, super penible donc rarement fait dans la pratique, donc code qui devient vite immaintenable.
Des que tu fais du C++, tu t'apercois que gdb n'as acces qu'a une partie limitee des objets, et que donc le debuggage est super penible, tu en reviens au printf, ce qui est long et penible.
Des outils comme la programmation oriente aspect permettent d'explorer des nouveaux concepts de programmation, plus en rapport avec les besoins de certains projets.
En java, il est possible de debugger a distance un programme java qui s'execute. Par exemple, je peux debugger une javacard depuis mon PC, poser des points d'arrets, inspecter les variables, etc. C'est difficile et lourd a faire avec du code embarque en C, tu es souvent oblige de developper un simulateur complet de ta plate-forme cible.
Des outils d'analyses de code peuvent te permettre de mieux comprendre un code existant. Ces outils sont limites dans leur comprehension du code C a cause des limitations de la grammaire du C (je commence a me repeter la).
<<
Les outils n'ont rien à voir avec la simplicité du langage...
>>
Je n'ai pas parle de simplicite mais d'expressivite. Si ton langage transcrit bien ce que tu veux faire, les outils peuvent t'aider beaucoup. Si ce n'est pas le cas, les outils ne peuvent rien pour toi.
Le cas d'erlang est frappant. Je ne connais pas le langage, mais je suis persuade que si tu informes le compilateur des morceaux de code qui doivent s'executer en parallele ou non, tu obtiens un truc bien plus propre que avec des mutex dans tous les sens, des sections critiques et des forks a tout va. Dans un cas, le compilateur peut t'aider et distributer pour toi l'execution du code sur plusieurs threads/processeurs/machines, dans l'autre, c'est toi pauvre programmeur, qui va essayer de le faire. Tu vas passer ton temps a re-inventer la roue.
[^] # Re: ...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 10.
Pourquoi Ironpython est plus lent en C qu'en C# ? Mal optimisé ?
>>
Une partie du gain vient du fait que le CLR peut detecter des organisations de code qu'il peut optimiser a la volee au moment de l'execution, ce que ne peut pas du tout faire le C.
Guido Van Rossum et tous les gens qui bossent sur python dpeuis 10 ans ne sont pas des machots donc je doute que le code C de python soit "mal optimise".
<<
Le C peut aussi bien faire de gros programmes, faut créer les bibliothèques et bien modulariser et bien savoir coder aussi
>>
Donc en fait, ta defense du C est une attaque des programmeurs. "Vous ne savez pas coder, sinon, ca marcherait mieux". C'est plutot minable comme argumentaire.
Sur des tres gros programmes en C, tu es souvent conduit a utiliser par exemple des pointeurs en (void *) car tu dois stocker plusieurs types de donnees dans un pointeur. L'absence de notion de dictionnaire, d'heritage, les notions de tableaux tres limitees, l'absence de notion d'interface font que beaucoup de paradigmes indispensables de programmation sont fait completement a l'insu du compilateur, qui du coup a un champ tres limite pour comprendre les intentions du programmeur et optimiser le code en fonction.
L'utilisation d'un (void *) est le plus flagrant mais tous les parametres jouent ensemble. Un dictionnaire a 3 elements est plus facile a optimiser avec une recherche lineaire, un dictionnaire avec 500 elements est plus facile a optimser avec une table de hashage. C'est une decision que le compilateur pourait prendre plutot que le programmeur.
L'absence de ramasse-miette fait aussi que les programmes en C demandent plus de travail au programmeur. Le ramassage des miettes (== desalllocation des ressources inutilisees) est aussi quelque chose que le compilateur peut faire mieux que le programmeur si on lui passe les bonnes information.
<<
La grammaire du C est complexe ? :o Pourquoi ?
>>
Au hasard et en survol :
- pas de distinction entre un tableau et un pointeur
- un melange entre la declaration de type et le nom de la variable :
<type de la variable> <nom de la variable> <info supplementaire facultative sur le type de la varible>
int a[30];
- le pre-processeur qui peut rendre la grammaire du texte decrivant le code completement irreguliere.
- l'absence de taille predefinies pour les types de bases.
<<
Des manipulations qui cachent ce que veut faire le developpeur ? C'est quoi ?
>>
Pour les plus simples :
- passage d'arguments par void *
- passage de tableaux par pointeur, on perd toute l'information sur la notion de tableau (de toute facon, le C n'est stocke aucune, mais c'est bien la une de ses limitations)
- bidouilles a coup de struct et de pointeurs de fonctions pour faire des interfaces
- pas de liste, pas de dictionnaire donc plein d'optimisations a la portee du compilateur qui sont perdues
<<
Et les outils ne font pas obligatoirement faire de meilleur code ;).
>>
T'as vraiment des arguments a 3 francs. T'as deja reflechi au sujet avant d'ecrire un truc pareil ?
Bien sur que la qualite des outils permettent d'ecrire du code de meilleur qualite et de le faire evoluer de meilleure facon.
Un outil de refactoring en java te permet de faire facilement evoluer ton code par exemple. La meme operation en C oblige a faire un gros grep dans les sources et a faire de modifs a la main, super penible donc rarement fait dans la pratique, donc code qui devient vite immaintenable.
Des que tu fais du C++, tu t'apercois que gdb n'as acces qu'a une partie limitee des objets, et que donc le debuggage est super penible, tu en reviens au printf, ce qui est long et penible.
Des outils comme la programmation oriente aspect permettent d'explorer des nouveaux concepts de programmation, plus en rapport avec les besoins de certains projets.
En java, il est possible de debugger a distance un programme java qui s'execute. Par exemple, je peux debugger une javacard depuis mon PC, poser des points d'arrets, inspecter les variables, etc. C'est difficile et lourd a faire avec du code embarque en C, tu es souvent oblige de developper un simulateur complet de ta plate-forme cible.
Des outils d'analyses de code peuvent te permettre de mieux comprendre un code existant. Ces outils sont limites dans leur comprehension du code C a cause des limitations de la grammaire du C (je commence a me repeter la).
<<
Les outils n'ont rien à voir avec la simplicité du langage...
>>
Je n'ai pas parle de simplicite mais d'expressivite. Si ton langage transcrit bien ce que tu veux faire, les outils peuvent t'aider beaucoup. Si ce n'est pas le cas, les outils ne peuvent rien pour toi.
Le cas d'erlang est frappant. Je ne connais pas le langage, mais je suis persuade que si tu informes le compilateur des morceaux de code qui doivent s'executer en parallele ou non, tu obtiens un truc bien plus propre que avec des mutex dans tous les sens, des sections critiques et des forks a tout va. Dans un cas, le compilateur peut t'aider et distributer pour toi l'execution du code sur plusieurs threads/processeurs/machines, dans l'autre, c'est toi pauvre programmeur, qui va essayer de le faire. Tu vas passer ton temps a re-inventer la roue.