Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #21
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Developpeur
    Inscrit en
    avril 2002
    Messages
    3 813
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Developpeur

    Informations forums :
    Inscription : avril 2002
    Messages : 3 813
    Points : 10 542
    Points
    10 542

    Par défaut

    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).

  2. #22
    Membre confirmé
    Profil pro
    retraité
    Inscrit en
    décembre 2010
    Messages
    240
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : retraité

    Informations forums :
    Inscription : décembre 2010
    Messages : 240
    Points : 495
    Points
    495

    Par défaut

    Citation Envoyé par darklinux Voir le message
    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++)

  3. #23
    Membre confirmé
    Homme Profil pro
    Consultant informatique
    Inscrit en
    octobre 2005
    Messages
    231
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : Philippines

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : octobre 2005
    Messages : 231
    Points : 549
    Points
    549

    Par défaut

    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.

  4. #24
    Membre confirmé
    Homme Profil pro
    Consultant informatique
    Inscrit en
    octobre 2005
    Messages
    231
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : Philippines

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : octobre 2005
    Messages : 231
    Points : 549
    Points
    549

    Par défaut

    Citation Envoyé par archqt Voir le message
    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).

  5. #25
    Membre confirmé
    Profil pro
    retraité
    Inscrit en
    décembre 2010
    Messages
    240
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : retraité

    Informations forums :
    Inscription : décembre 2010
    Messages : 240
    Points : 495
    Points
    495

    Par défaut

    Citation Envoyé par forthx Voir le message
    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 :-)

  6. #26
    Membre averti
    Homme Profil pro
    Consultant informatique
    Inscrit en
    décembre 2008
    Messages
    50
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : décembre 2008
    Messages : 50
    Points : 414
    Points
    414

    Par défaut le choix du benchmark et le biais de données

    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...

  7. #27
    Modérateur
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    4 088
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 4 088
    Points : 16 620
    Points
    16 620

    Par défaut

    Citation Envoyé par Uther Voir le message
    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.

    Citation Envoyé par anykeyh
    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 ...
    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  8. #28
    Nouveau Candidat au Club
    Profil pro
    Inscrit en
    novembre 2008
    Messages
    2
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2008
    Messages : 2
    Points : 0
    Points
    0

    Par défaut petite erreur ?

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

  9. #29
    Membre éprouvé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juin 2004
    Messages
    353
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : juin 2004
    Messages : 353
    Points : 1 181
    Points
    1 181

    Par défaut

    Citation Envoyé par archqt Voir le message
    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 ^^

  10. #30
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Developpeur
    Inscrit en
    avril 2002
    Messages
    3 813
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Developpeur

    Informations forums :
    Inscription : avril 2002
    Messages : 3 813
    Points : 10 542
    Points
    10 542

    Par défaut

    Citation Envoyé par Marco46 Voir le message
    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.

  11. #31
    Membre expert Avatar de Zefling
    Homme Profil pro
    Développeur Web
    Inscrit en
    avril 2007
    Messages
    1 026
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : avril 2007
    Messages : 1 026
    Points : 3 715
    Points
    3 715

    Par défaut

    Citation Envoyé par Uther Voir le message
    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, ...

  12. #32
    Modérateur
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    4 088
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 4 088
    Points : 16 620
    Points
    16 620

    Par défaut

    Citation Envoyé par Uther Voir le message
    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.

    Citation Envoyé par Uther Voir le message
    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.
    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  13. #33
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Developpeur
    Inscrit en
    avril 2002
    Messages
    3 813
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Developpeur

    Informations forums :
    Inscription : avril 2002
    Messages : 3 813
    Points : 10 542
    Points
    10 542

    Par défaut

    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.

  14. #34
    Membre averti
    Profil pro
    Inscrit en
    novembre 2005
    Messages
    245
    Détails du profil
    Informations personnelles :
    Localisation : France, Seine et Marne (Île de France)

    Informations forums :
    Inscription : novembre 2005
    Messages : 245
    Points : 325
    Points
    325

    Par défaut

    Citation Envoyé par transgohan Voir le message
    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 ...

  15. #35
    Membre éclairé
    Inscrit en
    janvier 2006
    Messages
    331
    Détails du profil
    Informations forums :
    Inscription : janvier 2006
    Messages : 331
    Points : 889
    Points
    889

    Par défaut Rien d'étonnant

    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

    Citation Envoyé par grunk Voir le message
    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...

  16. #36
    Modérateur
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    4 088
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 4 088
    Points : 16 620
    Points
    16 620

    Par défaut

    Citation Envoyé par esperanto Voir le message
    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.

    Citation Envoyé par esperanto Voir le message
    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.

    Citation Envoyé par esperanto Voir le message
    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.

    Citation Envoyé par esperanto Voir le message
    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.

    Citation Envoyé par esperanto Voir le message
    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.
    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  17. #37
    Expert éminent
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    janvier 2011
    Messages
    2 781
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : janvier 2011
    Messages : 2 781
    Points : 8 004
    Points
    8 004

    Par défaut

    Citation Envoyé par darklinux Voir le message
    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.

    « Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
    « Le watchdog aboie, les tests passent »

  18. #38
    Membre régulier
    Homme Profil pro
    Ingénieur systèmes et réseaux
    Inscrit en
    janvier 2006
    Messages
    102
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingénieur systèmes et réseaux
    Secteur : Industrie

    Informations forums :
    Inscription : janvier 2006
    Messages : 102
    Points : 100
    Points
    100

    Par défaut L'intêret ECOLOGIQUE

    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...

  19. #39
    Modérateur
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    4 088
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 4 088
    Points : 16 620
    Points
    16 620

    Par défaut

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

    Et sinon l'électricité verte ça n'existe pas.
    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  20. #40
    Membre expérimenté
    Profil pro
    Inscrit en
    janvier 2011
    Messages
    1 630
    Détails du profil
    Informations personnelles :
    Localisation : France, Nord (Nord Pas de Calais)

    Informations forums :
    Inscription : janvier 2011
    Messages : 1 630
    Points : 1 605
    Points
    1 605

    Par défaut

    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.

Discussions similaires

  1. Réponses: 53
    Dernier message: 24/04/2017, 16h23
  2. IDC : une étude révèle une addiction des américains pour les smartphones
    Par Stéphane le calme dans le forum Actualités
    Réponses: 7
    Dernier message: 09/04/2013, 08h32
  3. Réponses: 14
    Dernier message: 30/07/2009, 18h31
  4. Réponses: 0
    Dernier message: 30/07/2009, 10h42

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo