Les journaux sont destinés à des informations qui ne sont pas suffisamment intéressantes
pour être validées en dépêche (sinon n'hésitez pas à proposer votre information en
dépêche), qui sont sans rapport avec Linux ou le libre, ou simplement pour donner votre
avis. Si vous désirez poser une question, merci d'utiliser Derniers journaux de nicOnicO :
- [14/04@14:02] "Vous n’avez pas à vous débarrasser de votre ordinateur à chaque fois que Microsoft lance une nouvelle version de ses logiciels. "
- [12/04@16:28] VLC et son érgonomie
- [25/03@14:02] [HS] Emplois, salaire et manque de troll politique...
- [19/03@09:57] Éric Besson devient "secrétaire d'État chargé du développement de l'économie numérique"
- [02/03@20:04] "« Propriété intellectuelle » est un euphémisme malencontreux"
- [24/01@15:35] Un nouveau processeur VIA
- [21/01@09:35] [presque HS] Le rapport Attali « propriété » de l'éditeur Bernard Fixot !
- [16/01@14:18] Qu'est-ce qu'un outils de développement de rève ?
- [14/12@14:41] Qu'est-ce que bien gérer les erreurs dans ses programmes ?
- [14/12@13:56] "Accord Olivennes: Une vision consumériste de la culture"
- [06/12@16:53] P2P : L'Association des auteurs-compositeurs canadiens propose ... la licence globale !
- [03/12@20:03] Comment les programmeurs écrivent du code flottant ?
- [29/11@17:21] Vente de geek
- [29/11@13:02] Conférence: L'auteur du rapport sur la lutte contre le piratage sur internet à Science Po
- [20/11@22:39] 2 ans plus tard et toujours autant de conneries !
- [12/11@14:21] Comment vendre 100 000 single et toucher 477¤.
- [11/11@14:18] Qu'est-ce qu'un langage sécurisé ?
- [29/10@14:22] Boycote des CD ?
- [12/10@08:29] "revenir sur l'inscription du principe de précaution dans la Constitution"
- [11/10@15:58] Pas de licence 3G pour Free.
Journal : Lisaac plus rapide que le C !
Posté par Nicolas Boulay () le 24 avril 2008C'est fait, Lisaac, un langage impératif à prototype, a plus de point que le C dans le langage shoutout. Il s'agit de microbenchmarks, dont l'algorithme est imposé.
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all(...)
Cela fait un test un peu plus complet que le code mpeg2 qui servait de test.
http://isaacproject.u-strasbg.fr/li/li_benchs.html
Chapeau à Ben !
> Lire le journal (157 commentaires, moyenne: 3,4).
...
Heu, a part pour les arbres binnaires, il n'y a pas de grosses differences : http://shootout.alioth.debian.org/gp4/benchmark.php?test=all(...)
Et puis bon le pb de shootout, c'est que les "tests" ne sont pas forcement représentatif.
-
[^]Re: ...
Posté par Nicolas Boulay () le 24/04/2008 à 22:22. (lien). Évalué à 2."Et puis bon le pb de shootout, c'est que les "tests" ne sont pas forcement représentatif."
C'est pas le problème du shoutout, c'est le problème des microbenchs en général par rapport à un bench applicatif.
Mais si un langage n'est pas devant dans ce genre de cas, il a très peu de chance d'être devant dans des cas plus gros.
-
[^]Re: ...
Posté par Matthieu C () le 24/04/2008 à 22:28. (lien). Évalué à 10.Et puis bon le pb de shootout, c'est que les "tests" ne sont pas forcement représentatif.
J'ai regarder le cas des arbres binnaires, et on peut voir un beau malloc dans l'implementation.
Celui ci est appelé un certain nombre de fois (59157182).
Un coup de profiler confirme que ce test benchmark l'allocateur memoire de la libc...-
[^]Re: ...
Posté par alenvers () le 25/04/2008 à 09:52. (lien). Évalué à 7.Effectivement, en 5 minutes, j'ai remplacé l'allocation par de la pré-allocation et les perfs sont multipliées par 10. Niveau consommation de mémoire ce n'est pas ça (mais on s'en fout ici, ça peut être réglé avec un peu plus d'effort).
Sans optimisation :
bash-3.2$ time ./binarytrees.gcc_run 16
stretch tree of depth 17 check: -1
131072 trees of depth 4 check: -131072
32768 trees of depth 6 check: -32768
8192 trees of depth 8 check: -8192
2048 trees of depth 10 check: -2048
512 trees of depth 12 check: -512
128 trees of depth 14 check: -128
32 trees of depth 16 check: -32
long lived tree of depth 16 check: -1
real 0m11.233s
user 0m8.983s
sys 0m0.000s
Avec :
bash-3.2$ /usr/bin/gcc -pipe -Wall -O3 -fomit-frame-pointer -march=pentium4 -lm binarytrees.c -o binarytrees.gcc_run
bash-3.2$ time ./binarytrees.gcc_run 16
stretch tree of depth 17 check: -1
131072 trees of depth 4 check: -131072
32768 trees of depth 6 check: -32768
8192 trees of depth 8 check: -8192
2048 trees of depth 10 check: -2048
512 trees of depth 12 check: -512
128 trees of depth 14 check: -128
32 trees of depth 16 check: -32
long lived tree of depth 16 check: -1
real 0m1.235s
user 0m0.843s
sys 0m0.140s
void* mem_chunks = NULL;
char* mem_pos = NULL;
char* mem_chunks_nbr = 0;
void
*my_malloc(size_t NBYTES)
{
char* temp;
if (! mem_chunks)
mem_pos = mem_chunks = malloc(NBYTES * 100000000);
temp = mem_pos;
mem_pos += NBYTES;
mem_chunks_nbr++;
return temp;
}
void
*my_free(void *APTR)
{
if (! --mem_chunks_nbr) {
free(mem_chunks);
mem_chunks = NULL;
}
return NULL;
}
-
[^]Re: ...
-
-
-
[^]Re: ...
Posté par Philippe Fremy (page perso, ) le 25/04/2008 à 10:25. (lien). Évalué à 3.Les tests sont intéressants, même si il faut les prendre avec des pincettes. Ca donne un aperçu du potentiel.
Un autre indice que le C n'est pas la panacée est arrivé par python. La version .NET de python (IronPython) est arrivé soit à égalité, soit a été légèrement plus rapide que la version en C de l'interpréteur python sur une série de benchmark officiels.
Ca veut bien dire que on peut faire plus vite que du C. Je pense que c'est vrai en particulier sur des projets complexes, où le compilateur peut prendre une décision plus informée que l'être humain.
Sinon pour lisaac, si je me souviens bien, lisaac analyse l'ensemble du programme pour en optimiser tous ses aspects. Ca veut dire que sur un petit programme, il peut enlever des contraintes que le programmeur en C garderait. Après, sur un très gros programme, on peut imaginer qu'il pourra enlever beaucoup moins de contraintes et donc aura plus de mal à générer du code performant. Ou peut-être au contraire, il découvrira des optimisations inaperçues à la vue du programmeur.
L'absence de notion de bibliothèque est aussi un problème. Si j'ai bien compris les dernières explications sur le sujet, la notion de bibliothèque va justement réduire les capacités d'optimisation de lissac, puisque celui-ci ne pourra pas optimiser la partie du code externe.
Si tout le monde migrait a lissac, ce serait un peu comme passer à une gentoo en stage 1. Un truc de geek quoi.-
[^]Re: ...
Posté par Mildred (Jabber id, page perso, ) le 25/04/2008 à 12:19. (lien). Évalué à 3.Le système de bibliothèques sur lequel je travaille n'enlève rien aux optimisations ... Car ce sont des bibliothèques sources (il n'est pas encore possible de compiler les bibliothèques séparément).
Reste à soumettre ça dans le tronc principal :)
Sinon, pour l'avenir, on peut très bien imaginer des modules binaires (donc compilation séparée et possibilité de chargement runtime) qui utilise une interface bien définie quelque part. Et dans ce cas, il paraît évident que certaines optimisations vont partir. Mais comme en général on se débrouille pour avoir une interface minimale entre des modules, ça ne devrait pas être gênant je pense.
-
Hum
Dans l'article de wikipedia, on peut lire: "Le compilateur Lisaac génère du C ANSI optimisé".
Donc Lisaac n'est pas plus rapide que le C, puisque c'est du C.
-
[^]Re: Hum
Posté par Nicolas Boulay () le 24/04/2008 à 22:21. (lien). Évalué à 9.A bah, non, c'est de l'assembleur puisque le C génère de l'assembleur.
-
[^]Re: Hum
Posté par yellowiscool (Jabber id, page perso, ) le 24/04/2008 à 22:24. (lien). Évalué à 0.C'est gcc qui fait de l'assembleur.
Enfin, je comprend très bien l'idée qu'un langage de plus haut niveau arrive à faire mieux en rajoutant ses propres optimisations en plus de celles de gcc. C'est juste que on en revient encore une fois à gcc, et donc la puissance du C.-
[^]Re: Hum
Posté par Nicolas Boulay () le 24/04/2008 à 22:26. (lien). Évalué à 7.Dire que Lisaac c'est du C, c'est aussi débile que dire que du C, c'est de l'assembleur car c'est ce que génère gcc.
-
[^]Re: Hum
Posté par Mathieu Stumpf (Jabber id, page perso, ) le 25/04/2008 à 08:56. (lien). Évalué à 10.Je suis d'accord, mais dans ce cas faut pas venir clamer avec des trompette que tel langage est plus rapide que tel autre. Ça veux dire quoi la vitesse d'un langage?
Ce sont les processus exécutants des tâches aux finalités équivalentes sur un même matériel qui sont plus où moins performants. Éventuellement les programmes qu'éxécutent ces processus sont écrit dans un langage différent.-
[^]Re: Hum
Posté par Nicolas Boulay () le 25/04/2008 à 14:01. (lien). Évalué à 4.Disons que si tu prends 2 codeurs moyen avec un temps fixe de développement, tu auras un binaire plus rapide sous Lisaac que sous C. Car c'est plus costaux d'optimiser à mort pour C.
Ce sont les processus exécutants des tâches aux finalités équivalentes sur un même matériel qui sont plus où moins performants. Éventuellement les programmes qu'éxécutent ces processus sont écrit dans un langage différent.
c'est ça un bench. Même algo, même machine, même donné, seul change le langage, donc toute différence de performance peut-être imputé au langage, ou au codeur. C'est l'intérêt du développement ouvert du shoutout tout le monde peut proposer mieux.-
[^]Re: Hum
Posté par 2PetitsVerres () le 25/04/2008 à 14:14. (lien). Évalué à 9.donc toute différence de performance peut-être imputé au langage, ou au codeur.
Ou au compilateur, vu qu'il est possible de faire deux compilateurs pour un même langage dont les binaires résultants n'auront pas la même vitesse d'exécution.
-
-
-
[^]Re: Hum
Posté par calandoa () le 25/04/2008 à 10:45. (lien). Évalué à 1.Il n'y a rien de débile à dire que Lisaac c'est du C et de l'assembleur ; ce qui serait débile, c'est de dire que l'assembleur c'est du C ou du Lisaac.
Dit de manière (un peu) plus formelle, pour tout code en Lisaac, il existe un code équivalent en C ou en assembleur (ça reste encore un peu boiteux car le terme équivalent dépend du compilateur utilisé).
Et de fait, Lissac ne sera jamais plus rapide ou économe en mémoire que le C (désolé pour ton journal). Évidemment, ça ne prouve pas qu'il s'agisse d'un mauvais langage, car il est peut être plus facile à écrire et à débugger que le C, ce que le benchmark en question n'essaye pas de juger.-
[^]Re: Hum
Posté par Joc M () le 25/04/2008 à 14:49. (lien). Évalué à 2.ça reste encore un peu boiteux car le terme équivalent dépend du compilateur utilisé
C'est pas boiteux du tout. Tout langage est équivalent à tout autre sur le plan théorique. Ce qui définit le terme de langage c'est un formalisme pour décrire un calcul au sens Turing du terme.
Donc c'est pas boiteux... Seulement on a l'habitude de convertir dans un sens (compiler le C en assembleur par exemple) et pas dans l'autre.--
be a sheep isn't cheap-
[^]Re: Hum
Posté par Aldoo (Jabber id, ) le 25/04/2008 à 18:19. (lien). Évalué à 3.Ouhla ! Il y a équivalence et équivalence !
Tout langage de programmation digne de ce nom est Turing-complet, c'est à dire équivalent fonctionnellement à une machine de Turing.
Cela ne veut pas dire que l'on peut programmer des programmes également efficaces dans tous les langages Turing-complets.
D'ailleurs, y a qu'à voir comment est décrite la machine de Turing pour s'en rendre compte (combien de temps pour faire tourner un algo disons de tri sur une machine à ruban unique ?).-
[^]Re: Hum
Posté par mdlh () le 26/04/2008 à 04:03. (lien). Évalué à 0.Si je ne me trompe pas, un systeme turing-complet est un systeme qui est capable de calculer tout ce que la machine de Turing peut calculer.
C'est different de Turing-equivalent, qui inclue en plus le fait qu'une machine de Turing soit capable de calculer ce que ton system peut calculer [L'autre sens, en gros].
Si Turing-complet n'implique pas Turing-equivalent au sens strict, il s'observe dans la pratique que les systemes Turing complet sont aussi Turing-equivalent.-
[^]Re: Hum
Posté par outs () le 26/04/2008 à 08:48. (lien). Évalué à 2.Hein ?
les machine de turing peuvent tout calculer. En particulier en peut prendre la machine de turing universelle qui simule une machine de turing codé dans sa bande.
Et tous les langage des prog peuvent simuler une machines de turing (ca doit prendre 10minutes a programmer).
bref je ne vois pas la différence entre ta turing-équivalence et complétude.-
[^]Re: Hum
Posté par Aldoo (Jabber id, ) le 26/04/2008 à 12:36. (lien). Évalué à 6.Non une machine de Turing ne peut pas tout calculer, juste ce qui est calculable. Pas le problème de l'arrêt, par exemple. Pas la question dont la réponse est 42 non plus.
-
[^]Re: Hum
Posté par outs () le 26/04/2008 à 20:18. (lien). Évalué à 4.Arf c'était sous entendu.
Concernant 42, si on suppose que la question a laquelle on répond 42 est calculable. Ce qui semble logique puisque dans l'histoire pensée profonde arrive trouver la réponse en un temps fini de 7 500 000 année. Alors on pourrait imaginer énumérer toutes les machines de turing en ordre canonique (toutes les machines de taille 1, puis toutes les machines de taille 2). Et en même temps simuler simultanément (en parallèle) toutes les machines déjà générée à l'instant t sur toutes les entrée possible dans l'ordre canonique également. Quand je dis simuler en parallèle c'est important, puisque une machine de turing ne se termine pas forcement (sur une entrée) on ne peut pas se contenter de lancer chaque calcul à la suite.
Donc à partir de là on pourrait avoir une liste de machines de turing qui termine en écrivant 42. Bon le problème c'est pour savoir quelle est la bonne question parmi toutes celles qui sont dans la liste. Là effectivement faudrait ptet ouvrir la tête d'Arthur pour la choisir, mais bon je doute de la trouver là :-)
-
-
-
[^]Re: Hum
Posté par Aldoo (Jabber id, ) le 26/04/2008 à 12:35. (lien). Évalué à 2.Moui, ce que tu dis est juste dans l'absolu (normalement la X-complétude n'est pas l'équivalence à X).
Enfin tout ça aurait un sens si on avait d'autres modèles de calcul plus puissants (fonctionnellement) que la machine de Turing, ce qui n'est pas possible avec ce qu'on appelle calculable, et encore moins avec ce qui est effectivement calculable dans un ordinateur (à mémoire finie).
Enfin bref quoiqu'il en soit, tout en gardant la puissance d'une machine de Turing universelle, on peut imaginer des paquets de modèles de calcul plus ou moins efficaces, dont un paquet qui sont basés sur les comportements possibles d'un processeur classique sur un sous-langage de l'assembleur. Ces sous-langages étant la cible des différents compilateurs.-
[^]Re: Hum
-
[^]Re: Hum
Posté par Ernest H (Jabber id, ) le 28/04/2008 à 18:22. (lien). Évalué à 2.Mais, on en a des modèles de calcul plus puissants que la machine de Turing : hypercalcul ! Ce qui sauve la thèse se Church, c'est que ce ne sont que des modèles et que personne n'a jamais vu de machines qui sont effectivement super-Turing... Mais qui a vu des machines de Turing de toute façon ?
-
[^]Re: Hum
Posté par imalip (page perso, ) le 28/04/2008 à 18:49. (lien). Évalué à 2.Bon, c'est pas exactement des machines de Turing, mais perso j'ai vu une Bombe et un Colossus reconstruits. Habitant a coté de Bletchley Park fallait bien que je visite quand meme :)
--
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal
-
[^]Re: Hum
Posté par Aldoo (Jabber id, ) le 29/04/2008 à 14:01. (lien). Évalué à 2.M'enfin certes. Mais c'est hors-sujet. Aucune machine physique ne peut ni ne pourra jamais implanter un hypercalculateur.
D'où les précautions que je mettais autour du terme "calculable" pour qu'on se limite aux cas pratiques réels (temps fini et mémoire finie pour une instance), alors même que j'ignorais l'existence de l'hypercalcul (mais me doutais bien qu'un truc dans ce genre devait exister ! ;-) ).
-
-
-
-
-
-
-
[^]Re: Hum
Posté par fcartegnie () le 27/04/2008 à 18:27. (lien). Évalué à 2.Comment ça c'est débile ?
C'est pas de l'assembleur d'ailleurs, ce sont des octets.
-
-
-
-
[^]Re: Hum
Posté par auve () le 24/04/2008 à 22:25. (lien). Évalué à 6.Il faut lire « du C écrit par un humain ».
-
[^]Re: Hum
Posté par Maxime (Jabber id, ) le 24/04/2008 à 22:30. (lien). Évalué à 3.Bah il suffit d'être un humain capable de faire toutes les optimisations imaginables dans ce cas.
Bon ok, on risque de perdre en lisibilité toussa mais c'est un autre problème.-
[^]Re: Hum
Posté par Nicolas Boulay () le 24/04/2008 à 23:35. (lien). Évalué à 4.et passer un temps hyper long...
-
[^]Re: Hum
Posté par briaeros007 () le 25/04/2008 à 00:04. (lien). Évalué à 4.c'est pour ça que l'homme a inventé l'informatique : pour faire les taches longues pénibles et très souvent répétitive à une armée de singe en silicone.
Comme ça, le serpent se mord bien la queue :P--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
[^]Re: Hum
Posté par Maxime (Jabber id, ) le 25/04/2008 à 03:13. (lien). Évalué à 9.Pour revenir à ce que disait yellowiscool, je ne comprend pas vraiment son moinsage... Il n'a pas tord :
Si Lisaac génère du C, j'ai du mal à voir comment on peut dire que c'est plus rapide que le C comme tu le prétends dans ton titre.
Par contre en effet, le Lisaac permet visiblement de générer un code plus optimisé et donc plus rapide que si on avait codé directement en C sans être un génie de l'optimisation.-
[^]Re: Hum
Posté par Guid (page perso, ) le 25/04/2008 à 09:48. (lien). Évalué à 7.Pour revenir à ce que disait yellowiscool, je ne comprend pas vraiment son moinsage... Il n'a pas tord :
Si Lisaac génère du C, j'ai du mal à voir comment on peut dire que c'est plus rapide que le C comme tu le prétends dans ton titre.
gcc génère de l'assembleur à partir de C, est-ce qu'on peut dire que le C c'est de l'assembleur ?
Faut arrêter de faire souffrir les drosophiles tout le monde a bien compris de quoi il s'agissait au delà de l'abus de langage.-
[^]Re: Hum
Posté par Benoît Guédas (Jabber id, ) le 25/04/2008 à 10:06. (lien). Évalué à 8.gcc génère de l'assembleur à partir de C, est-ce qu'on peut dire que le C c'est de l'assembleur ?
Ce n'est pas du tout ce qui est dit : personne n'a dit que Lisaac c'était du C.
Quelqu'un a-t-il aussi proclamé que le C était plus rapide que l'assemble ? Je ne pense pas.-
[^]Re: Hum
Posté par Benoît Guédas (Jabber id, ) le 25/04/2008 à 10:10. (lien). Évalué à 2.Bon, on dirait que mon clavier s'est blo (sur l'assembleur) ;-)
En tous cas, dans le cas de Lisaac, il existera toujours au moins un programme C aussi performant que celui en Lisaac : celui généré par Lisaac, ou un autre. C'est tout.-
[^]Re: Hum
Posté par Nicolas Boulay () le 25/04/2008 à 14:01. (lien). Évalué à 2.Sauf qu'un humain mettra infiniment plus de temps à le générer que le compilo Lisaac.
-
[^]Re: Hum
-
-
-
-
[^]Re: Hum
Posté par Maxime (Jabber id, ) le 25/04/2008 à 12:46. (lien). Évalué à 6.Je n'ai pas dit que Lisaac c'était du C mais il a été dit que ça générait du C.
Par exemple, pour ceux comme moi qui ne connaissent pas Lisaac, on peut imaginer un langage qui a des fonctions de très haut niveau et qui te génère du C méga optimisé et tu pourras en arriver à la même conclusion qu'ici.
Après, on peut prendre le même raisonnement avec le C et l'assembleur. On pourra tjs dire que le C peut-être plus facilement optimisable mais au final, vu qu'on se retrouve avec du code assembleur, on ne peut pas dire qu'il est plus rapide mais seulement qu'il peut être plus rapide que du code assembleur qui sort d'un codeur.
Un exemple simple :
Tu fais un programme de tri qui fait appel à la fonction qsort en C. Derrière ça te génère du code ultra optimisé mélangeant du quicksort à d'autres tris etc.
Maintenant, tu me demandes de te le faire en assembleur, je vais te faire un truc moins optimisé car je serais déjà bien content que ça marche :).
Est-ce qu'on peut dire que le C est plus rapide que l'assembleur ? non.
-
-
[^]Re: Hum
Posté par alenvers () le 25/04/2008 à 10:04. (lien). Évalué à 4.>Par contre en effet, le Lisaac permet visiblement de générer un code
>plus optimisé et donc plus rapide que si on avait codé directement en
>C sans être un génie de l'optimisation.
Il n'y pas besoin d'être un génie du C pour faire repasser le C devant... Il suffit de faire de la pré-allocation pour les arbres binaires (cfr. mon code dans un post plus haut).-
[^]Re: Hum
Posté par Nicolas Boulay () le 25/04/2008 à 14:04. (lien). Évalué à 2.La différence est minime de toute façon, c'est symbolique...
Propose ta modification. Mais fait attention aussi que tu respectes bien les règles de codages, si tu change l'algo cela n'a pas de sens, et que si tu fais exploser la consommation mémoire tu y perds sur ce paramètre.-
[^]Re: Hum
Posté par alenvers () le 25/04/2008 à 14:27. (lien). Évalué à 3.>Propose ta modification.
Pour ça, il faudrait que l'allocation soit un peu plus propre et plus dynamique ;-) J'ai pas trop envie d'en faire plus. C'était juste pour avoir une estimation de l'ordre de grandeur du remplacement de l'allocation de mémoire.
>si tu change l'algo cela n'a pas de sens
Rien changé, juste remplacé les malloc/free par les miens.
-
[^]Re: Hum
Posté par alenvers () le 28/04/2008 à 16:29. (lien). Évalué à 2.Voila, j'ai soumit un autre programme :
http://alioth.debian.org/tracker/index.php?func=detail&a(...)
Les perfs sont encore meilleures que lors de mes modifications précédentes. Nous en sommes à un facteur de plus ou moins 15.
Bientôt (si c'est accepté), un journal avec le titre :
"Lisaac plus rapide que le C ? Pas du tout, efface !"-
[^]Re: Hum
Posté par Nicolas Boulay () le 28/04/2008 à 17:57. (lien). Évalué à 3.Si tu as respecté l'algo de base, c'est le jeu !
-
[^]Re: Hum
Posté par alenvers () le 29/04/2008 à 08:42. (lien). Évalué à 3.>Si tu as respecté l'algo de base, c'est le jeu !
Oui mais non :
How should I implement programs for the Benchmarks Game?
We prefer plain vanilla programs - after all we're trying to compare language implementations not programmer effort and skill.
De plus, je viens de remarquer qu'il existe une implémentation qui est beaucoup plus performante que celle utilisée sur le site http://alioth.debian.org/plugins/scmcvs/cvsweb.php/shootout/(...)
La mienne est plus rapide mais peu être considérée moins "vanilla". (Par ailleurs, je ne sais pas pourquoi cette version n'est pas utilisée).-
[^]Re: Hum
Posté par Nicolas Boulay () le 29/04/2008 à 09:35. (lien). Évalué à 3.Les algos proposés sont parfois loin d'être optimal pour le problème posé. Une solution plus performante mais ne respectant pas l'algo original ne sera pas retenu.
-
[^]Re: Hum
Posté par alenvers () le 29/04/2008 à 12:35. (lien). Évalué à 2.http://alioth.debian.org/plugins/scmcvs/cvsweb.php/shootout/(...)
Cela fait 18 mois qu'il est dans le cvs mais pas dans la comparaison, je ne sais pas pourquoi (Rien trouvé à ce sujet) :
- L'algo est le même (c'est juste une minimisation des appels à malloc via une réutilisation des noeuds libérés).
http://shootout.alioth.debian.org/gp4/faq.php#alternative
What does Interesting Alternative Program mean?
Interesting Alternative Program means that the program doesn't implement the benchmark according to the arbitrary and idiosyncratic rules of The Computer Language Benchmarks Game - but we simply couldn't resist showing the program.
= En résumé, les règles sont arbitraire...-
[^]Re: Hum
Posté par Ontologia (page perso, ) le 29/04/2008 à 14:46. (lien). Évalué à 3.C'est clair. Et c'est dommage. On a du se battre pour insérer le langage, et ya fallu que Dominique Colnet, l'auteur d'Eiffel pousse une gueulante pour que ça passe.
C'est vraiment dommage, car on pourrait inclure d'autres langages intéressants. Personnellement, je me fiche que le langage soit connu ou pas.
Le shootout est un des rares cas où l'on peut voir différents langages en action pour autre choses que des hello world ou 1001 bottle of beer, et ça serait passionant de voir les spécificités de chacun, en vitesse, en concision, en syntaxe, etc...
ça me ferait franchement marrer de voir un bench avec du brainfuck ou du whitespace !
Franchement, je me suis carrément dit qu'il faudrait leur piquer le code source (c'est libre) et remonter le projet ailleurs, en étant moins arbitraire..-
[^]Re: Hum
Posté par alenvers () le 29/04/2008 à 16:03. (lien). Évalué à 2.>en étant moins arbitraire..
La première chose à faire pour ça, c'est d'autoriser tous les algo pour résoudre un problème précis car il est évident que certains paradigmes(OO, fonctionnel, impératif, ...)/algo s'implémentent mieux (sont plus efficaces) dans certains langages.-
[^]Re: Hum
Posté par Ontologia (page perso, ) le 29/04/2008 à 19:10. (lien). Évalué à 2.Oui mais là, on compare des algorithmes, et plus des compilateurs.
Comparer des algos, c'est ce que fait le meteor-contest par exemple...
Ce serait intéressant de mettre les deux, mais de bien pouvoir séparer les résultats.-
[^]Re: Hum
Posté par alenvers () le 29/04/2008 à 20:58. (lien). Évalué à 2.>Oui mais là, on compare des algorithmes, et plus des compilateurs.
Oui mais non, si un algo est meilleurs pour un langage, il suffit d'implémenter le même dans les autres... On se retrouvera rapidement aux meilleurs algo dans tous les langages.
-
-
[^]Re: Hum
Posté par Nicolas Boulay () le 30/04/2008 à 09:50. (lien). Évalué à 2.Tu ne sais plus trop ce que tu tests dans ce cas là.
Il vaut mieux un truc imparfait avec une imperfection borné, qu'un truc ou tu ne sais quoi dire des chiffres. Est-ce que les chiffres est faibles car l'algo n'est pas le meilleur ?, etc...-
[^]Re: Hum
Posté par alenvers () le 30/04/2008 à 10:19. (lien). Évalué à 2.Cfr. (un post plus haut) :
https://linuxfr.org/comments/926979.html#926979
>Tu ne sais plus trop ce que tu tests dans ce cas là.
Si on sait exactement ce qu'on teste, le meilleur algo dans chaque langage. Car , par exemple, dans un langage fonctionnel, on ne développe pas comme dans de l'oo ou de l'impératif et les algos efficaces sont par voie de conséquence différents.
>Il vaut mieux un truc imparfait avec une imperfection borné, qu'un truc
>ou tu ne sais quoi dire des chiffres.
Non, figer l'algo biaise car certains algo sont plus adaptés aux paradigmes de certains langages.-
[^]Re: Hum
Posté par Nicolas Boulay () le 30/04/2008 à 14:56. (lien). Évalué à 2."Non, figer l'algo biaise car certains algo sont plus adaptés aux paradigmes de certains langages."
J'y crois moyen... Que certain algo soit plus facile à écrire avec certain langage, c'est une évidence. Mais les performances sont lié à l'algorithme et le traitement capable d'être fait par le compilateur.
Tu as des exemples ?-
[^]Re: Hum
Posté par alenvers () le 01/05/2008 à 00:09. (lien). Évalué à 3.Oui, par exemple :
http://www.haskell.org/haskellwiki/Introduction#When_C_is_be(...)
Les langages fonctionnels ont tendance à faire exploser la complexité en espace. Mais l'espace c'est du temps aussi ;-) Donc, les versions fonctionnelles du quicksort sont moins efficaces que dans un langage impératif. Un quicksort en place est plus efficace qu'un quicksort non en place. Le quicksort en place n'est pas exprimable en fonctionnel (a moins que le compilo soit vraiment vraiment vraiment intelligent, mais ça c'est de la science fiction actuellement).
Un quicksort en place et un non en place ne sont pas les mêmes algos. Si on choisit d'implémenter le non en place ce n'est pas équitable car C peut faire mieux (et pas Haskell). Si on prend le en place ce n'est pas équitable car Haskell aura des problèmes pour l'exprimer.-
[^]Re: Hum
Posté par Nicolas Boulay () le 02/05/2008 à 09:33. (lien). Évalué à 2.Je trouve que c'est très équitable : Haskel ne permet pas de faire l'algo quicksort le plus rapide. C'est bien l'intéret d'un (micro) bench !
Pour être juste, je pense qu'il faudrait pouvoir mettre l'algo de trie que l'on veut. Mais si le quicksort est le plus rapide, alors Haskel produit dans tous les cas de trie, un code plus lent que C.
Si on prend le en place ce n'est pas équitable car Haskell aura des problèmes pour l'exprimer.
Je ne vois pas pourquoi cela serait injuste, c'est le but du test de montrer ce genre de limitation.
-
-
-
-
-
-
[^]Re: Hum
-
-
-
-
-
-
-
-
-
-
-
[^]Re: Hum
Posté par Moogle (page perso, ) le 25/04/2008 à 12:08. (lien). Évalué à 4.On peut pas faire un langage C qui s'auto-optimise ? Genre du C transformé en C optimisé transformé en ASM transformé en binaire transformé en signaux électriques transformé en déplacement de molécules transformé en ...
(et si on pouvait re-optimiser le C déjà optimisé, quelle classe)-
[^]Re: Hum
Posté par Maxime (Jabber id, ) le 25/04/2008 à 12:52. (lien). Évalué à 2.Vu que gcc optimise ton code C, tu voudrais qu'en plus il te donne l'équivalent en C que tu aurais dû taper pour que ce soit optimal ?
Quel est l'intérêt ? Pouvoir te la péter avec du code illisible mais plus rapide si gcc n'optimisait pas ? C'est tordu quand même :P.-
[^]Re: Hum
Posté par mdlh () le 25/04/2008 à 23:23. (lien). Évalué à 2.Genre un compilateur qui est capable d'effectuer des optimisations poussees en terme d'analyse inter-procedurales mais qui n'a pas de backend pour ta plateforme?
Ou que le resultat reinjecte dans GCC, avec moins d'ambiguite permet a GCC de rajouter un couche d'optimisation?
Hum.... llvm avec le backend cbe.-
[^]Re: Hum
Posté par Vador Dark (Jabber id, ) le 27/04/2008 à 02:18. (lien). Évalué à 3.Bin c'est couillons parce que l'optimisation dépend aussi fortement de la plateforme. Une façon de faire quelque chose peut-être plus rapide sur une plate-forme que sur une autre.
Du coup, en optimisant ton code pour une plate-forme, et en balancant le résultat sur une autre plate-forme, tu pourrais même y perdre.
De plus, je pense que ça n'a pas toujours de sens de parler d'équivalent en C du programme optimiser. Parfois, tu décris une action en C, et le compilateur aura un choix a faire pour le retranscrire en assembleur. Il n'y a pas forcément une équivalence strict entre l'assembleur et le C.-
[^]Re: Hum
Posté par mdlh () le 28/04/2008 à 17:10. (lien). Évalué à 2.Un compilo travaille sur plusieurs niveaux. L'optimisation de code pour une plateforme donnee en est un mais pas le seul. Celles de haut-niveau sont generiques et ne dependent pas de la plateforme.
En terme d'optimisation de code, tu as deux approches compatibles:
- Faire moins
- Faire plus vite
Si une approche de haut niveau est capable d'eliminer du code, peux importe l'optmisation de la plateforme: ne rien faire est plus rapide que quelque chose d'optimise. Un exemple pratique: Une classe A avec appel de methode virtuelle. A chaque appel de la methode, le code genere doit d'abord determiner quelle methode doit etre effectivement appele. Si une analyse pousse prouve que seule une sous-classe B est utilisee, et que la methode correspondante est statique, alors tu peux supprimer la recherche: tu connais la methode au moment de la compilation.
Pour info, les compilos avec une sortie en C n'effectue pas une traduction code machine vers C. La traduction s'effectue depuis la representation intermediaire, avant l'optmisation pour la plateforme.
-
-
-
-
-
-
Miloud
Je suis en train de préparer la sortie de Miloud !
Miloud plus rapide que Lisaac !
En effet, Miloud est de plus haut niveau que Lisaac et offre plus de possibilité d'optimisation que Lisaac.
Ça génère du Lisaac...
-
[^]Re: Miloud
Posté par ptifeth (page perso, ) le 24/04/2008 à 22:43. (lien). Évalué à 8.Ça me rappelle un OS de très haut niveau [0] construit sur l'OS le plus bas niveau qui fût. Son créateur envisageait de réorganiser la société humaine sur ces bases d'ailleurs. Miloud a-t-il des visées politiques ?
[0] Utilisateur:Haypo/MultiDeskOS-
[^]Re: Miloud
-
[^]Re: Miloud
Posté par Victor STINNER (page perso, ) le 25/04/2008 à 12:18. (lien). Évalué à 5.Oh, mon article enfin cité, c'est la consécration !
-
[^]Re: Miloud
Posté par Mathieu Stumpf (Jabber id, page perso, ) le 25/04/2008 à 15:51. (lien). Évalué à 2.Faut dire il et bien plaqué. Moi je croyais que MultideskOS avait disparu de wikipedia...
-
[^]Re: Miloud
Posté par Victor STINNER (page perso, ) le 28/04/2008 à 14:27. (lien). Évalué à 2.L'article ne fait pas parti du Wikipédia officiel (l'article ne fait pas parti de l'encyclopédie). C'est un article dans ma page perso qui ne fait parti d'aucune catégorie Wikipédia.
-
-
-
Les benchmarks c'est du bullshit
Sauf un peut-être : s'il existait un outil professionnel de mouling en lisaac on verrait quel langage preumse le plus vite.
-
[^]Re: Les benchmarks c'est du bullshit
Langage de "très haut niveau"?
Pour moi langage de haut niveau ça veut dire "code concis". Eh bien, pour lisaac, c'est loin d'être le cas!
http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?t(...)
Lisaac arrive pratiquement en dernière position, et, à en croire ce benchmark, il est plus de deux fois plus verbeux que python et ruby, et même plus verbeux que le vénérable C. Autant programmer en C donc, c'est aussi rapide et pas plus verbeux que lisaac, et beaucoup plus mature et mieux supporté.
-
[^]Re: Langage de "très haut niveau"?
Posté par Mathieu Stumpf (Jabber id, page perso, ) le 25/04/2008 à 10:25. (lien). Évalué à 1.Oui enfin le nombre de ligne ne fait pas tout.
-
[^]Re: Langage de "très haut niveau"?
Posté par JoeltheLion () le 25/04/2008 à 10:28. (lien). Évalué à 3.C'est pas le nombre de lignes, c'est la taille du code zippé. Ok, c'est pas ultime comme benchmark, mais je pense que ça reflète quand même la réalité. D'ailleurs, il suffit de jetter un coup d'oeil au code pour voir que c'est très verbeux. Alors, appeler ça un "langage de très haut niveau", c'est un peu abuser...
-
[^]Re: Langage de "très haut niveau"?
Posté par Jehan (page perso, ) le 25/04/2008 à 11:47. (lien). Évalué à 9.Bonjour,
ce n'est pas vraiment la définition d'un langage de haut niveau. Un langage de haut niveau se définit plutôt par ses possibilités de programmation "conceptuelle", "abstraite". En gros l'idée est de s'éloigner de toute notion trop concrète (vis à vis du matériel informatique du moins), pas d'allocation mémoire (et toute gestion de mémoire d'ailleurs, pour que les segfaults ne soient plus qu'un lointain souvenir...), encore moins de libération mémoire (garbage collector...), ne plus se poser de questions s'il est plus optimisé de mettre une variable par valeur ou par référence, s'il est mieux d'utiliser un pointeur, une référence, une copie, ne pas avoir à gérer des tailles de conteneur (prévoir les tailles des chaînes de caractère, les vecteurs & co à l'avance, puis les redimensionner ensuite notamment), etc.
En gros, plus un langage est haut niveau, moins on s'occupe de l'ordinateur et essentiellement du but et de comment on veut y arriver éventuellement (quoique le plus haut niveau qui soit, on pourrait imaginer qu'il n'y a même plus du tout à s'occuper du "comment").
- L'une des manières d'y arriver est parfois effectivement de faire dans la simplicité, ou la flexibilité, notamment du langage, et donc d'avoir un langage concis. Beaucoup pour cela vont par exemple abstraire un peu les notions de type (typage faible) sans déclaration de variable souvent (et donc du type).
- Mais aussi souvent c'est d'aller de plus en plus au sémantique par exemple, et pour cela, un langage va souvent devenir verbeux. Notamment on veut que quelqu'un puisse lire et comprendre votre programme du premier coup sans le connaître par exemple.
- Le conceptuel est aussi très présent. Ainsi la prog objet a été un pas vers le haut niveau: c'était l'idée de concevoir la prog comme une manipulation d'objets qui "savent" faire certaines choses. D'autres se sont dits qu'ils allaient plutôt concevoir le "monde" comme un endroit avec des faits (prédicats) et des règles. Ca donne des langages logiques comme Prolog. Il y a aussi d'autres concepts, pour enregistrer les données par ex, a-t-on besoin d'une pile (on met les objets les uns sur les autres), d'une liste, etc.
En fait il y a beaucoup de façon de concevoir du "haut niveau" et cela peut mener à divers types de langage, parfois verbeux, parfois non. Mais la seule constante, c'est s'abstraire de la machine. Et la verbosité n'a rien à voir là dedans.-
[^]Re: Langage de "très haut niveau"?
Posté par JoeltheLion () le 25/04/2008 à 11:51. (lien). Évalué à 2.Je suis tout à fait conscient que j'utilise une définition très restreinte de ce qu'est un langage de très haut niveau. Mais c'est le seul aspect du haut niveau qui m'intéresse, donc je l'assume :)
Franchement, quel est l'intérêt de s'abstraire de la machine si ça ne résulte pas en un code plus clair et plus concis?-
[^]Re: Langage de "très haut niveau"?
Posté par Jehan (page perso, ) le 25/04/2008 à 12:35. (lien). Évalué à 8.En fait plus concis ne signifie pas forcément plus clair. Ca peut l'être, mais ça peut aussi être tout l'inverse. Pour le développeur en particulier, c'est clair que plus y a de touches à taper, plus c'est chiant. Par contre pour un relecteur, un nouveau mainteneur, ou même le développeur lui-même mais 3 mois après quand il revient sur du code qu'il a écrit pour le changer et s'en rappelle plus, des fois c'est chiant si on comprend pas tout de suite ce que le développeur a voulu faire.
Un exemple (parmi tant d'autres) très simple de ce qu'apporte la verbosité est les paramètres labellisés/nommés par ex. C'est un système que je n'ai vu que sur Ocaml et Ada95, mais je ne connais pas tous les langages du monde et ça existe sûrement ailleurs.
Par exemple, imaginez la fonction "attaque" qui prend 2 paramètres: l'attaquant et l'attaqué. Comment savoir si le premier paramètre est l'attaquant ou l'attaqué, surtout que les 2 params ont le même type (un "personnage")? Dans notre cas, sémantiquement nous ferons souvent plutôt: attaque (attaquant, attaqué). Néanmoins il y a de nombreux cas de fonctions où ce n'est pas si évident (et même là, après tout rien n'interdit à un dév d'estimer que c'est mieux dans l'autre sens!). Donc si on lit le script suivant: attaque (robert, martin). Qui attaque qui? Simple et concis, c'est sûr; clair, sûrement pas. On se reporte à la doc, on perd du temps. Et là c'est un exemple facile, encore une fois (quand t'as une fonction avec 10 paramètres et une sémantique beaucoup moins "vie courante", y a plus rien de clair). Mais les langages qui implémente le nommage de variables donnent la possibilité d'écrire:
attaque (attaquant => robert, attaqué => martin).
Là, c'est réellement clair. Et pourtant c'est sacrément plus verbeux. Mais au moins n'importe quel pecno qui relit le code le comprend immédiatement et on gagne un temps fou.
Donc non concis n'implique absolument pas clair, encore moins réciproquement.-
[^]Re: Langage de "très haut niveau"?
Posté par JoeltheLion () le 25/04/2008 à 12:49. (lien). Évalué à 3.Pour reprendre ton example, robert.attaque(martin), c'est encore plus clair, et plus concis. Le truc le plus clair est forcément concis (même si c'est pas forcément le plus concis. La concision absolue n'est pas un objectif en soi, sur ce point je suis bien d'accord).
-
[^]Re: Langage de "très haut niveau"?
Posté par Maxime (Jabber id, ) le 25/04/2008 à 12:58. (lien). Évalué à 2.Il a volontairement pris un exemple simple... Comment tu aurais fait s'il y avait eu d'autres paramètres ?
-
[^]Re: Langage de "très haut niveau"?
Posté par JoeltheLion () le 25/04/2008 à 13:13. (lien). Évalué à 2.Lis le commentaire de CrEV :) De toutes façons, je n'ai rien contre un peu de verbosité volontaire, pour résoudre une ambiguité. Ce qui est mal, c'est la verbosité imposée par le langage.
-
-
[^]Re: Langage de "très haut niveau"?
Posté par CrEv (page perso, ) le 25/04/2008 à 13:04. (lien). Évalué à 6.c'est surtout que
attaque (attaquant => robert, attaqué => martin)
et
robert.attaque(martin)
ne sont pas du tout la même chose
dans le premier cas, on a un 'attaque' qui est "global" alors que dans le deuxième attaque s'applique à 'robert'
Cet exemple montre justement que le premier est plus verveux et pourtant pas plus clair...
En ce sens, les nomages à la objective C me semblent intéressant. On aurait écrit (en gros) :
[robert attaque:martin]
D'ailleurs, il suffit de rajouter un paramètre pour le voir un peu mieux :
attaque(attaquant => robert, attaqué => martin, arme => machette)
robert.attaque(martin, machette)
[robert attaque:martin avec_arme:machette]
D'ailleurs, on retrouve parfois ce genre de construction en ruby (en jouant sur les hash) :
robert.attaque margin, arme => machette
Tout ça pour dire que je trouve vraiment que les langages concis et bien foutu permettent d'avoir des codes bien plus lisibles, plus compréhensible. Il est d'ailleurs au pire toujours possible de faire du verbeux, du lourd avec un langage concis, mais malheureusement pas le contraire (et les langages trop verbeux ... beurk)
En fait, ce qu'il faut à mon avis ces des langages expressif, et je trouve que ruby en est justement un pas trop mauvais exemple. Il est concis, lisible et suffisament expressif pour avoir des codes lisibles et propres-
[^]Re: Langage de "très haut niveau"?
Posté par _p4_ () le 27/04/2008 à 11:56. (lien). Évalué à 2.La notation la plus claire me semble [robert attaque:martin] car elle met en avant la sémantique de l'expression: [sujet > prédicat > objet ] plus une propriété pour arme>machette. Cette notation se rapproche du langage naturel sans impliquer la compréhension de trop de concepts abstraits. J'aime bien.
-
[^]Re: Langage de "très haut niveau"?
Posté par Sylvain Sauvage () le 28/04/2008 à 22:29. (lien). Évalué à 7.Nuance : ça se rapproche des langages naturels de type SVO (sujet-verbe-objet).
Cet ordre n’est pas universel. Tous les ordres possibles ont au moins un exemple de langue qui l’utilise (cf. Langue_VSO).
Tu préfères cet ordre parce que le français est SVO. Un Japonais, un arabophone, etc., préfèreront un autre ordre.
C’est fou où ça va se cacher les préjugés culturels…-
[^]Re: Langage de "très haut niveau"?
-
-
-
[^]Re: Langage de "très haut niveau"?
Posté par Ontologia (page perso, ) le 27/04/2008 à 13:57. (lien). Évalué à 4.En Lisaac/Smalltalk (syntaxe à mot clé)
robert.attaque martin avec manchette;
-
[^]Re: Langage de "très haut niveau"?
Posté par Mildred (Jabber id, page perso, ) le 28/04/2008 à 01:02. (lien). Évalué à 3.En smalltalk ce serait plutôt:
robert.attaque: martin avec: manchette;
Ce que je trouve plus approprié et moins ambiguë. Cela permet aussi de pouvoir faire référence aux slots ainsi: attaque:avec: au lieu de ce qu'on a en Lisaac: attaque__avec (enfin je crois bien que c'est ça)-
[^]hRe: Langage de "très haut niveau"?
Posté par bluestorm () le 28/04/2008 à 14:56. (lien). Évalué à 1.En haskell :
attaque :: perso -> perso -> resultat
robert `attaque` martin
attaque :: perso -> perso -> arme -> resultat
avec a b = a b
robert `attaque` martin `avec` manchette
[aussi disponible en version avec manchette (robert `attaque` martin), pour une autre définition de avec ou de attaque]
-
-
-
-
-
-
[^]Re: Langage de "très haut niveau"?
Posté par Jean Boussier () le 25/04/2008 à 12:36. (lien). Évalué à 2.Même si clair et concis ne sont pas antinomiques en développement ils sont parfois durs à concilier.
Si je prend l'exemple de Ruby, certains codes biens écrits peuvent se lire quasiment comme un texte en anglais.
A contrario Perl est très concis, mais celui qui me diras qu'il est clair ....
Mais vu tes posts je suppose que tu as un langage préféré à mettre en avant. Alors vas y ne te gène pas.-
[^]Re: Langage de "très haut niveau"?
Posté par alenvers () le 25/04/2008 à 13:31. (lien). Évalué à 3.>A contrario Perl est très concis, mais celui qui me diras qu'il est clair ....
Perl est beaucoup plus claire pour faire le boulot pour lequel, il a été conçu (notamment car je connais aucun autre langage intégrant si bien les expressions régulières).
Pour rappel, PERL ça signifie :
"Practical Extraction and Report Language" ou "langage pratique d'extraction et de génération de rapports"
-
-
[^]Re: Langage de "très haut niveau"?
Posté par Mathieu Stumpf (Jabber id, page perso, ) le 25/04/2008 à 12:37. (lien). Évalué à 2.La clarté et la concision sont deux choses totalement indépendantes.
Un langage plus verbeux peut t'éviter de faire des erreurs subtiles.-
[^]Re: Langage de "très haut niveau"?
Posté par JoeltheLion () le 25/04/2008 à 12:46. (lien). Évalué à 2.La clarté et la concision sont deux choses totalement indépendantes.
Pas du tout. La verbosité pénalise la lisibilité du code (sans parler du temps passer à l'écrire) . Un truc écrit concisement (par concis j'entends peu de symboles, pas peu de charactères. Un nom de variable, même long de 40 charactères ne compte que comme un symbole. Cela est pris en compte en considérant la taille du code zippé, et non le nombre de lignes ou de charactères), si il est bien écrit, sera plus facile à maintenir qu'un truc verbeux équivalent.
En fait, concis n'implique pas clair, mais parfaitement clair implique concis.-
[^]Re: Langage de "très haut niveau"?
Posté par briaeros007 () le 25/04/2008 à 13:39. (lien). Évalué à 1.non, car un code concis peut etre ambigue.
Bref, clair (code lisible, facilement compréhensible et maintenable) et concis (code avec peu de construction, etc...) n'ont strictement rien a voir.
C'est pas en affirmant "si c'est concis alors c'est plus clair qu'un truc verbeux équivalent" que c'est vrai.
Bref affirmation sans fondement n'est que ruine de la discussion :P--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Langage de "très haut niveau"?
Posté par JoeltheLion () le 25/04/2008 à 13:42. (lien). Évalué à 2.Comme je l'ai dit dans un autre commentaire, je n'ai rien contre un peu de verbosité volontaire pour éviter une ambiguité. Ce qui n'a rien à voir avec la verbosité imposée par un langage.
-
[^]Re: Langage de "très haut niveau"?
Posté par briaeros007 () le 25/04/2008 à 13:46. (lien). Évalué à 1.je n'ai rien contre un peu de verbosité volontaire pour éviter une ambiguité
On parle d'un langage qui dois être compréhensible.
Et tu nous dis toi même qu'un langage concis est plus compréhensible.
Et derrière tu nous dis "ben euh non en réalité c'est au developpeur d'expliquer ce qu'il fait finalement"...
Avec de l'ASM c'est concis (très peu de symbole != ) et tu peux le "verbositer" si tu veux. (mettre des commentaires, tout mettre bien dans plein de registres, toussa)
Perso je trouve pas ça très clair pourtant--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Langage de "très haut niveau"?
Posté par JoeltheLion () le 25/04/2008 à 13:49. (lien). Évalué à 4.Un programme en assembleur comptera énormément de symboles même pour faire une chose simple. Bref, tu ne comprends pas ce que je dis.
-
[^]Re: Langage de "très haut niveau"?
Posté par briaeros007 () le 25/04/2008 à 15:10. (lien). Évalué à 0.si je comprend ce que tu dis, mais un programme en assembleur ne comptera pas énormément de symboles pour faire une chose simple.
Tu as les n instructions du proc (tu peux faire des procs avec très peu de symboles), tu aura tes registres (assez peu) et des accès mémoire.
Nombre de symbole différent : peu.*
Nombre d'instructions : beaucoup.
Tu définis toi même qu'une variable comme un seul symbole , je te cite :
Un nom de variable, même long de 40 charactères ne compte que comme un symbole. Cela est pris en compte en considérant la taille du code zippé, et non le nombre de lignes ou de charactères)
Et on peu s'amuser a faire exactement l'inverse un langage avec énormément de symboles (fonction, variables, ...), et extrêmement peu d'instructions.
Et ça ne sera pas non plus beaucoup plus lisible.
Et puis supposons que je comprenne pas (après tout je n'ai pas la science infuse) , pourquoi tu ne m'explique pas ce que tu as voulu dire plutot que "tu comprend pas ce que je dis" ?
Bref, la tu joue ton "grand maître ténébreux" :
- aucune argumentation, juste des trucs parachuté (un code clair est forcément concis. Pas d'explication du pourquoi. Du raisonnement ni rien.
Pas de définition de ce que tu entend par concis ni verbeux, vu que visiblement on a pas du tout la meme définition)
- aucune explication de ce que tu utilise. (Typiquement ce que tu entend par symbole)
- seul contre argument "Tu comprend pas" ou encore "Pas du tout" ou "relis moi bien" (aucune remise en cause ou volontée que l'autre comprenne).
Ca fait cours quand même comme argumentation...--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Langage de "très haut niveau"?
Posté par Guillaume Knispel () le 25/04/2008 à 15:30. (lien). Évalué à 3.Je pense que son "tu ne comprends pas ce que je dis" s'adressait uniquement à la question de l'assembleur, qui effectivement ne permet pas la concision (sauf cas extrèment particulier)
En fait la concision n'est pas tant liée aux nombre de symboles et de paramètres des opérations élémentaires d'un langage qu'à la capacité à spécifier simplement et sans ambiguité des algorithmes résolvants des problèmes complexes. Le cerveau humain étant ce qu'il est, la concision est souvent souhaitable afin de permettre au programmeur d'avoir plus de choses en tête à un instant T, le langage influant à mon avis fortement sur la manière de penser pendant un développement. La possibilité de concision est fortement liée aux abstractions fournies par un langage.
Alors évidemment on peut faire du concis qui ne soit pas particulièrement clair (à la one liner Perl qui descramble du CSS :D ), mais cela n'empeche pas au concis de facilité la clarté lorsqu'il est bien utilisé.-
[^]Re: Langage de "très haut niveau"?
-
[^]Re: Langage de "très haut niveau"?
Posté par briaeros007 () le 25/04/2008 à 16:31. (lien). Évalué à 2.Le grand intérêt avec ta réponse (et je t'en remercie) c'est que tu définie précisement le périmètre que tu étudies.
Toutefois elle ne me satisfait pas totalement, et je vais détaillé pourquoi :
à la capacité à spécifier simplement et sans ambiguité des algorithmes résolvants des problèmes complexes.
1°) Ce n'est pas un critère qui peut vraiment servir à comparer des langages alors.
Les différents types de langages (fonctionnel, objet, ...) sont eux comparé par ça : ils permettent de s'approcher de la logique de l'algorithme afin de simplifier l'implémentation des algorithmes résolvants des problèmes complexes.
2°) Cette capacité différe automatiquement (par application du principe 1) suivants les algorithmes!
un algorithme très simple a développer (prog de généalogie) en prolog peut être une horreur en C ... Et inversement!
Donc le prolog est plus concis que le C, ou inversement. \o/
mais cela n'empeche pas au concis de facilité la clarté lorsqu'il est bien utilisé.
Et idem pour la verbosité ;)--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
-
-
-
-
-
[^]Re: Langage de "très haut niveau"?
Posté par JoeltheLion () le 25/04/2008 à 13:46. (lien). Évalué à 2.C'est pas en affirmant "si c'est concis alors c'est plus clair qu'un truc verbeux équivalent" que c'est vrai.
Relis moi bien, j'ai pas dit ça. Tout ce que je dis, c'est qu'un truc clair est forcément raisonablement concis.-
[^]Re: Langage de "très haut niveau"?
Posté par briaeros007 () le 25/04/2008 à 15:07. (lien). Évalué à 0.Relis moi bien, j'ai pas dit ça.
Vraiment ?
je te cite alors
En fait, concis n'implique pas clair, mais parfaitement clair implique concis.
Donc on a
clair => concis. (c'est ce que tu dis).
Comme verbeux = |(concis) (complémentaire de concis)
Donc clair =/=> verbeux.
Alors effectivement ce n'est pas une équivalence entre clair et concis, mais tu as bien dis que si c'était clair alors c'était concis. Donc si on a le choix entre un truc concis et un truc verbeux , équivalent (dans mon message "truc verbeux équivalent" ) alors le concis est plus clair.--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Langage de "très haut niveau"?
Posté par allcolor (Jabber id, page perso, ) le 25/04/2008 à 16:30. (lien). Évalué à 2.Donc si on a le choix entre un truc concis et un truc verbeux , équivalent (dans mon message "truc verbeux équivalent" ) alors le concis est plus clair.
Non il n'a pas dit ça, il a dit que si c'est clair c'est concis, ça n'implique pas qu'un truc concis est forcément clair... A => B != B=> A--
All those moments will be lost in time, like tears in the rain.-
[^]Re: Langage de "très haut niveau"?
Posté par briaeros007 () le 25/04/2008 à 16:40. (lien). Évalué à 1.personne vois le mot "équivalent" que j'ai marqué 3 fois ?
et personne ne vois "Alors effectivement ce n'est pas une équivalence entre clair et concis," ?--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Langage de "très haut niveau"?
Posté par JoeltheLion () le 26/04/2008 à 15:01. (lien). Évalué à 2.Le equivalent voulait dire, "aussi bien écrit". Mais bon, c'était pas très clair :)
-
-
-
-
-
-
-
-
-
[^]Re: Langage de "très haut niveau"?
Posté par Guillaume Knispel () le 25/04/2008 à 15:12. (lien). Évalué à 4.Je suis plutôt d'accord. Néanmoins la verbosité n'est pas complètement décorrelée du niveau du langage, surtout d'un point de vue pratique : il est beaucoup plus difficile (généralement...) d'être concis en utilisant un langage de bas niveau, et les abstractions fournies par les langages de haut niveau n'auraient en pratique pas beaucoup d'interêt s'il fallait au final écrire 10x plus de code qu'en ASM (sauf si on ne documente pas son code ASM :)
Disons que si les abstractions ne permettent pas la concision, elles sont moins intéressantes en terme de productivité.
En ce qui concerne les bench d'alioth, les programmes sont très courts et à mon avis on ne peut pas vraiment estimer et comparer les concisions des langages sans prendre en compte certaines caractéristiques comme le niveau du typage. Sans compter que le paradigme peut jouer énormement selon le type de problème posé (penser à du backtracking en logique versus en impératif ... :)
-
[^]Re: Langage de "très haut niveau"?
Posté par Sylvain Sauvage () le 25/04/2008 à 18:09. (lien). Évalué à 10.Pour certains, les langages de haut niveau sont ceux dont les livres sont sur l’étagère du haut, la poussiéreuse.
Pour certains, les langages de bas niveau sont ceux dont les livres servent à caler la bibliothèque.
-
-
-
-
[^]Re: Langage de "très haut niveau"?
Posté par Ontologia (page perso, ) le 25/04/2008 à 10:57. (lien). Évalué à 4.C'est intéressant comme remarque..
C'est vrai que quand on regarde le code ruby, c'est beaucoup plus concis.
Lisaac est effectivement "encore" trop verbeux.
Mais l'avantage dans tous cela, c'est que ça peut facilement changer : quasiment toutes les structures de contrôles sont définis en librairie, et il suffira d'avoir les même fonctions que ruby dispose dans sa librairie, pour se retrouver avec un code à peine plus gros.
Il y a eu un gros travail de réflexions là dessus, de la part de Mildre et votre serviteur : pas mal de foreach ont été implémentés, avec différentes variantes. Il existe aussi des map/fold/filter.
Les utiliser ne devrait pas couter en performances, vu que l'on retombe sur des boucles classiques.
Il y aussi beaucoup de choses à implémenter : quand je regarde fasta par exemple, il y a des fonctions slices, join, etc... qu'on a pas encore, et ce genre de fonctions racourcissent le code...
Bref, Lisaac est bien un langage de haut niveau, et comme Ruby dont il est assez proche, tout est une question de libraire.-
[^]Re: Langage de "très haut niveau"?
Posté par JoeltheLion () le 25/04/2008 à 11:07. (lien). Évalué à 2.
Mais l'avantage dans tous cela, c'est que ça peut facilement changer : quasiment toutes les structures de contrôles sont définis en librairie, et il suffira d'avoir les même fonctions que ruby dispose dans sa librairie, pour se retrouver avec un code à peine plus gros.
Tout est dans le "facilement". C'est probablement facile techniquement, mais concevoir une bonne librairie standard est un challenge, et c'est très important pour la réussite du langage. J'aimerais beaucoup essayer Lisaac, mais en l'absence d'une bonne librairie standard (jette un coup d'oeil à celle de python (au sens large, ça inclut les types inclus dans le langage, tels que {}, [], set, frozenset, string, etc.) pour voir ce que je veux dire.), ce langage n'a pas d'intérêt pour moi.
La librairie doit être bien fournie, sans superflu, et être extrêmement cohérente pour que son utilisation soit intuitive et facile. Pas si évident que ça à mon avis :)-
[^]Re: Langage de "très haut niveau"?
Posté par Ontologia (page perso, ) le 25/04/2008 à 12:06. (lien). Évalué à 5.Je confirme, c'est extrêmement difficile.
Il faut savoir que la librarie de Lisaac, est la copie conforme de la librairie SmartEiffel pour tous les types de bases, à quelques exceptions près.
Elle reprend donc toute l'expérience de celle de SmartEiffel, qui est elle même parait-il basée sur celle de smalltalk-80.
Pour le moment, elle recouvre un minimum :
- entiers, structures de contrôle, IO, chaines
- conteneurs de bases (collections, ensembles, hashtables)
- accès fichier
- Quelques formats de fichiers (bmp, ai, tga)
- Une gui totalement native, qui s'améliore de jour en jour, mais encore jeune.
- Un super binding open-gl (merci Damien), qui gère plein de choses, lit les md2 de quake...
- Un binding lua
Notons qu'avec tout ça, on peut d'ors et déjà faire un jeu 3D en Lisaac... sans le son.
En passant, citons d'autre outils :
- Un player mpeg2
- Un compilateur de compilateur SLR (Sanglier)
- Une lib freetype qui marchait il y a quelques années, et qu'il faut remettre au gout du jour.
Il nous manque pas mal de choses (réseau, regexp, gestion du temps, maths avancé, logging, xml, html, ...).-
[^]Re: Langage de "très haut niveau"?
Posté par titi toto (Jabber id, ) le 25/04/2008 à 19:19. (lien). Évalué à 4.- Quelques formats de fichiers (bmp, ai, tga)
Que des formats que tout le monde utilise tous les jours, quoi..-
[^]Re: Langage de "très haut niveau"?
Posté par Mildred (Jabber id, page perso, ) le 25/04/2008 à 23:43. (lien). Évalué à 4.Sans compter que le code qui gère ça n'a pas l'air bien propre ... il me semble que la dernière fois, j'avais vu un slot 'open_bmp' dans ABSTRACT_ENTRY (représente un élément du système de fichiers) ...
C'est là: http://svn.gna.org/viewcvs/isaac/trunk/lisaac/lib/file_syste(...)
Je pense que la lib mériterait d'être revue à fond. Mais il y a d'autres choses plus urgentes à faire.
-
-
-
-
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.