Discussion :

[Uther]

Le plus bizarre c'est surtout que TypeScript n'est jamais exécuté. Il transpile vers JavaScript qui lui est exécuté. Donc catégoriser TypeScript qui n'est déjà pas un langage à part entière (superset de JS) comme un langage interprété c'est, pour rester gentil, bizarre.

Ce n'est pas si bizarre que ça, en soi, de considérer le TS et le JS différent. Le C, Rust, Go,... pourraient aussi être considéré comme un superset du langage d'assemblage, ils n'en restent pas moins des langages différents.

La transpilation /compilation d'un langage peut avoir un impact sur les performance en mal, notamment si le langage de plus haut niveau introduit des mécanises qui peuvent impacter les performance (typage dynamique, GC), ou en bien si elle permet de produire du code plus efficace que ce qui aurait été fait manuellement (asm.js par exemple).

[archqt]

C 'est quoi l ' intérêt ? j ' aurais approuvé cette étude fin des années 1990 début 2000 à l ' époque ou les CPU étaient monocœur et le SMP à la limite de ' expérimental , mais les CPU ont tellement évolué , comme les GPU . À la limite cela pourrait être valable sur smartphone ou tablette , mais qui programme la dessus en C ou Perl ???

L'intérêt est triple :

• pour la planète
• pour la facture de l'entreprise
• pour la rapidité du programme pour l'utilisateur

Par exemple Flask ou Django en python sont à 5% au nombre de requêtes réseaux par rapport à des frameworks compilés. On gagne peut être du temps au développement (pas sûr non plus) mais ensuite s'il faut déployer 20 serveurs au lieu d'un seul sur le long terme ce n'est pas gagnant....
Je n'ai plus la référence d'un article, dont la société avait refait son logiciel serveur d'envoi de SMS (pour orange de mémoire) en langage C au lieu du PHP et cela permettait d'envoyer 150 fois plus de SMS/seconde qu'avant. Sur le coup cela permet assez rapidement de rentrer dans ses fonds en dépensant moins en matériel/électricité.
Même facebook a fait un transpileur PHP -> C++ puis le code est compilé....et je ne parle même pas de l'embarqué (en général C/C++)

[anykeyh]

Cette étude est mal faite. J'ai sursauté sur la difference x8 entre Typescript et Javascript.

Du coup je me suis permis de regarder le framework de test disponible ici. https://sites.google.com/view/energy...ency-languages

J'ai pris l'étude, la première ligne du premier tableau (binarytree) et comparé les algos de deux langages que je connais: Ruby et Javascript:

https://github.com/greensoftwarelab/...es.yarv-5.yarv
https://github.com/greensoftwarelab/...narytrees.node

(On passera sur les extension de fichier yolo yolo hein...).

Long story short: La version de Ruby est une version parallelisable qui fork un process Unix, forcement moins efficace energetiquement et probablement moins éfficace en mono-coeur ou en "load" average.

Pareillement, la différence entre typescript et javascript dans "fannkuch-redux" s'explique par le code source completement différent (algorithme different).

Après, j'ai eu la flemme d'aller plus loin je dois dire. Bref, étude à jeter.

[anykeyh]

L'intérêt est triple :

• pour la planète
• pour la facture de l'entreprise
• pour la rapidité du programme pour l'utilisateur

Par exemple Flask ou Django en python sont à 5% au nombre de requêtes réseaux par rapport à des frameworks compilés. On gagne peut être du temps au développement (pas sûr non plus) mais ensuite s'il faut déployer 20 serveurs au lieu d'un seul sur le long terme ce n'est pas gagnant....
Je n'ai plus la référence d'un article, dont la société avait refait son logiciel serveur d'envoi de SMS (pour orange de mémoire) en langage C au lieu du PHP et cela permettait d'envoyer 150 fois plus de SMS/seconde qu'avant. Sur le coup cela permet assez rapidement de rentrer dans ses fonds en dépensant moins en matériel/électricité.
Même facebook a fait un transpileur PHP -> C++ puis le code est compilé....et je ne parle même pas de l'embarqué (en général C/C++)

C'est possible de gagner énormement en performance en utilisant un language compilé, MAIS il faut changer de paradigme sur pas mal d'éléments; la plupart du temps passé par le serveur web est dans la mémoire et les E/S. Un service web va literralement passer la plus grande partie de son temps a parser / copier / déplacer / réduire des infos. Du coup si tu pars sur du compilé mais tu gardes un ORM ultra facile à prendre en main, une interface super simple d'accès aux paramètres HTTP, des hash/map/dictionnary partout et bien tu vas pas gagner tant que ça (peut-etre x2 max).

[archqt]

Intéressant pour se faire une idée avec les compilateurs, os, et processeurs moderne !

Dommage qu'il n'y ai pas l'assembleur

Bah il gagnerait :-)

[pboulanger]

Le choix d'un benchmark induit souvent un biais tant sur la mesure que sur ce qui est mesuré: sur https://julialang.org/benchmarks/ on verra LuaJIT proche des performances du C.
La plupart des benchmarks ne sont pas forcément optimisés sur tous les langages ou n'utilise pas forcément les bonnes librairies (comme numpy en python couplé à numba, par exemple)...
Dans un monde où le prix de l'énergie est dépendant de ressources limitées (bientôt plus de pétrole, par ex) mesurer le coût d'exécution d'un programme n'est pas inintéressant... Quand pour maintenir le bitcoin et autres cryptomonnaies on consomme, en électricité, la consommation d'un pays; on se dit que l'on marche sur la tête: le gaspillage ne saurait perdurer éternellement...

[Marco46]

Ce n'est pas si biearre que ça en soit, de considérer le TS et le JS différent. Le C, Rust, Go,... pourraient aussi être considéré comme un superset du langage d'assemblage, ils n'en restent pas moins des langages différents.

La transpilation /compilation d'un langage peut avoir un impact sur les performance en mal, notamment si le langage de plus haut niveau introduit des mécanises qui peuvent impacter les performance (typage dynamique, GC), ou en bien si elle permet de produire du code plus efficace que ce qui aurait été fait manuellement (asm.js par exemple).

Mais le TS n'est jamais exécuté directement ! On passe de TS à JS et c'est ce JS qui est exécuté. Jamais le TS. Et en plus on peut transpiler une seule fois pour n exécutions.

Et de plus le code JS généré dépend avant tout de la version de JS que tu cibles. Si tu cibles ESNext il n'y a pratiquement aucune différence entre le code JS généré et celui que tu aurais pu écrire.

Pareillement, la différence entre typescript et javascript dans "fannkuch-redux" s'explique par le code source completement différent (algorithme different).

Bon ben voilà, c'est juste n'imp quoi ...

[cmercier]

je crois avoir relevé un leger decalage sur la date de parution qui aurait due être au 1/4/2019 ?

[Shepard]

Bah il gagnerait :-)

Je n'en suis pas sûr du tout, il y a des tas d'optimisations qu'un compilateur fait et qu'un humain ne penserait pas à appliquer. Je ne pense pas qu'un humain puisse rivaliser actuellement avec le boulot fait par gcc. Par contre, en optimisant "à la main" le programme C déjà compilé, un humain pourrait probablement trouver des spots améliorable et vaincre le compilateur, mais du coup ce n'est plus le programme écrit en assembleur d'après moi ^^

[Uther]

Mais le TS n'est jamais exécuté directement ! On passe de TS à JS et c'est ce JS qui est exécuté. Jamais le TS. Et en plus on peut transpiler une seule fois pour n exécutions.

Et de plus le code JS généré dépend avant tout de la version de JS que tu cibles. Si tu cibles ESNext il n'y a pratiquement aucune différence entre le code JS généré et celui que tu aurais pu écrire.

Je crois que tu as mal compris ce que je voulais dire. Je sais bien ce que le TS est compilé en JS.

Je dis juste que faire la différence TypeScript / JavaScript est assez similaire à faire la différence C / Assembleur.
Le code JavaScript généré par le transpileur pourrait être différent d'un code JavaScript écrit à la main. Tout comme le code généré par un compilateur C est généralement différent d'un code écrit manuellement en assembleur.

