Il faut croire à tes explications que, effectivement, je n'ai pas compris la même chose que toi. Je n'ai pas encore écouté ton mp4, j'espère que je pourrais l'écouter sous GNU/Linux.
Je suis d'accord que la gestion de la mémoire ce n'est pas simplement faire du malloc/mmap/... mais aussi gérer ses données comme par exemple sa taille ... qui peut dépendre de l'architecture matérielle sous-jacente. je suis d'accord aussi que c'est au langage de gérer au mieux la gestion mémoire en fonction de l'architecture sous-jacente. Mais là, contrairement à ce que tu dis, les langages de haut niveau ne sont pas pour autant mis hors jeu, au contraire...
De plus, ce qui fait gagner la majorité des cas en performance, c'est l'optimisation globale et non locale.
Et sur ce point, un certain nombre de langages de haut niveau gère très bien cela, et surtoût mieux que nous pourrions le faire dans la plupart des cas. Je m'explique sur ce point. Dans des applications complexes, tu peut effectivement avec un langage de bas niveau optimiser un certain nombre de choses, mais cette optimisation se fait localement et non globalement ; autrement dit, tu as optimisé les parties de l'application qui finalement ne seront peut-être utiles que dans 20% dans le meilleur des cas tout simplement parce que ton application est trop complexe pour avoir un aperçu globale de ces optimisations (leur pertinence, etc.). Le tout se durcit si en plus ton application doit être multi-plateforme : la particularité de chaque plate-forme doit être prise en compte ! Ceci est particulièrement pertinent avec les SGBDR.
Faire de l'optimisation pour faire de l'optimisation ne sert à rien ! L'optimisation est un moyen, pas un but en soit.
Au jour d'aujourd'hui, les compilateurs de certains langages haut niveau (malheureusement pas ceux que l'on utilise au quotidien) ont atteint une grande maturité et permettent d'écrire des programmes multi-plateforme d'une grande efficacité, en tout plus éfficace et bug free que si on avait à les écrire en optimisant nous même avec un langage de bas niveau (qu'il soit ou non équipé d'un compilateur performant). Et le progrès de ce côté là continue.
Par contre, je suis d'accord que ce n'est pas parce que ton langage, ton framework ou autre permet d'optimiser globalement ton appli en fonction de l'architecture sous-jacente que tu dois pour autant ne pas te préoccuper dans certains cas des problématiques d'optimisation de ton code. De la même façon, ce n'est pas parce que tu programmes avec un langage de bas niveau (donc soit disant plus performant) ou de haut niveau (il sait faire les optimisations mieux que moi) que tu dois choisir des technos ou faire une conception à chier qui finalement conduit à produire un bousin (souvent parce que c'est la mode).
[^] # Re: La memoire goulot d'etranglement
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Comment résoudre la "crise du logiciel" ?. Évalué à 3.
Je suis d'accord que la gestion de la mémoire ce n'est pas simplement faire du malloc/mmap/... mais aussi gérer ses données comme par exemple sa taille ... qui peut dépendre de l'architecture matérielle sous-jacente. je suis d'accord aussi que c'est au langage de gérer au mieux la gestion mémoire en fonction de l'architecture sous-jacente. Mais là, contrairement à ce que tu dis, les langages de haut niveau ne sont pas pour autant mis hors jeu, au contraire...
De plus, ce qui fait gagner la majorité des cas en performance, c'est l'optimisation globale et non locale.
Et sur ce point, un certain nombre de langages de haut niveau gère très bien cela, et surtoût mieux que nous pourrions le faire dans la plupart des cas. Je m'explique sur ce point. Dans des applications complexes, tu peut effectivement avec un langage de bas niveau optimiser un certain nombre de choses, mais cette optimisation se fait localement et non globalement ; autrement dit, tu as optimisé les parties de l'application qui finalement ne seront peut-être utiles que dans 20% dans le meilleur des cas tout simplement parce que ton application est trop complexe pour avoir un aperçu globale de ces optimisations (leur pertinence, etc.). Le tout se durcit si en plus ton application doit être multi-plateforme : la particularité de chaque plate-forme doit être prise en compte ! Ceci est particulièrement pertinent avec les SGBDR.
Faire de l'optimisation pour faire de l'optimisation ne sert à rien ! L'optimisation est un moyen, pas un but en soit.
Au jour d'aujourd'hui, les compilateurs de certains langages haut niveau (malheureusement pas ceux que l'on utilise au quotidien) ont atteint une grande maturité et permettent d'écrire des programmes multi-plateforme d'une grande efficacité, en tout plus éfficace et bug free que si on avait à les écrire en optimisant nous même avec un langage de bas niveau (qu'il soit ou non équipé d'un compilateur performant). Et le progrès de ce côté là continue.
Par contre, je suis d'accord que ce n'est pas parce que ton langage, ton framework ou autre permet d'optimiser globalement ton appli en fonction de l'architecture sous-jacente que tu dois pour autant ne pas te préoccuper dans certains cas des problématiques d'optimisation de ton code. De la même façon, ce n'est pas parce que tu programmes avec un langage de bas niveau (donc soit disant plus performant) ou de haut niveau (il sait faire les optimisations mieux que moi) que tu dois choisir des technos ou faire une conception à chier qui finalement conduit à produire un bousin (souvent parce que c'est la mode).