• [^] # Re: A quand un OS "INBUGABLE" ?

    Posté par . En réponse à la dépêche Interview de Bjarne Stroustrup. Évalué à 2.

    c'est vrai que dans certains cas, il faut privilégier ta performance, mais en général les développements internes sont fait en langage interprétés (VB & Macros pour la bureautique, Perl & scripts pour l'admin).
    Un article démontrait que si tu devais lancer un calcul qui devait prendre plus de 26 mois, c'était plus rentable d'attendre la génération des machines 2 fois plus puissantes et faire un calcul de 8 mois pour arriver au même résultat.
    En gros si tu dois mettre 2 fois plus de temps pour coder une application optimisée, il vaut mieux l'écrire de manière moins optimisée (à condition que les temps de réactions soient raisonnables) et propre. Et Si en plus elle est faite pour durer, même si les 3000 postes sont à 500mhz pour le moment, et bien dans 5 ans ils seront à 5ghz.

    Donc l'optimisation vaut le coup pour :
    -une application de calcul pur (ex modélisation, traitements temps réels, etc).
    -une application quick&dirty jettable (ex jeux).


    Bon maintenant, si tu es un dieu en C++/C que tu codes du premier coup sans avoir de fuites de mémoires, autant prendre le langage le plus rapide. ça vaut surtout le coup pour les applications graphiques ou il y a beaucoup d'interactivité et peu de répétitions.
    Pour tout ce qui est opérations répétitives sans interactivité (filtrage constant d'un flux par ex) JAVA devient trés performant, parce que la JIT va affinner le code assembleur généré, et au bout de 10 passes tu obtiens un code presque aussi performant que du C.
    C'est comme tout, il faut choisir l'outils le plus adapté à ta situation.
    Reste que pour moi C++ va vers des niches ou la performance prime tout en ayant un peu plus de rigueur dans le codage que le C qui est un "assembleur évolué".