Aujourd'hui et dans un futur proche, les machines vont être beaucoup plus difficile à programmer correctement.
En effet, la RAM est "loin" du CPU. C'est à dire qu'un algo correcte prend en compte le fait que la RAM est "loin" et qu'en fait il doit considérer les différents niveaux de la mémoire cache.
Histoire de compliquer la tâche encore plus, nos CPU sont maintenant mutli-cœurs et embarquent un contrôleur de mémoire (pour les design modernes, Intel est à la bourre mais AMD est à l'heure sur ce sujet). Donc pour les algo vraiment intensifs il s'agit de considérer cette dimension (et je ne parle pas des pages de mémoire virtuelle and co).
Le lead de la glibc Ulrich Drepper a fait un bon papier qui illustre par la pratique une partie de ce que je viens de dire: http://lwn.net/Articles/259710/
Les architectures sont tellement comlexes aujourd'hui qu'un des seuls moyens d'avoir un bon algo dans un context technique bien précis, c'est d'utiliser les outils d'instrumentation.
Donc à vos valgrind et oprofile.
# Tout mauvais...
Posté par GPL . En réponse au journal Lisaac plus rapide que le C !. Évalué à 5.
En effet, la RAM est "loin" du CPU. C'est à dire qu'un algo correcte prend en compte le fait que la RAM est "loin" et qu'en fait il doit considérer les différents niveaux de la mémoire cache.
Histoire de compliquer la tâche encore plus, nos CPU sont maintenant mutli-cœurs et embarquent un contrôleur de mémoire (pour les design modernes, Intel est à la bourre mais AMD est à l'heure sur ce sujet). Donc pour les algo vraiment intensifs il s'agit de considérer cette dimension (et je ne parle pas des pages de mémoire virtuelle and co).
Le lead de la glibc Ulrich Drepper a fait un bon papier qui illustre par la pratique une partie de ce que je viens de dire:
http://lwn.net/Articles/259710/
Les architectures sont tellement comlexes aujourd'hui qu'un des seuls moyens d'avoir un bon algo dans un context technique bien précis, c'est d'utiliser les outils d'instrumentation.
Donc à vos valgrind et oprofile.