Discussion :

[Hoffa]

Bonsoir,

A part le Batch, je ne connais pas d'autres langages qui supportent le système de "labels". Pour ceux qui ne savent pas ce que c'est, voici un pseudo-code d'un logiciel qui affiche le message "Hello World!" à l'infini.

Code :

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

1
2
3
label("ma_boucle");
echo "Hello World!";
goto("ma_boucle");

J'éspère que vous avez compris du premier coup de quoi il s'agit. Enfin bref, pourquoi les langages les plus connus ne supportent pas ce système ? Est-il pratiquement impossible de le faire dans un langage comme le C ?

Enfin j'aimerais avoir votre avis.
Merci d'avance,

Hoffa.

[Garulfo]

Bonsoir,

A part le Batch, je ne connais pas d'autres langages qui supportent le système de "labels".
[...] Enfin bref, pourquoi les langages les plus connus ne supportent pas ce système ? Est-il pratiquement impossible de le faire dans un langage comme le C ? [...]
Hoffa.

le C ne peut pas faire de goto ? Si...
En fait quasiment tous les langages impératif ont un mécanisme dans ce genre. Pour les langages fonctionnels il y a les continuations qui mènent à la même chose.

Où as-tu vu que tu ne pouvais pas le faire en C?

Code c :

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

1
2
3
 
etiquette: printf("Hello World!\n") ;
goto etiquette;

Bien sûr, on te déconseille les goto parce qu'en général ils sont mal utilisés. Et vu ta question, je suppose que tu ne sais pas concevoir correctement des programme (manque d'expérience pas de qualité personnelle) et, par conséquent, tu devrais éviter de les utiliser -_- C'est une mine d'erreurs et d'horreurs !

En effet ce programme

Code c :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
int main ()
{
   int n = 0;
   etiquette: 
   printf("Hello world\n");
   if ( n < 10 )
   {
       n++;
       goto etiquette;
   }
   return 0;
}

montre que tu ne sais pas concevoir correctement tes programmes car tu n'as pas conceptualisé ta boucle sans une forme logique et abstraite. En gros, tu as voulu programmer sans réflechir avant d'agir.

Code c :

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

1
2
3
4
5
6
7
8
9
 
int main ()
{
    int i;
    for (i=0; i<10; i++)
        printf ("Hello world\n") ;
 
    return 0;
}

est la bonne façon de faire.

Évites aussi d'être aussi sûr de toi quand tu ne sais pas. Ça évites d'avoir l'air bêbette par la suite Parce que là, tu viens finalement de démontrer que tu ne connais pas d'autres langages

[Hoffa]

Garulfo: En fait non, je n'ai JAMAIS utilisé le système de labels, jamais. Si j'ai demandé cette question, c'était juste pour m'instruire. Je ne compte pas utiliser ce système, c'était juste que... je voulais savoir. Enfin après tout, ça ne fait jamais de mal d'apprendre une nouvelle chose. Si je n'ai pas su que quasiment tous les langages supportaient ceci, eh bien c'est parce que je ne suis pas encore assez expérimenté, ou bien parce que je ne me suis pas intéressé auparavant.

[gorgonite]

Bien sûr, on te déconseille les goto parce qu'en général ils sont mal utilisés.

disons que les saletés doivent ne pas être enseignées aux débutants... voire être interdites dans 90% des cas où l'on voit les gens s'en servir

mais à partir d'un certain niveau, ces saletés deviennent extrêmement utiles car elles permettent de faire énormement de choses sans vérification, et donc de gagner beaucoup en perf

exemple : sans les goto, aurait-on un moyen rapide de faire un interprète threaded code ?
il faut bien avouer que ça permet de gagner un facteur 2 sur le fonctionnement de la machine virtuelle, mais qu'il faut refléchir correctement dès la conception car ça devient très dur à déboguer

[Garulfo]