Alors peut-être que en effet, comme tu le dit, le TS fait un travail minimal, mais théoriquement il pourrait utiliser ses informations de typage pour générer du code asm.js plus efficace que du code JavaScript écrit à la main. Ou peut-être que la qualité du code transpilé pourrait être moins bonne que ce que fait à la main un bon programmeur JS. Bref les considérer comme différent d'un point de vue théorique n'est pas idiot.

Maintenant le problème de cette étude est qu'elle est basée sur le benchmark game dont les programmes benchmarkés sont soumis par des volontaires qui n'ont pas tous réalisé les mêmes optimisations, ce qui a souvent plus d'impact que les langages utilisés.

[Zefling]

Je crois que tu as mal compris ce que je voulais dire. Je sais bien ce que le TS est compilé en JS.

Il manque peut-être le mode de transpilation : ES5, ES6, ES7, ...

[Marco46]

Alors peut-être que en effet, comme tu le dit, le TS fait un travail minimal, mais théoriquement il pourrait utiliser ses informations de typage pour générer du code asm.js plus efficace que du code JavaScript écrit à la main. Ou peut-être que la qualité du code transpilé pourrait être moins bonne que ce que fait à la main un bon programmeur JS. Bref les considérer comme différent d'un point de vue théorique n'est pas idiot.

Sauf que les informations de typage ne sont pas transpilées mais supprimées puisque JavaScript n'en connaît rien. Elles ne servent qu'au compilateur TS pour émettre des erreurs, il n'en reste rien au runtime.

Je t'invite à faire le test.

Quand tu transpiles de TS vers ESNext il n'y a pratiquement aucun changement de structure. Les types disparaissent purement et simplement.

C'est quand tu transpiles de TS vers ES5 par exemple que tu vas avoir plein de choses pour émuler les features manquantes entre ES5 et ESNext. Exactement comme avec Babel.

D'où la remarque de Zefling je suppose. Ce test ne veut rien dire si on ne précise pas la target du compilateur.

Je dis juste que faire la différence TypeScript / JavaScript est assez similaire à faire la différence C / Assembleur.

Et du coup non. C'est justement la grosse différence. TypeScript = JavaScript + les types + les polyfills nécessaires en fonction de la target.

[Uther]

Ok, je n'ai en effet pas étudié en détail le fonctionnement interne de TypeScript. D'après tes explications, le transpileur TS fait un boulot minimal. C'est dommage, car théoriquement avec asm.js, et certaines API modernes comme les tableaux typés, il y a moyen de générer du code JavaScript, certes absolument pas idiomatique, mais qui profite des informations de typage.

[darklinux]

Il existe toujours et il existera toujours des systèmes embarqués temps réel qui ne tournent pas sur des "machines de guerre".

De plus cela sensibilise, si tu prends celui qui fait mumuse avec un raspberry avec du Python il se rendra compte que si son application est lente malgré toutes ses optimisations il peut obtenir une considérable amélioration en recodant tout en C.

Le RPI n ' est qu ' un PC de la fin des années 1990 multicœurs ... Ce n 'est pas plus significatif que le Jetson Nano ...

[esperanto]

Je ne vois rien d'étonnant dans ces résultats, on a à peu de choses près dans l'ordre

1. Les langages de très bas niveau et compilés en code natif (C/C++)
2. Les langages de haut niveau compilés en natif, comme Ada: le code est un peu moins optimisé parce qu'il faut convertir les types "humains" en types "machine"
3. Les machines virtuelles
4. Les interpréteurs : plus lents que les VM parce que modifier des registres, fussent-ils virtuels, est moins cher que de parcourir un arbre syntaxique abstrait
5. Les interpréteurs dans une VM, type JRuby (au fait: compilé ou interprété?)
6. Les transpileurs comme Typescript, j'y reviendrai plus loin

