@Nmut Cela fait plaisir de voir quelqu’un qui prends le temps d’argumenter et fournit de arguments interessants et construits. Un très grand merci à toi.
Allons directement à l’essentiel :
(1) L’empilement des couches. Tu dit que les couches sont nécessaires. Et la dessus, je ne te contredirait pas, c’est évident. Ce que je dénonce, c’est l’excès d’empilement et la non maîtrise croissante de ce qui se passe au sein de ces couches.
Les couches, cela apporte du bon et du moins bon. Des fonctions évoluées pour le positif, un éloignement de la réalité de la machine pour le négatif.
Lorsqu’une couche est de mauvaise qualité, la logique voudrait qu’on dénonce la situation et qu’on la réécrive. Mais bien souvent quand un programmeur doit faire avec une couche merdique, il choisit par facilité d’écrire une nouvelle couche par dessus.
Avec le temps, au lieu de restructurer les couches, on continue d’empiler parce que c’est la voie de la facilité. Au final, on obtient un empilement infâme qui bouffe toujours plus de puissance. Et la plupart des programmeurs n’ont plus la moindre idée de ce qui s’y passe et de comment écrire du code efficient avec ça.
Un jour ou l’autre, il faudra bien restructurer tout cela. On ne pourra pas empiler éternellement. Parce que la réalité, c’est que toute la puissance apportée par le progrès matériel est bouffé au fur et à mesure qu’on empile.
La loi de moore à donné de mauvaises habitudes. Mais ce temps la est fini.
On gagne désormais bien plus à virer des couches inutiles qu’a changer un proco de 10 ans d’age. Et les programmeurs comme moi ne s'en privent pas quand cela est possible.
(2) Les langages.
Les objets n’ont pas forcément un overhead important, mais cela dépends beaucoup du langage. En Javascript, c’est une catastrophe. Mais en C++, si on sait bien se servir des objets, l’impact est quasiment nul. Donc on ne s'en prive pas. Mais encore faut t’il avoir appris comment cela fonctionne à bas niveau pour savoir ce qu’il faut faire et ne pas faire. Parce que l'objet, comme tout ce qui est puissant, on peut en faire le meilleur et le pire.
Pour ce qui est de la comparaison des langages, Java est très inférieur en performances à C/C++. Du moins entre les mains de bons programmeurs.
En rapidité, Java est plombé par le bound checking sur ses accès mémoire. Et les accès mémoire, sur les systèmes moderne, c’est très cher.
Attention aux benchmarks naifs. Un test naïf viens souvent démontrer que le garbage collector de Java est plus rapide qu’une gestion de la mémoire de débutant en C/C++. Par contre, il se fait détruire littéralement par une collection de gestionnaires mémoires personnalisés en C/C++.
Au niveau des types de données et leur gestion, quand j’ai découvert Java, j’ai halluciné devant la catastrophe.
Et que dire sur l’absence de fichiers d’en tête… et le code peu lisible qui en découle.
Pour ce qui est du calcul, Java à l’avantage d’être compilé en mode JIT. Ce qui a l’avantage de pouvoir exploiter plus facilement les extensions d’un processeur particulier.
Mais il suffit de compiler son soft C/C++ sur la plateforme avec les bons flags pour obtenir la même chose. Et même encore mieux (voir plus loin).
C’est la ou l’on arrive au débat sur l’assembleur. Beaucoup pensent à tort que l’assembleur n’est plus utilisé. Mais cela n’est pas vrai.
De nos jours, il est vrai que l’on n’écrirait plus un soft complet en assembleur. Trop compliqué, trop long, pas assez portable. Et les compilateurs sont plutôt bons de nos jours. Sur des milliers d’instruction, je vous garantit que vous ferez moins bien qu’un compilateur.
Sauf que… l’assembleur est toujours utilisé pour des petites portions de code. Des portions petites, mais extrêmement importantes en terme de performance.
Des cas ou il faut justement faire des calculs très intensifs et ou l’on choisit les quelques instructions assembleur les meilleures avec beaucoup de soin et avec des codepath pour chaque processeur particulier.
Beaucoup de gens connaissent les instructions MMX, AVX et autres. Mais chaque processeur dispose de particularités qui sont souvent très difficiles à exploiter autrement qu’en assembleur. Il y a tellement de subtilités et de complexités dans les processeurs modernes. Regardez certains softs ou bibliothèque de bas niveau, vous verrez que l’assembleur est plus utilisé que certains le pensent.
Et c’est la ou les bons compilateurs C/C++ ont une autre supériorité, celle de permettre d’écrire de l’assembleur directement.
Mais également, certaines aides permettent d’écrire de l’assembleur de manière portable. Ce qui est très utile, par exemple, quand on veut faire interagir plusieurs thread avec un minimum de pertes de performances.
Enfin, pour finir, les optimisations les plus importantes ne sont pas la ou beaucoup le pensent. Bien souvent, les optimisations les plus rentables sont dans la manière d’architecturer un logiciel. Mais sans connaissance de la programmation bas niveau, il est impossible d’écrire des choses performantes.
(3) Le cas que vous décrivez d’un système multimédia automobile me parait assez symptomatique. Les gens arrivent avec un cahier des charges de dingue sans vouloir mettre les compétences, l’argent, le temps et le matériel adéquat sur la table. Bref, ils veulent tout pour rien et si possible, pour la veille. Ils pensent qu’il suffit de mettre des boites en concurrence pour que la magie du Dieu Marché tout puissant rende possible les exigences les plus folles. Et ils obtiennent au final la merde qu’ils méritent…
Le plus amusant avec l’informatique dans les auto, c’est quand il faut dépanner… et qu'on y colle des gars qui ont un CAP alors que même des ingénieurs s'arrachent parfois les cheveux.
(4) Pour L’amiga, le propos était de démontrer qu’on était loin d’un simple affichage monochrome. Mais si on veut se montrer tatillon, il pouvait afficher ses 4096 couleurs sans bidouilles grâce à plusieurs dispositifs. Le premier, c’est le mode graphique HAM, un mode capable d’afficher 4096 couleurs avec un dispositif de compression assez astucieux. Le second, c’est le copper, un coprocesseur spécialisé capable de placer une valeur dans un registre au moment ou le faisceau d’électrons était à la position de l’écran que l’on souhaite, mais cela sans intervention du processeur.
Maintenant, si on compare avec du matériel moderne, c’est à dire un GPU piloté en DirectX ou OpenGL, c’est devenu plus complexe pour optimiser. Le fait de passer par une API de haut niveau n’est pas toujours une aide. Parfois il faut passer beaucoup de temps pour comprendre pourquoi telle opération est plus lente que telle autre… et que c’est le contraire sur un autre GPU. Mais la démarche n’a pas vraiment changé au final. Le fait de comprendre ce qui se passe à bas niveau permet d’écrire du code de haut niveau performant.
Pour finir, tu dit que ce n’est pas aussi catastrophique que je le pense. Je ne partage pas cet avis. Il suffit de regarder le fiasco de certains gros logiciels publics qui ont du être abandonnés faute de pouvoir simplement en maîtriser les bugs.
Et je suis peut être un vieux con, mais j’en ai mare de voire des softs qui rament pour faire des choses très simple. Des lenteurs, des affichages pas fluides. Tout cela est mauvais d’un point de vue expérience utilisateur.
S’il y a 40 ans on m’avait dit qu’on inventerait toute cette puissance fabuleuse mais qu’on ne ferait que la gaspiller pour au final avoir des interfaces lentes et peu réactives, parfois pire que dans les années 70, ça m’aurait carrément déprimé.
Je me souviendrais toujours du remplacement des vieilles bornes automatiques de billeterie dans les grandes gares parisienne. Le vieux modèle avec son écran tout tremblotant en noir et blanc était rapide. Le nouveau avec son interface graphique était d’une lenteur affligeante. Et les voyageurs devaient faire la queue.
Pour qui a connu l’évolution de cette informatique, il y a vraiment des choses à dire sur les soit disant progrès.
que tu le penses.