[...]
exemple : sans les goto, aurait-on un moyen rapide de faire un interprète threaded code ?
il faut bien avouer que ça permet de gagner un facteur 2 sur le fonctionnement de la machine virtuelle, mais qu'il faut refléchir correctement dès la conception car ça devient très dur à déboguer

J'espère que par « un moyen rapide » tu n'entends pas « développer vite fait ». Car, en général, les erreurs potientielles vont, statistiquement, augmenter le temps de développement. C'est pourquoi même si c'est plus long, même si on y perd en performance, il vaut mieux passer par de la programmation « propre ». Que celle-ci puisse être parfois faite avec un goto, c'est une chose et j'y adhère. Mais la plupart du temps, on peut très bien, sans réel perte passer par un autre mécanisme. Et c'est là le problème : les gens cèdent à la facilité.

Donc comme tu le dis « il faut réfléchir correctement dès la conception car ça devient très dur à déboguer, » c'est souvent là que le bât blesse ^_^

Sinon, je reviens dessus et j'insiste, les études montrent que les besoins de modification liées aux performances insuffisantes représentent moins de 3% des efforts alors que ceux liés au besoin insatisfait ou à une conception qui ne respecte pas la spécification sont de 40%. On s'entend bien donc que s'il faut viser quelque chose c'est la fiabilité et la propreté de conception plus que des bonnes performances.

[gorgonite]

On s'entend bien donc que s'il faut viser quelque chose c'est la fiabilité et la propreté de conception plus que des bonnes performances.

et c'est là que tous les concepteurs de langages un peu évolués se plantent, et obligent les domaines de niche à rester sur de l'asm ou des sous-ensembles c...

j'ai pris un exemple très précis, celui des machines virtuelles, et là le fait d'économiser en mémoire et en temps de calcul peut avoir des incidences énormes, car elles permettront ensuite à des programmeurs moins expérimentés de concevoir des programmes plus simples, sans barbarie inutile, car 80% des perfs seront gagnées au niveau inférieur

on peut se demander pourquoi kaffe se vend moins bien que la vm d'esmertec dans le domaine de Java pour systèmes mobiles... réponse : parce que Sun a laissé un boulot de stagiaire arriver en prod, et qu'une seule personne peut les mettre mal en moins de 6 mois : ce fut mon cas, je leur pris un facteur entre 2 et 5 alors que je ne suis pas un pro des optimisations bas niveau, et j'ai moins de bugs que celle d'origine ^^


donc au risque de me répéter : tous les débutants doivent apprendre des choses propres, privilégier l'algorithmie, la modularité et la lisibilité...
mais passer un certain cap, dans certains domaines, ils seront obligés de faire des choses plus sales, et là il aurait mieux valu qu'on leur ait expliqué ce qu'ils peuvent faire, et surtout comment ils doivent s'y prendre pour ne pas déboguer un projet durant un mois

[Garulfo]

[...]
donc au risque de me répéter : tous les débutants doivent apprendre des choses propres, privilégier l'algorithmie, la modularité et la lisibilité...

Ça oui... on est d'accord

mais passer un certain cap, dans certains domaines, ils seront obligés de faire des choses plus sales

Non pas forcément. Tu généralises trop à ce que tu vis je pense.
En exemple, plus de 50% des informaticiens au Canada, par exemple, travaille sur des systèmes d'information où les performances ne sont pas dans les priorités... En fait, la majorité des travaux des informaticiens portent sur des tâches où on peut relèguer les performances en seconde ligne. Donc, sur le terrain, peu sont obligés de faire des choses sales ! C'est souvent qu'ils ne savent pas construire une architecture digne de ce nom. C'est donc leurs lacunes en conception qui réapparaît. Très peu de domaine ont réellement besoin qu'on aille se mouiller les mains dans le cambouis des tweakages. Maintenant, il y a des domaines où tu as complètement raison. Mais la majeure partie de la production en informatique ne nécessite pas autre chose que de bien comprendre ce qu'est une conception et de savoir agir au niveau de l'architecture.

