Tout le monde s'en fout, mais cela fait des années que je suis persuadé qu'un langage de très haut niveau à plus de potentiel d'optimisation qu'un langage aussi bas niveau que le C. Et pourtant dés que l'on veut de la performance, on pense C.
C'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 !
Journal Lisaac plus rapide que le C !
25
avr.
2008
# ...
Posté par M . Évalué à 3.
Et puis bon le pb de shootout, c'est que les "tests" ne sont pas forcement représentatif.
[^] # Re: ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
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.
"La première sécurité est la liberté"
[^] # Re: ...
Posté par M . Évalué à 10.
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...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ...
Posté par Philippe F (site web personnel) . Évalué à 3.
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 (site web personnel) . Évalué à 3.
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
Posté par yellowiscool . Évalué à 10.
Donc Lisaac n'est pas plus rapide que le C, puisque c'est du C.
Envoyé depuis mon lapin.
[^] # Re: Hum
Posté par Nicolas Boulay (site web personnel) . Évalué à 9.
"La première sécurité est la liberté"
[^] # Re: Hum
Posté par yellowiscool . Évalué à 0.
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.
Envoyé depuis mon lapin.
[^] # Re: Hum
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
"La première sécurité est la liberté"
[^] # Re: Hum
Posté par psychoslave__ (site web personnel) . Évalué à 10.
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 (site web personnel) . Évalué à 4.
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.
"La première sécurité est la liberté"
[^] # Re: Hum
Posté par 2PetitsVerres . Évalué à 9.
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.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Hum
Posté par calandoa . Évalué à 1.
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 . Évalué à 2.
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.
[^] # Re: Hum
Posté par Aldoo . Évalué à 3.
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 . Évalué à 0.
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 . Évalué à 2.
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 . Évalué à 6.
[^] # Re: Hum
Posté par outs . Évalué à 4.
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 . Évalué à 2.
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
Posté par mdlh . Évalué à 1.
[^] # Re: Hum
Posté par 태 (site web personnel) . Évalué à 2.
[^] # Re: Hum
Posté par imalip . Évalué à 2.
[^] # Re: Hum
Posté par Aldoo . Évalué à 2.
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 . Évalué à 2.
C'est pas de l'assembleur d'ailleurs, ce sont des octets.
[^] # Re: Hum
Posté par auve . Évalué à 6.
[^] # Re: Hum
Posté par Maxime (site web personnel) . Évalué à 3.
Bon ok, on risque de perdre en lisibilité toussa mais c'est un autre problème.
[^] # Re: Hum
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: Hum
Posté par briaeros007 . Évalué à 4.
Comme ça, le serpent se mord bien la queue :P
[^] # Re: Hum
Posté par Maxime (site web personnel) . Évalué à 9.
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 Guillaume Denry (site web personnel) . Évalué à 7.
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 Dr BG (site web personnel) . Évalué à 8.
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 Dr BG (site web personnel) . Évalué à 2.
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 (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Hum
Posté par Obsidian . Évalué à 1.
[^] # Re: Hum
Posté par Maxime (site web personnel) . Évalué à 6.
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Hum
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
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.
"La première sécurité est la liberté"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Hum
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Hum
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Hum
Posté par Ontologia (site web personnel) . Évalué à 3.
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..
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Hum
Posté par Ontologia (site web personnel) . Évalué à 2.
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.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Hum
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
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...
"La première sécurité est la liberté"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Hum
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
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 ?
"La première sécurité est la liberté"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Hum
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
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.
"La première sécurité est la liberté"
[^] # Re: Hum
Posté par auve . Évalué à 3.
Du compilateur (dialecte ?) SmartEiffel plutôt, non ? Pour Eiffel c'est Bertrand Meyer si je ne m'abuse.
[^] # Re: Hum
Posté par Moogle . Évalué à 4.
(et si on pouvait re-optimiser le C déjà optimisé, quelle classe)
[^] # Re: Hum
Posté par Maxime (site web personnel) . Évalué à 2.
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 . Évalué à 2.
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 (site web personnel) . Évalué à 3.
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 . Évalué à 2.
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
Posté par IsNotGood . Évalué à 3.
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 feth . Évalué à 8.
[0] Utilisateur:Haypo/MultiDeskOS
[^] # Re: Miloud
Posté par IsNotGood . Évalué à 2.
Les ambitions sont modestes. Pas de marketing, pas de com (sauf technique), pas de tune, pas de pub, que le bonheur de l'humanité.
[^] # Re: Miloud
Posté par Victor STINNER (site web personnel) . Évalué à 5.
[^] # Re: Miloud
Posté par psychoslave__ (site web personnel) . Évalué à 2.
[^] # Re: Miloud
Posté par Victor STINNER (site web personnel) . Évalué à 2.
# Les benchmarks c'est du bullshit
Posté par feth . Évalué à 4.
[^] # Re: Les benchmarks c'est du bullshit
Posté par auve . Évalué à 5.
# Langage de "très haut niveau"?
Posté par JoeltheLion (site web personnel) . Évalué à 6.
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 psychoslave__ (site web personnel) . Évalué à 1.
[^] # Re: Langage de "très haut niveau"?
Posté par JoeltheLion (site web personnel) . Évalué à 3.
[^] # Re: Langage de "très haut niveau"?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 9.
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.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Langage de "très haut niveau"?
Posté par JoeltheLion (site web personnel) . Évalué à 2.
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 (site web personnel, Mastodon) . Évalué à 8.
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.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Langage de "très haut niveau"?
Posté par JoeltheLion (site web personnel) . Évalué à 3.
[^] # Re: Langage de "très haut niveau"?
Posté par Maxime (site web personnel) . Évalué à 2.
[^] # Re: Langage de "très haut niveau"?
Posté par JoeltheLion (site web personnel) . Évalué à 2.
[^] # Re: Langage de "très haut niveau"?
Posté par CrEv (site web personnel) . Évalué à 6.
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 => machetteTout ç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_ . Évalué à 2.
[^] # Re: Langage de "très haut niveau"?
Posté par Sylvain Sauvage . Évalué à 7.
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"?
Posté par _p4_ . Évalué à 3.
Il s'agit plutôt d'ignorance que de préjugé, je l'ai perçu comme ça de prime abord, ta remarque est juste.
[^] # Re: Langage de "très haut niveau"?
Posté par Ontologia (site web personnel) . Évalué à 4.
robert.attaque martin avec manchette;
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Langage de "très haut niveau"?
Posté par Mildred (site web personnel) . Évalué à 3.
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 gasche . Évalué à 1.
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 B . Évalué à 2.
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Langage de "très haut niveau"?
Posté par psychoslave__ (site web personnel) . Évalué à 2.
Un langage plus verbeux peut t'éviter de faire des erreurs subtiles.
[^] # Re: Langage de "très haut niveau"?
Posté par JoeltheLion (site web personnel) . Évalué à 2.
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 . Évalué à 1.
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
[^] # Re: Langage de "très haut niveau"?
Posté par JoeltheLion (site web personnel) . Évalué à 2.
[^] # Re: Langage de "très haut niveau"?
Posté par briaeros007 . Évalué à 1.
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
[^] # Re: Langage de "très haut niveau"?
Posté par JoeltheLion (site web personnel) . Évalué à 4.
[^] # Re: Langage de "très haut niveau"?
Posté par briaeros007 . Évalué à 0.
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...
[^] # Re: Langage de "très haut niveau"?
Posté par Guillaume Knispel . Évalué à 3.
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"?
Posté par JoeltheLion (site web personnel) . Évalué à 2.
[^] # Re: Langage de "très haut niveau"?
Posté par briaeros007 . Évalué à 2.
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é ;)
[^] # Re: Langage de "très haut niveau"?
Posté par JoeltheLion (site web personnel) . Évalué à 2.
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 . Évalué à 0.
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.
[^] # Re: Langage de "très haut niveau"?
Posté par allcolor (site web personnel) . É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
[^] # Re: Langage de "très haut niveau"?
Posté par briaeros007 . Évalué à 1.
et personne ne vois "Alors effectivement ce n'est pas une équivalence entre clair et concis," ?
[^] # Re: Langage de "très haut niveau"?
Posté par JoeltheLion (site web personnel) . Évalué à 2.
[^] # Re: Langage de "très haut niveau"?
Posté par Guillaume Knispel . Évalué à 4.
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 . Évalué à 10.
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 (site web personnel) . Évalué à 4.
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.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Langage de "très haut niveau"?
Posté par JoeltheLion (site web personnel) . É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 (site web personnel) . Évalué à 5.
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, ...).
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Langage de "très haut niveau"?
Posté par titi toto . Évalué à 4.
Que des formats que tout le monde utilise tous les jours, quoi..
[^] # Re: Langage de "très haut niveau"?
Posté par Mildred (site web personnel) . Évalué à 4.
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.
[^] # Re: Langage de "très haut niveau"?
Posté par Ontologia (site web personnel) . Évalué à 4.
Bref, en fait, tout ce qui ne vient pas d'Eiffel...
Même la Gui, qui devient vraiment intéressante pourrait être simplifiée.
Après vu tout le code que tu produis en lisaac, tu aurais peut être des critiques sur la core library ;)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Langage de "très haut niveau"?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
# Tout mauvais...
Posté par GPL . Évalué à 5.
En effet, la RAM est "loin" du CPU. C'est à dire qu'un algo correcte prend en compte le fait que la RAM est "loin" et qu'en fait il doit considérer les différents niveaux de la mémoire cache.
Histoire de compliquer la tâche encore plus, nos CPU sont maintenant mutli-cœurs et embarquent un contrôleur de mémoire (pour les design modernes, Intel est à la bourre mais AMD est à l'heure sur ce sujet). Donc pour les algo vraiment intensifs il s'agit de considérer cette dimension (et je ne parle pas des pages de mémoire virtuelle and co).
Le lead de la glibc Ulrich Drepper a fait un bon papier qui illustre par la pratique une partie de ce que je viens de dire:
http://lwn.net/Articles/259710/
Les architectures sont tellement comlexes aujourd'hui qu'un des seuls moyens d'avoir un bon algo dans un context technique bien précis, c'est d'utiliser les outils d'instrumentation.
Donc à vos valgrind et oprofile.
[^] # oprofile?
Posté par Zenitram (site web personnel) . Évalué à 2.
Perso, j'utilise Valgrind pour les memory leaks et utilisation de blocs non initialisés (bonne bête celui-la, il m'a été d'une grand aide, un bonheur pour trouver des petits bugs chiants...), et gprof pour le profiling (très facile, une option pour gcc, une commande ensuite pour créer le fichier lisible).
Est-ce que oprofile fait la même chose que gprof? si oui, il est meilleur?
A première vue, il a l'air plus costaud à manipuler, donc je me demande si ça vaut le coup que je regarde plus en profondeur son utilisation.
[^] # Re: oprofile?
Posté par cedric . Évalué à 4.
D'ailleur dans la meme collection massif pour savoir quelle fonction alloue le plus de ram ou cachegrind pour savoir qui fait le plus de boulette dans le cache c'est vraiment terrible. Si tu n'utilises que l'outil memcheck de valgrind, tu n'as encore rien decouvert de sa puissance. Et ils enterent tous gprof. Je te conseille d'essayer.
[^] # Re: oprofile?
Posté par GPL . Évalué à 3.
Cela dit, ayé, latency top est dans Linux. J'avoue que j'ai pas testé, mais si quelqu'un a déjà essayé de repérer des goulots d'étranglement avec, et bien qu'il nous fasse part de son expérience!
[^] # Re: Tout mauvais...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Il y a des tas d'optimisation inaccessible en C sans casser la sémantique, par exemple, sur le layout mémoire. Tu n'as pas le droit de toucher à l'ordre des champs d'un struct en C, Lisaac peut le faire. (je crois qu'il y a une option pour le faire maintenant dans gcc mais cela peut casser des programmes)
Un langage de haut niveau permet mieux d'exprimer ce que le codeur veut faire ce qui donne suffisamment d'information au compilateur pour générer le meilleur code possible.
"La première sécurité est la liberté"
[^] # Re: Tout mauvais...
Posté par mdlh . Évalué à 5.
Un algorithme ecrit sur papier permet de mieux expliquer ce que l'algorithmicien veut faire, ce qui donne suffisement d'information au developeur pour ecrire le meilleur code possible, incluant le choix des des structures de donnees.
Pour avoir travaille pendant plus de 5 ans dans le domaine de l'optimisation de code, mon experiece m'a montre que meme un algorithme ecrit dans un language de haut niveau ne retranscrit pas necessairement exactement ce que l'algorithme etait cense faire. La retranscription en code inclue parfois de devoir utiliser des fonctions de bases du language qui ont parfois beaucoup trop de semantique associe et de ce fait limite les optimisations possibles.
Idem pour la documentation du choix de l'implementation. On arrive a determiner par les commentaires ce que le developeur a voulu faire, mais on ne sait rien sur ce qu'il n'a pas fait: Quels etaient les autres solutions envisagees et pourquoi ont-elles ete ecartees? Ca permet de ne pas forcement se retapper tout le boulot de verification, ou meme de se rendre compte que le developeur a l'origine n'a pas tenu compte de quelque chose.
[^] # Re: Tout mauvais...
Posté par M . Évalué à 2.
# Ton titre se démonte en 1 minute top chrono.
Posté par Zenitram (site web personnel) . Évalué à 2.
Si tu suis un raisonnement scientifique (logique), Lisaac ne peut pas, par conception, être plus rapide que du C.
En effet, en suivant un simple raisonnement logique, un code C au minimum (le code généré par Lisaac), sera aussi rapide que du code Lisaac.
Il existera toujours un code C aussi rapide qu'un code Lisaac pour la même fonctionnalité.
CQFD.
Tu peux dire que tu peux coder plus rapidement du code rapide avec Lisaac, tu ne peux en aucun cas dire que Lisaac est plus rapide que le C.
[^] # Re: Ton titre se démonte en 1 minute top chrono.
Posté par JoeltheLion (site web personnel) . Évalué à 2.
[^] # Re: Ton titre se démonte en 1 minute top chrono.
Posté par Zenitram (site web personnel) . Évalué à 2.
Tu peux dire "par un humain dans le même laps de temps" peut-être, mais tu ne peux pas dire "Lisaac est plus rapide que du code C écrit par un humain" vu qu'un humain sait écrire du C, sait réfléchir (Lisaac implémente des algo écrit par des humains non? Donc les humains connaissent les algo C... Lisaac ne fait qu'automatiser une tache très fastidieuse)
[^] # Re: Ton titre se démonte en 1 minute top chrono.
Posté par JoeltheLion (site web personnel) . Évalué à 4.
que?
[^] # Re: Ton titre se démonte en 1 minute top chrono.
Posté par Thomas Debesse (site web personnel) . Évalué à 10.
Ça doit être un peu comme maintenir un code après passage au préprocesseur, ou pire un code décompilé.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Ton titre se démonte en 1 minute top chrono.
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
"Si tu suis un raisonnement scientifique (logique), Lisaac ne peut pas, par conception, être plus rapide que du C."
Et donc par conception, du code C ne peut pas être plus rapide que de l'assembleur ? Et par extension, aucun langage ne peut être plus rapide que l'assembleur ?
Il est évident que je parle pour un temps de développement "borné". "Plus rapide" n'a de sens que dans ce cadre.
"La première sécurité est la liberté"
[^] # Re: Ton titre se démonte en 1 minute top chrono.
Posté par Zenitram (site web personnel) . Évalué à 1.
Oui, et je ne vois pas ce qui te choque.
Un langage, pas sa façon de voir les choses, va imposer des limitations par rapport au code assembleur (langue maternelle du CPU)
Un code assembleur sera potentiellement toujours plus rapide que du C, et du C ne sera jamais plus rapide que de l'assembleur, tout bêtement parce que tu ne peux pas faire tout code assembleur avec du C. Tu as x milliards de façons de faire du code en Assembleur, tu en a moins que x milliards en C.
Lisaac produit du C, donc reprend obligatoirement la limitation du C, en plus d'ajouter les siennes.
Donc Lisaac <= C <= Assembleur.
C'est scientifique, je ne vois pas ce qui te pose problème...
Il est évident que je parle pour un temps de développement "borné".
As-tu fixé les bornes? Sont-elles acceptée par tous? Est-ce que tu as fait des tests sur les autres langages avec les mêmes bornes? Dire des "vérités" brutes, c'est pas si évident, tu généralises à partir d'un exemple, on peut te donner un autre exemple ou C est plus rapide que Lisaac (genre void main(){}) et dire "Lisaac ca rame.
Tu balances une truc super-général, avec quelques tests, désolé mais ça n'a rien de scientifique, ça fait la personne qui veut prouver quelque chose et qui va biaiser son étude pour arriver à la conclusion qui l'arrange...
[^] # Re: Ton titre se démonte en 1 minute top chrono.
Posté par briaeros007 . Évalué à -1.
Sachant que tu peux mettre de l'asm dans du code C, si!
/me sort en courant
Sinon plus sérieusement, tu nous dis que C est injectif dans l'ASM (tous le c est contenu dans l'asm) , mais pas surjectif (tous les élements de l'asm a au moins un antécédents dans c). Ansi donc C n'est pas bijectif dans l'asm.
Maintenant reste plus qu'a le prouver :P
As-tu fixé les bornes? Sont-elles acceptée par tous?
Je pense que si tu dis que n'importe que programme doit pouvoir etre terminé dans les 100 ans, les bornes sont accepté par tous.
[^] # Re: Ton titre se démonte en 1 minute top chrono.
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
C'est faux ça. J'ai souvent vu des instructions qui sont en fait des macros ou des concatenations d'instruction (par exemple pour faire un saut absolue en ARM, le call est transformé en call indirect qui va chercher l'adresse de saut un peu plus loin en mémoire).
C'est encore un poil au dessus du binaire de base.
Tu balances une truc super-général, avec quelques tests, désolé mais ça n'a rien de scientifique, ça fait la personne qui veut prouver quelque chose et qui va biaiser son étude pour arriver à la conclusion qui l'arrange...
Espèce de rabat-joie.
Ne t'inquiète pas je sais très bien ce que veut dire ce bench et ce qu'il ne veut pas dire.
Mais si il y a 2 ans tu aurais dit qu'un langage à prototype qui est encore plus haut niveau que Eiffel aurait des performances proches du C, tu aurais été mis à l'asile.
As-tu fixé les bornes? Sont-elles acceptée par tous? Est-ce que tu as fait des tests sur les autres langages avec les mêmes bornes? Dire des "vérités" brutes, c'est pas si évident, tu généralises à partir d'un exemple, on peut te donner un autre exemple ou C est plus rapide que Lisaac (genre void main(){}) et dire "Lisaac ca rame.
Je fais pas mal d'optimisation pour m'amuser. Je suis sûr que je peux battre Lisaac, car c'est une partie de mes idées qui sont à la base de certaine optimisation. Mais entre prendre un code clean, pour le transformer en truc immonde 2 fois plus rapide, il y a des heures de boulot. Et encore, certaine optimisation nécessite d'avoir la connaissance adéquate, cela n'est pas à la porté de tout codeur.
"La première sécurité est la liberté"
[^] # Re: Ton titre se démonte en 1 minute top chrono.
Posté par Zenitram (site web personnel) . Évalué à 3.
Bah... tu sais, j'ai déjà tellement entendu que le C++ c'est plus lent que le C car plus haut niveau (alors que bon, à utilisation identique, c'est pareil... Un peu comme Lisaac, le C++ est olus facile à maintenir que le C :-D ), voir Java, qui n'a pas grand chose à voir avec le C mais qu'on dit super-lent (alors que non, correctement utilisé ça se bat bien), que je ne m'intéresse pas au "niveau" d'un langage.
Je ne suis pas d'accord avec toi donc pour dire que plus le langage est haut niveau, plus il est lent. (Ca va dans ton sens ;-) ).
Mais je reste stupéfait quand je lis "Le langage A crachant du langage B est plus rapide que le langage B"
Non, et non, ça ne peut pas marcher, rien qu'intellectuellement.
Et c'est dommage de se "battre" sur ce terrain, l'avantage d'un langage haut-niveau n'étant pas la mesure de sa rapidité (un langage qui pour faire la même chose rame 10x plus n'est pas forcement un mauvais langage, c'est surtout le compilo qui est merdique).
Car au final, tu as dis "Lisaac est plus rapide que le C sur tel test", en comparant quoi? Des compilos. Tu a comparé le compilo Lisaac au compilo C que tu veux, alors que suivant le compilo, suivant sa configuration, ça peut changer sa perf.
Dire que tel langage est plus rapide que tel autre est une grosse connerie : ce n'est pas le langage qui fait forcement la vitesse, mais le compilo.
Bref, c'est surtout le titre du journal qui m'a fait bondir, tu l'auras compris.
[^] # Re: Ton titre se démonte en 1 minute top chrono.
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Non, et non, ça ne peut pas marcher, rien qu'intellectuellement."
Cela démontre juste qu'intellectulement, tu n'as rien compris à la compilation, voir même à l'intérêt d'un langage de programmation (qui doit aider à gérer les problèmes de maintenabilité et d'absence d'erreur).
Et on revient à la débilité où on compare C et l'assembleur.
Or le C n'est qu'un assembleur un poil plus évolué.
l'avantage d'un langage haut-niveau n'étant pas la mesure de sa rapidité (un langage qui pour faire la même chose rame 10x plus n'est pas forcement un mauvais langage, c'est surtout le compilo qui est merdique).
Et pourtant, tous les langages de haut niveau sont plus lent que C (jusqu'à présent). On connait tous les avantages du haut niveau si en plus on a la vitesse, c'est encore mieux...
"Dire que tel langage est plus rapide que tel autre est une grosse connerie : ce n'est pas le langage qui fait forcement la vitesse, mais le compilo."
Sauf que c'est simplement faux. Faire un compilo rapide pour perl ou python est super difficile, car le langage ne le permet pas au contraire de lisaac. C montre aussi ces limites (contrainte sur le structure de donné en mémoire par exemple).
Pour un effort identique, un compilo ne te donnera pas du tout le même résultat selon le langage. Dans le cas de génération du C, tu peux en plus utiliser toutes les optimisation bas niveau du compilo C.
"La première sécurité est la liberté"
[^] # Re: Ton titre se démonte en 1 minute top chrono.
Posté par psychoslave__ (site web personnel) . Évalué à 2.
Moi je suis sûr que madame michu elle le pense toujours. :)
[^] # Re: Ton titre se démonte en 1 minute top chrono.
Posté par Jean B . Évalué à 4.
Par maître Capello sans doute.
[^] # Re: Ton titre se démonte en 1 minute top chrono.
Posté par khivapia . Évalué à 2.
Et encore on n'a pas parlé de la distribution des données d'entrées, qui joue fortement sur les performances des programmes quand on les compare.
En effet, définissons un programme comme suit : il prend des données dans une certaine zone de mémoire (comprenant éventuellement les données aléatoires qu'il aura à récupérer, sans perdre de généralité). Il fait ensuite un traitement déterministe et sort les résultats dans une certaine zone de la mémoire (bon c'est presque une machine de Turing notre programme, ami lecteur sauras-tu retrouver la différence ? ).
Si on prend le compilateur théorique suivant, on aura parfaite égalité de vitesse dans les programmes entre tous les langages :
1) il prend le code initial (du C, du Lisaac, etc.)
2) il génère tous les codes assembleurs qui réalisent la même opération (données en mémoire -> sortie en mémoire). C'est possible en temps fini (il suffit de tout énumérer) mais c'est long (bon j'ai précisé que c'était un compilateur théorique, hein ;-) )
3) le compilateur lance chaque programme sur toutes les entrées possibles (pareil, c'est encore plus long ;-) )
4) il choisit à chaque fois le programme le plus rapide pour effectuer les tâches.
Alors l'assembleur, écrit par un humain, sera forcément plus lent ou au mieux aussi rapide que le C/Lisaac/tout ce que vous voulez.
ensuite si on veut chipoter sur les données on se met d'accord sur une distribution de probabilité des données d'entrées et sur la façon de calculer la meilleure vitesse (vitesse moyenne sur les entrées ? vitesse dans le pire cas ? ... ? ) et on recommence le compilateur précédent, en choisissant le programme le plus rapide.
[^] # Re: Ton titre se démonte en 1 minute top chrono.
Posté par mdlh . Évalué à 1.
Quelque soit le compilateur, il se doit de retranscrire ce que tu as exprime en utilisant un langage. Mais parfois le langage manque de nuance dans un cas precis et tu lui dit plus que ce que tu penses, volontairement ou pas.
[^] # Re: Ton titre se démonte en 1 minute top chrono.
Posté par khivapia . Évalué à 2.
L'essentiel est bien qu'étant donné une entrée le calcul soit le même que celui spécifié par le langage, c'est en ce sens là seulement que le compilateur se doit de retranscrire ce qu'on a exprimé.
Le langage initial n'étant pas exécutable directement sur une machine, il n'est qu'une indication de ce qui doit être fait, pas une description exacte.
[^] # Re: Ton titre se démonte en 1 minute top chrono.
Posté par mdlh . Évalué à 0.
L'essentiel est bien qu'étant donné une entrée le calcul soit le même que celui spécifié par le langage".
Je parlais de l'expression du resultat final: Si je ne peux pas decrire ce que je veux exactement, par exemple je desire obtenir un resultat satisfaisant certaintes contraintes que le langage ne me permet pas d'exprimer. Je me trouve donc dans l'obligation d'ajouter certaines contraintes de tel sorte que le resultat soit satisfaisant, mais avec un cout supplementaire de calcul.
[^] # Re: Ton titre se démonte en 1 minute top chrono.
Posté par khivapia . Évalué à 2.
(surtout qu'on peut écrire un simulateur de processeur, un interpréteur d'assembleur en fait, en n'importe quel langage)
[^] # Re: Ton titre se démonte en 1 minute top chrono.
Posté par mdlh . Évalué à 1.
En effet comme tu le dis, on peut simuler un processeur. Donc on a une equivalence dans la theorie, sous reserve de resource illimitee, que l'on reste dans le calculable, et que le compilo soit capable de non pas optimiser le simulateur, mais le couple (simulateur, code). Mais avec tout ce que ton compilo est capable de faire, pourquoi pas...
Apres y avoir repense, tu as raison. Si je devais re-repondre, je dirais: Le raisonnement est correct, mais la situation initiale reste a prouver.
[^] # Re: Ton titre se démonte en 1 minute top chrono.
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
En fait ce qu'on peut-dire aussi c'est que Lisaac dépend du compilateur C, et donc qu'un code en lisaac ne peut donner un programme plus rapide que ce que peut donner ce même compilateur C, quelque soit le langage à la base et les étapes de transcription.
Je pense donc que Lisaac est plus dépendant du compilateur C que du langage C lui même (qui est assez bas-niveau pour pouvoir être torturé dans tout les sens).
En fait c'est bien là où pèche la rhétorique : c'est qu'il doit être possible de faire à peu près tout en C (sans prendre en compte les critères de lisibilité, clarté, concision, maintenabilité...) donc forcément tout code, même s'il ne passait pas par l'étape C à la compilation comme Lisaac, pourrait avoir un équivalent en C aussi rapide que lui.
Conclusion : améliorons toujours gcc. :)
Je pense qu'il faut voir le code C produit par Lisaac comme une étape de précompilation : ce n'est déjà plus le source. Écrire un programme en C aussi rapide qu'un programme en C pourrait revenir à programmer un programme directement en binaire avec éditions de liens et tout et tout, et qui soit aussi rapide que celui en assembleur. c'est possible, certains l'ont fait peut-être, mais bon...
D'ailleurs, si j'ai bien, deux langages turing-complets doivent pouvoir être retranscrit dans l'un ou dans l'autres des langages avec un comportement final identique, à l'instruction près, où alors ils ne seraient pas turing-complets. Donc il est possible d'écrire un code Lisaac qui soit aussi lent qu'un code C. (qui veut écrire le compilateur ? XD).
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Ton titre se démonte en 1 minute top chrono.
Posté par Guillaume Knispel . Évalué à 5.
Un compilateur ne produit pas forcément de l'assembleur. Le compilateur Lisaac est un compilateur de plein droit.
Et effectivement le code C produit n'est plus le source, et si quelqu'un s'amusait à rajouter des blobs en C issues d'une compilation Lisaac dans la distribution d'un programme GPL et qu'il distriburait le résultat sans fournir les sources Lisaac, il violerait clairement la GPL.
[^] # Re: Ton titre se démonte en 1 minute top chrono.
Posté par Mildred (site web personnel) . Évalué à 2.
[^] # Re: Ton titre se démonte en 1 minute top chrono.
Posté par outs . Évalué à 3.
C'est : un programme généré par un compilateur (ou une suite de compilateur) à partir d'un code source redigé dans un langage, qui peut être rapide ou non à délivrer un résultat pour une certaine entrée.
sachant que chacun de ces élément influence la vitesse finale...
En plus lisaac est a la fois le nom du compilateur et du langage, ce qui rajoute encore à la confusion.
Pauvres mouches ...
# Prêt à être utilisé par les masses?
Posté par Maclag . Évalué à 3.
Et c'est du haut de ces maigres connaissances que je vais poser la question qui tue:
- Lisaac est-il prêt à être utilisé par les développeurs? (genre on peut faire des progs avec python, perl, tout ça! Et Lisaac?)
- Si réponse négative, les éléments manquants ne risquent-ils pas de venir foutre par terre ce joli petit bench?
En tout cas chapeau à Sonntag parce que ça a l'air costaud comme truc!
[^] # Re: Prêt à être utilisé par les masses?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Tu peux regarder dans les exemples. Il y a même un petit tetris.
"La première sécurité est la liberté"
[^] # Re: Prêt à être utilisé par les masses?
Posté par Ontologia (site web personnel) . Évalué à 3.
Bref, de quoi faire un jeu... sans son, et sans réseau.
Mais avec de bonnes perfs ;-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Prêt à être utilisé par les masses?
Posté par Mildred (site web personnel) . Évalué à 4.
Pourquoi ?
D'une part, il n'y a pas de gestion correcte des erreurs (et la lib standard n'est pas très jolie). On a les contrats (formidable) mais ils ne permettent pas de gérer toutes les erreurs. Comment gérer par exemple une erreur d'allocation mémoire.
Pour le moment, si une allocation échoue, on a droit à un exit(1) ... Je n'aime pas trop.
D'autre part, le temsp de compilation est exponentiel. De ce coté, Benoît a fournit un travail extraordinaire ! Mais cela n'empêche pas que ce soit quelque chose que je considère gênant.
Si on arrive a modulariser le compilateur (compiler des modules séparément) alors on aura peut être un temps de compilation exponnentiel sur chaque module (mais raisonnable car chaque module aura une taille limitée). Bien sûr, il faut bien concevoir l'application et déterminer où seront les interfaces. Ces choix influront probablement sur les optimisation que Lisaac pourra faire.
Enfin pour le moment c'est juste une idée (que je n'ai même pas encore soumise à la mailing liste).
Et bien sûr, le dernier point, c'est le problème des bibliothèques que j'ai résolu en local mais qui n'est pas (encore ?) dans le tronc. En gros, actuellement, tu as un fichier path.li global (installé dans /usr, donc un utilisateur ne peux pas le modifier) qui liste les dossiers de ton projet et les dossiers des bibliothèques.
Impossible d'installer une bibliothèque sans toucher à ce fichier
Impossible de commencer un projet (organisé en plusieurs dossiers) sans toucher à ce fichier.
A mon avis, il faut se mettre au boulot et sans doute que dans un an ces problèmes auront disparu. J'espère.
Mildred
[^] # Re: Prêt à être utilisé par les masses?
Posté par MrLapinot (site web personnel) . Évalué à 2.
Si oui, souffre-t-il (potentiellement) du problème classique des compilateurs avec optimisations globales, à savoir : tu changes une ligne dans ton programme et ça modifie radicalement tes performances (en bien ou en mal, mais c'est en mal que c'est gênant), par des modifications qui se propagent en cascade ?
[^] # Re: Prêt à être utilisé par les masses?
Posté par Ontologia (site web personnel) . Évalué à 2.
Oui.
Si oui, souffre-t-il (potentiellement) du problème classique des compilateurs avec optimisations globales, à savoir : tu changes une ligne dans ton programme et ça modifie radicalement tes performances (en bien ou en mal, mais c'est en mal que c'est gênant), par des modifications qui se propagent en cascade ?
Euh radicalement, je ne sais pas, ça dépend de la ligne que tu rajoutes, ça dépend de l'influence de cette différence sur le reste du programme.
Le compilateur optimise toujours au mieux : c'est une machine bête et stupide, il trace tout les types, applique toutes les optims (en fonction des flags donné en argument), donc je vois pas trop où est le problème.
Ce que je veux dire, car c'est ce que je sens derrière ta question, c'est qu'il n'y a pas d'indéterminisme ni d'instabilité : pour un code lisaac donné, quand on connait le fonctionnement du compilateur, on peut facilement avoir une intuition de ce que ça donnera en C.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Prêt à être utilisé par les masses?
Posté par MrLapinot (site web personnel) . Évalué à 5.
C'est toujours une question délicate, le choix entre des optimisations globales ou locales. Personnellement, je préfère les secondes, parce que ça prémunit contre les surprises, et il n'y a pas forcément besoin d'avoir une connaissance approfondie du compilo pour écrire un code efficace (je pense à des langages à la ML où la phase de compilation fait parfois un peu magie noire). Mais c'est une question d'équilibre et les deux écoles existent, avec de bons arguments de chaque côté.
# Perl et autre
Posté par Joris Dedieu (site web personnel) . Évalué à 8.
Oui perl grossit comme le C produit des bugs.
Mais ces langages ont ceci en commun qu'ils ont été construit par leurs utilisateurs. Des gens capable de produire de libs au kilomètre de voir revoir et rerevoir du code par ce que c'est ce dont ils avaient besoin, pour leur travail, tous les jours ...
Java par son aspect anti-cobold s'est également inscrit cette lignée. Ou encore l'affreux php.
Lisaac est peut être un tres bon langage. Mais il lui manque peut-être l'essentiel. Répondre à un vrai besoin. Trouver sa communauté.
Or le besoin aujourd'hui est de pondre du code parallellisable certes mais surtout parallellisé vraiment.
Et je n'ai pas l'impression que ce soit l'objectif premier. Dommage.
[^] # Re: Perl et autre
Posté par Ontologia (site web personnel) . Évalué à 4.
C'est pas le premier certes, mais ça deviendra une feature majeur dans quelques mois. On en reparlera en détail avec une news spéciale.
Lisaac va implémenter COP, Concurent Object Programming.
En gros, COP permet d'automatiser la programmation parralèlle, en donnant au compilateur le sale boulot.
Pas de lib, pas de thread, pas de verrou.
En Lisaac, un programme début de deux façons :
Section Header
+ name := OBJ;
ou
Section Header
- name := OBJ;
Dans le premier cas, on a un objet à prototype classique, clonable. Chaque clone de cet objet sera différent, comme d'habitude.
Dans le second, chaque clone de l'objet donnera lieu à un thread.
Le modèle est conçu pour gérer automatiquement les priorités entre thread, avec un modèle bien à lui, que je me sens pas capable de vous expliquer ici :-)
Pour ceux qui veulent en savoir plus, rendez-vous P97 http://isaacproject.u-strasbg.fr/download/Lisaac_RM_03.pdf
On verra comment ce modèle fonctionnera, on a bien l'attention de jouer avec quelques mois avant de se déclarer satisfait.
Pour le reste ton analyse est très vraie, et très intéressante.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Perl et autre
Posté par Ummon . Évalué à 3.
On y parle principalement de programmation concurrente, des méthodes classiques existantes (lock (mutex, semaphore et cie), STM, etc.) ainsi que de l'approche de Clojure.
Même si vous ne vous intéressez pas particulièrement à ce langage je vous conseille d'y jeter un oeil.
[^] # Re: Perl et autre
Posté par Ummon . Évalué à 3.
Le "permalink" de la présentation dont je parlais : http://blip.tv/file/812787
Elle est disponible en mp4 ici : http://blip.tv/file/get/Richhickey-ClojureConcurrency730.mp4
Les slides et le code présenté sont disponibles sur le premier lien.
(J'espère qu'on pourra une fois un jour peut-être éditer les messages)
[^] # Re: Perl et autre
Posté par Mildred (site web personnel) . Évalué à 3.
Un objet '-' définit un thread avec une file d'appels. Chaque appel de slot sur cet objet va être mis en attente, et l'objet le traitera en temps venu.
Si on attend une valeur de retour, l'appel est bloquant. Il ne l'est pas dans le cas contraire.
On peut avec des paramètres et des valeurs de retour faire transiter des objets entre les threads. pour éviter les problèmes liés à la mémoire partagée, les objets partagés de type '+' sont rendus immuables (lecture seule). Les objets '-' par contre peuvent être partagés librement car ils ne sont accessibes que par envoi de messages entre threads, ne posant aucun problème de concurrence.
J'attend avec impatience de voir ce que ça va donner :)
Mildred
[^] # Re: Perl et autre
Posté par Sylvain Sauvage . Évalué à 8.
Je trouvais que les majuscules faisaient un peu trop années 1970, mais bon, on doit pouvoir s’habituer. Mais alors franchement, là, c’est du n’importe quoi.
Vous pouviez pas trouver une notation encore plus illisible, genre un . contre une , ?
[^] # Re: Perl et autre
Posté par Mildred (site web personnel) . Évalué à 4.
Un prototype s'écrit de la manière suivante:
Section Header
+ name := MON_PROTOTYPE;
+ description := "Juste un exemple";
// ...
Section Inherit
+ parent: Expanded OBJECT;
Section Public
- main <-
( + a, b:INTEGER;
a := 3;
b := 5;
a.to_string+" + "+b.to_string+" = "+(a+b).to_string+"\n".print;
);
Tu vois que les variables locales (a, b), les méthodes (main) et variables d'instance (parent), ou les propriétés décrivant l'objet (name, description, ...) sont toujours introduites par un signe + ou -.
le + correspond en général a une variable classique. Chaque objet à sa propre copie. Et devant 'name' cela signifie aussi que ton objet est probablement privé à un thread (sinon, il devient immuable).
Le - correspond au static du C, C++, Java ... La vairable est partagée entre tous les clones d'un même prototype, et est concervée entre les appels de fonction. Pour 'name' cela correspond que ton objet peut être partagé sans problèmes entre plusieurs threads sans devenir immuable (et ce faisant, il peut être lui-même un thread, selon la programmation).
A mon avis cela ne pose pas tant que ça un problème de lisibilité si la coloration syntaxique met en gras ces signes. Et je pense que dans le cas général, ce sera évident lorsqu'un objet sera + ou -.
Et si cela pose vraiment problème, c'est toujours modifiable. Par exemple dans la version 0.1 du langage, il y avait en plus du + et du - un signe * qui a été remplacé par le mot clef Expanded (qui signifie que l'objet est stocké complètrement dans la variable, ce n'est pas une référence).
[^] # Re: Perl et autre
Posté par windu.2b . Évalué à 5.
Un code ne devrait-il pas être clair même sans coloration syntaxique ? S'il faut se crever les yeux sur un pov' caractère qui peut changer radicalement le résultat attendu (ne pas bien différencier une variable privée d'une variable statique, y a quand même là une source d'erreur énorme !).
[^] # Re: Perl et autre
Posté par Mildred (site web personnel) . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.