Évidemment vous allez me dire que ça ne correspond pas exactement. Mais il faut ensuite pondérer par d'autres critères comme l'utilisation habituelle d'un langage: par exemple, selon ce critère Fortran devrait être devant Java, mais si on compare une VM récente à un compilateur qui n'a plus connu que des corrections de bugs pendant les dix dernières années, je veux bien croire que Java est mieux adapté aux machines récentes que son ancêtre...
A une époque ce genre d'étude aurait servi à discréditer Ada, réputé lent mais donnant la priorité à la sécurité. Aujourd'hui on va s'en prendre aux langages de script parce qu'ils sont tout à coup devenus majoritaires

C'est étonnant de voir un facteur 5 entre JS et typescript puisque le résultat final de ts est du JS.
A moins que l'étape de transpilage soit compté auquel cas il faut faire de mm pour les compilation.

Même si l'étape de transpilage n'est pas comptée, un code transpilé n'est pas équivalent au même code écrit en Javascript par un humain: dans le meilleur des cas le transpileur ajoute toujours un peu de code identique dans tous les programmes, qui équivaut en gros à la "libc" par rapport à l'assembleur. Un exemple: si une fonction Typescript n'a pas exactement les mêmes paramètres que son équivalent Javascript, il est probable que le compilateur va d'abord rajouter une fonction Javascript qui ne fait qu'appeler la fonction habituelle avec les bons paramètres et ensuite partout où la version Typescript est appelée, générer un appel de fonction, coûteux en temps.

Il serait aussi intéressant de savoir si tous ces programmes ont bien été écrits chacun par un spécialiste du langage en question. Sinon, ça me rappellerait trop comment on a détruit les bases de données objet (ODMG): les benchmarks étaient écrits par des spécialistes Oracle, donc on comparait un programme Oracle hyper-optimisé avec un "équivalent" ODMG écrit à l'arrache...

[Marco46]

Même si l'étape de transpilage n'est pas comptée, un code transpilé n'est pas équivalent au même code écrit en Javascript par un humain:

Et si justement.

dans le meilleur des cas le transpileur ajoute toujours un peu de code identique dans tous les programmes, qui équivaut en gros à la "libc" par rapport à l'assembleur.

Non. Enfin ça dépend de la target. Si tu target ES5 et que tu utilises des fonctionnalités de ES6+ il va te rajouter plein de choses. Si tu target ESNext il n'y a aucune différence.

Mais dans ce cas leur test n'a aucune valeur. Il faudrait comparer TS avec ESNext, pas avec une version du langage obsolète. C'est comme si ils avaient fait le test avec Java 5 ou .NET 1.0 ça n'a pas de sens.

Un exemple: si une fonction Typescript n'a pas exactement les mêmes paramètres que son équivalent Javascript, il est probable que le compilateur va d'abord rajouter une fonction Javascript qui ne fait qu'appeler la fonction habituelle avec les bons paramètres et

Non.

ensuite partout où la version Typescript est appelée, générer un appel de fonction, coûteux en temps.

C'est pas le cas.

Il serait aussi intéressant de savoir si tous ces programmes ont bien été écrits chacun par un spécialiste du langage en question.

Je pense qu'on peut largement se mettre d'accord sur le fait que les conclusions de cette étude sont bonnes pour la poubelle, cf en particulier le post de @anykeyh.

[transgohan]

Le RPI n ' est qu ' un PC de la fin des années 1990 multicœurs ... Ce n 'est pas plus significatif que le Jetson Nano ...

Et qu'est ce qui est significatif en systèmes embarqués ? Un octo-coeur avec une carte graphique de 2Gio ?

La plupart des systèmes embarqués tournent avec du matériel dont la puissance est digne des années 80-90. C'est ça la réalité.
Je travaille sur des produits utilisant des technologies éprouvées qui datent d'avant ma naissance... C'est la quotidien de tous les développeurs embarqués.

[requinham]

Pour moi de telle étude est d'une importance majeure sur le plan ECOLOGIQUE surtout pour les fournisseurs qui ne prévoient pas un passage à l'électricité verte...

[Marco46]

Si les données sont fausses l'étude ne sert à rien.

Et sinon l'électricité verte ça n'existe pas.

[tanaka59]

Le Python est un langage vorace car celui ci sert dans des appli utilisant des moteurs 3D .. rien de révolutionnaire . Idem le C++ peut servir pour du 2D et des minis jeux genre snake ou puissance 4.