Comment faire un langage plus rapide que C ?
Enfin thoériquement un langage qui produit du C en sorti aura dû mal à être plus rapide, si le compilateur a été capable d'écrire ce code, un programmeur sera capable de le faire.
D'ailleur au final votre benchmark MPEG2 le prouve, LISAAC est légèrement plus lent.
Pour aller plus vite que le C, faut commencer par le "sqeezer", c'est-à-dire produire directement du code machine, sinon Lisaac sera toujours limité aux contraintes sémantiques imposées par le C, contraintes qui empêche certaines optimisations possible dans d'autres langages.
Premier point : Le minimalisme du code.
Pas toujours vrai. Imposer des constructions de boucle ou de tableau dans le langage avec une sémantique précise permet au compilateur de faire des hypothèses valides supplémentaire. En fait la plupart des constructions qui sont intégrées au langage permettent au langage de faire des hypothèses valides et donc des optimisations supplémentaires.
Second point : La suppression de la liaison dynamique
Je veux bien moi, mais bon c'est plus un problème des langages objets que du C qui est ici le sujet :)
Le compilateur Lisaac réalise le graphe de l'ensemble du code, c'est pour cela que compiler 40 000 lignes (libraririe comprise) prend avec ce compilateur 512 Mo de mémoire.
Eh bé :)
Maintenant dans la série "comment...", "Comment faire un langage qui remplace les langages objets actuels ?"
- Ne pas se focaliser uniquement sur les performances, la plupart des langages compilés ont aujourd'hui des performances largement raisonnable et suffisantes.
- Se focaliser sur la productivité et l'agréable.
Pour cela, il faut faire à la place du programmeur tout ce qui est trop techniques et lui fait perdre du temps sur des détails qui n'ont pas grand chose à voir avec l'objectif du programmeur : faire un programme qui répond à un besoin et des objectifs.
Pour cela :
- gérer la mémoire pour éviter toutes fuites mémoires et autres erreurs grossières d'accès mémoires
- proposer des types "primitifs" en "standard" dans la grammaire du langage (entier, flottant, chaîne de caractère, etc.) et des constructions "standards" (conditionnel, boucle) sans autre alternative : c'est une façon d'imposer un style de rédaction et d'écriture d'algorithme, avec comme objectif : se faire comprendre des autres programmeurs, et donc gagner du temps en maintenance, en relecture, en test, etc. Bref, avoir un dictionnaire de référence pour que tout le monde parle la même langue et se comprenne. Rien de plus frustrant de tomber sur des macros imbittable en C++, ou des types string personnalisés
- proposer un grand nombre de bibliothèque en "standard" implémentant les problèmes les plus courant. Ceci toujours dans la même idée d'éviter que chacun réinvente une roue au comportement pas forcement identique à celle du collègue programmeur. On retrouvera bien entendu dans ces bibliothèques l'accès au système de fichier mais aussi tout ce qui touche aux "communications" comme un mécanisme d'appel d'objet/procédure distant, des implémentations de standards courants comme XML, HTTP et les sockets, toujours dans le but de "standardiser" les moyens de communications entre application et donc éviter de se prendre le "choux" à faire communiquer 2 briques logiciels qui utilisent des implémentations différentes (et jamais parfaites) parfois de protocoles identiques.
On retrouvera également dans ces bibliothèques des types "standards" comme les collections ou les types exprimants le temps, toujours dans cet objectif d'avoir une représentation commune des structures les plus courantes, et ainsi grandement simplifier la réutilisation de code existant.
De la même manière on retrouvera des mécanismes de persistances (BDD, sérialisation automatique, etc.).
- la gestion de version : une brique logicielle évolue, et pour être réutilisée dans un cadre précis, il faut savoir identifier une version précise de la brique, mais aussi des types qui la compose voir des fonctions.
- un mécanisme de reflexion pour faciliter la programmation à un niveau supérieur mais aussi faciliter l'analyse et la vérification de code.
- une sécurisation de l'espace mémoire avec un mécanisme d'isolation empêchant un processus de faire s'écrouler d'autres processus.
Reste un dernier point qui n'est pas "obligatoire" :
- poser une couche d'abstraction vis-à-vis du matériel. C'est un gros avantage, mais il peut limiter la construction de logiciels utilisation du matériel justement :)
J'oublies sûrement plein de trucs, mais si un langage veut s'imposer il doit "réfléchir" à tous ces points et ne pas s'occuper uniquement de sa grammaire mais de son environnement complet : environnement d'exécution et bibliothèques proposées en standard.
Un point important à considérer également :
- faciliter la programmation multi-thread pour la rendre intuitive au programmeur.
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par TImaniac (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 2.
Enfin thoériquement un langage qui produit du C en sorti aura dû mal à être plus rapide, si le compilateur a été capable d'écrire ce code, un programmeur sera capable de le faire.
D'ailleur au final votre benchmark MPEG2 le prouve, LISAAC est légèrement plus lent.
Pour aller plus vite que le C, faut commencer par le "sqeezer", c'est-à-dire produire directement du code machine, sinon Lisaac sera toujours limité aux contraintes sémantiques imposées par le C, contraintes qui empêche certaines optimisations possible dans d'autres langages.
Premier point : Le minimalisme du code.
Pas toujours vrai. Imposer des constructions de boucle ou de tableau dans le langage avec une sémantique précise permet au compilateur de faire des hypothèses valides supplémentaire. En fait la plupart des constructions qui sont intégrées au langage permettent au langage de faire des hypothèses valides et donc des optimisations supplémentaires.
Second point : La suppression de la liaison dynamique
Je veux bien moi, mais bon c'est plus un problème des langages objets que du C qui est ici le sujet :)
Le compilateur Lisaac réalise le graphe de l'ensemble du code, c'est pour cela que compiler 40 000 lignes (libraririe comprise) prend avec ce compilateur 512 Mo de mémoire.
Eh bé :)
Maintenant dans la série "comment...", "Comment faire un langage qui remplace les langages objets actuels ?"
- Ne pas se focaliser uniquement sur les performances, la plupart des langages compilés ont aujourd'hui des performances largement raisonnable et suffisantes.
- Se focaliser sur la productivité et l'agréable.
Pour cela, il faut faire à la place du programmeur tout ce qui est trop techniques et lui fait perdre du temps sur des détails qui n'ont pas grand chose à voir avec l'objectif du programmeur : faire un programme qui répond à un besoin et des objectifs.
Pour cela :
- gérer la mémoire pour éviter toutes fuites mémoires et autres erreurs grossières d'accès mémoires
- proposer des types "primitifs" en "standard" dans la grammaire du langage (entier, flottant, chaîne de caractère, etc.) et des constructions "standards" (conditionnel, boucle) sans autre alternative : c'est une façon d'imposer un style de rédaction et d'écriture d'algorithme, avec comme objectif : se faire comprendre des autres programmeurs, et donc gagner du temps en maintenance, en relecture, en test, etc. Bref, avoir un dictionnaire de référence pour que tout le monde parle la même langue et se comprenne. Rien de plus frustrant de tomber sur des macros imbittable en C++, ou des types string personnalisés
- proposer un grand nombre de bibliothèque en "standard" implémentant les problèmes les plus courant. Ceci toujours dans la même idée d'éviter que chacun réinvente une roue au comportement pas forcement identique à celle du collègue programmeur. On retrouvera bien entendu dans ces bibliothèques l'accès au système de fichier mais aussi tout ce qui touche aux "communications" comme un mécanisme d'appel d'objet/procédure distant, des implémentations de standards courants comme XML, HTTP et les sockets, toujours dans le but de "standardiser" les moyens de communications entre application et donc éviter de se prendre le "choux" à faire communiquer 2 briques logiciels qui utilisent des implémentations différentes (et jamais parfaites) parfois de protocoles identiques.
On retrouvera également dans ces bibliothèques des types "standards" comme les collections ou les types exprimants le temps, toujours dans cet objectif d'avoir une représentation commune des structures les plus courantes, et ainsi grandement simplifier la réutilisation de code existant.
De la même manière on retrouvera des mécanismes de persistances (BDD, sérialisation automatique, etc.).
- la gestion de version : une brique logicielle évolue, et pour être réutilisée dans un cadre précis, il faut savoir identifier une version précise de la brique, mais aussi des types qui la compose voir des fonctions.
- un mécanisme de reflexion pour faciliter la programmation à un niveau supérieur mais aussi faciliter l'analyse et la vérification de code.
- une sécurisation de l'espace mémoire avec un mécanisme d'isolation empêchant un processus de faire s'écrouler d'autres processus.
Reste un dernier point qui n'est pas "obligatoire" :
- poser une couche d'abstraction vis-à-vis du matériel. C'est un gros avantage, mais il peut limiter la construction de logiciels utilisation du matériel justement :)
J'oublies sûrement plein de trucs, mais si un langage veut s'imposer il doit "réfléchir" à tous ces points et ne pas s'occuper uniquement de sa grammaire mais de son environnement complet : environnement d'exécution et bibliothèques proposées en standard.
Un point important à considérer également :
- faciliter la programmation multi-thread pour la rendre intuitive au programmeur.