Je crois que effectivement tu n'as pas saisi de quoi je parlais. La problematique principale de la gestion de la memoire, c'est que souvent on alloue de la memoire sans regarder quand et comment on l'utilise. Normal il n'y a pas de moyen natif au niveau d'aucun langage connu qui permet d'exprimer ca, encore moins au niveau de l'OS.
Or on alloue quand meme de la memoire pour l'utiliser et c'est l'utilisation qui compte. Si tes donnees au moment ou tu les utilises sont completement disperse en memoire (fragmente) et non aligne, et bien tu vas facilement te prendre un facteur 100 voir de plus en plus grand avec le temps puisque le rapport entre la vitesse du CPU et la latence memoire a tendance a grandir.
Et pour optimiser quelque chose, il n'y a qu'un seul moyen que lorsque tu compiles, tu compiles l'integralite de ton univers (ou en tout cas tout ce qui produit et utilise de la memoire, ce qui revient au meme). A ma connaissance, seul l'eiffel peu proposer se genre de mecanisme. Maintenant j'ai de gros doute qu'ils aient implemente la capacite a changer les algorithmes et les structures memoires pour optimiser de maniere globale ton programme.
Et contrairement a ce que tu dis, si tu arrives a faire cette optimisation globale, tu aura un gain collossal souvent sous estime. Maintenant, si tu choisis un langage qui ne te permettra jamais d'optimiser ton application (en gros qui ne te donne pas la main sur la manipulation memoire), il va arriver un moment ou tu vas te dir que entre rajouter une nieme fonction avec peu de demande ou optimiser ton appli pour qu'elle tourne mieux sur de petite machine, c'est l'optimisation que tu vas choisir. Et la soit tu peux faire des optims globales qui payent (et l'optimisation memoire ca paye bien), soit tu ne peux pas. Et dans ce cas, si tu es en competition avec des gens qui eux le peuvent, tu devra tout redevelopper. Autant dire que tu vas perdre sur le long terme.
C'est pourquoi d'apres moi les langages qui ne permettent pas ce genre d'optimisation doivent rester cantonner sur du RAD sans interet sur le long terme. D'ailleur ca explique le peu de prise des langages dit haut niveau dans le domaine du libre, ou une bonne partie des developpeurs aime bien optimiser (et oui, pour certain c'est un but...). Maintenant dans l'industrie, je veux bien croire que les productions a court terme sont plus importante, mais ils finiront toujours par ce faire depasser.
[^] # Re: La memoire goulot d'etranglement
Posté par cedric . En réponse au journal Comment résoudre la "crise du logiciel" ?. Évalué à 9.
Or on alloue quand meme de la memoire pour l'utiliser et c'est l'utilisation qui compte. Si tes donnees au moment ou tu les utilises sont completement disperse en memoire (fragmente) et non aligne, et bien tu vas facilement te prendre un facteur 100 voir de plus en plus grand avec le temps puisque le rapport entre la vitesse du CPU et la latence memoire a tendance a grandir.
Et pour optimiser quelque chose, il n'y a qu'un seul moyen que lorsque tu compiles, tu compiles l'integralite de ton univers (ou en tout cas tout ce qui produit et utilise de la memoire, ce qui revient au meme). A ma connaissance, seul l'eiffel peu proposer se genre de mecanisme. Maintenant j'ai de gros doute qu'ils aient implemente la capacite a changer les algorithmes et les structures memoires pour optimiser de maniere globale ton programme.
Et contrairement a ce que tu dis, si tu arrives a faire cette optimisation globale, tu aura un gain collossal souvent sous estime. Maintenant, si tu choisis un langage qui ne te permettra jamais d'optimiser ton application (en gros qui ne te donne pas la main sur la manipulation memoire), il va arriver un moment ou tu vas te dir que entre rajouter une nieme fonction avec peu de demande ou optimiser ton appli pour qu'elle tourne mieux sur de petite machine, c'est l'optimisation que tu vas choisir. Et la soit tu peux faire des optims globales qui payent (et l'optimisation memoire ca paye bien), soit tu ne peux pas. Et dans ce cas, si tu es en competition avec des gens qui eux le peuvent, tu devra tout redevelopper. Autant dire que tu vas perdre sur le long terme.
C'est pourquoi d'apres moi les langages qui ne permettent pas ce genre d'optimisation doivent rester cantonner sur du RAD sans interet sur le long terme. D'ailleur ca explique le peu de prise des langages dit haut niveau dans le domaine du libre, ou une bonne partie des developpeurs aime bien optimiser (et oui, pour certain c'est un but...). Maintenant dans l'industrie, je veux bien croire que les productions a court terme sont plus importante, mais ils finiront toujours par ce faire depasser.