Et je suis aussi complètement en accord quand tu dis qu'il faut que les concepteurs de langages ouvrent leurs esprits pour offrir des concepts de hauts niveaux et travailler sur leurs optimisations en sous-couches. En fait, je suis tellement d'accord que c'est ma branche d'une certaine manière.

L'autre chose est qu'on vise à faire de l'informatique ce qu'il devrait être : un outil pour les non-informaticiens. Mais c'est un autre débat.

[Chatbour]

Salut à tous

exemple : sans les goto, aurait-on un moyen rapide de faire un interprète threaded code ?
il faut bien avouer que ça permet de gagner un facteur 2 sur le fonctionnement de la machine virtuelle, mais qu'il faut refléchir correctement dès la conception car ça devient très dur à déboguer

gorgonite, est-ce que tu peux expliquer d'avantage cette idée ? merci d'avance

[el_slapper]

enfin, dans le genre horrible, COBOL permet les GO TO, mais aussi les ALTER - qui changent la cible du GO TO. Absolument illisible et inmaintenable. Pouark.

[gorgonite]

gorgonite, est-ce que tu peux expliquer d'avantage cette idée ? merci d'avance

bien sûr... étant donné que c'est une partie de mon stage de master, ça devrait être possible


commençons par présenter le schéma classique d'interprétation de bytecode :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
bytecodes = enumération de taches (add, mul, ifeq, ..., end)
programme = tableau de bytecode
indice = 0

tant que (instr = programme[indice++]) != end
  selon la valeur de instr faire
    cas add : ...
    cas mul : ...
    cas par défaut : "erreur de bytecode"
  fin selon
fin tant que

on remarque qu'il y a 3 instructions de controle pour 1 instruction de bytecode (ratio 3:1)

1. test sur le bytecode courant au niveau du "while"
2. saut indirect grâce à une table des valeurs du "switch"
3. saut pour revenir en début de boucle

c'est le principe de fonctionnement de la j2ME (kaffe)



le threaded code permet de réduire le ratio à 1:1 au prix de l'allocation de l'adresse du début de la séquence de chaque bytecode

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
bytecodes = enumération de taches (add, mul, ifeq, ..., end)
table_addr = [addresse add, addresse mul, ...] 
// indexée selon l'enum bytecode

programme = tableau de bytecode
indice = 0

aller à l'étiquette : table_addr[programme[indice++]

etiquette add:
  ...
  aller à l'étiquette : table_addr[programme[indice++]
etiquette mul:
  ...
  aller à l'étiquette : table_addr[programme[indice++]
etiquette end:
  sortir de la fonction d'interpretation

on voit qu'on a juste un "goto" à la fin de chaque exécution de bytecode




maintenant si l'on considère que les bytecode sont "bas niveau", donc ne font pas grand chose individuellement, on voit que le cout des traitements de controle peut être significatif par rapport au cout du bytecode
=> donc le threaded code peut rapporter beaucoup sur de tels langages (la jvm est un bon exemple)


le hic : avec l'augmentation des longueurs de pipelines et les prédictions de branchements hasardeux sur certaines architectures, on peut se retrouver avec un threaded code plus lent qu'un interprète classique (c'est le cas sur une architecture Prescott alors qu'une architecture amd64 s'en sort grâce une mémorisation asticieuse des branchements antérieurs)


pour aller plus loin : la ratio 1:1 peut être réduit à 1:N si l'on considère la notion de basic bloc d'instructions successives sans branchement... on va alors générer des buffer code exécutable, mais il faudra faire attention à la gestion mémoire, au cout de la génération, à la réutilisation éventuelle, etc
par ailleurs, si tu ajoutes des optimisations à la volée dans les basic bloc générés, tu te retrouves avec une compilation JIT (Just-In-Time) comme sur la j2se (jvm pour machine de bureau) ou une DAC (Dynamic and Adaptative Compilation) comme avec la jvm embarquée d'esmertec