En fait je veux simplement donner quelques éléments sur ce qu'on appelle la mémoire cache. (en fait il y en a plusieurs types)
Dans un ordinateur, il y a le processeur.
Dans ce processeur, il y a quelques zones mémoires pas très grosses (quelques Ko) mais d'accès ultra rapide : les registres.
Un peu "plus loin", et moins rapide d'accès, il y a des zones mémoires (1,2, ou 3 en général) pas très grosses non plus, appelées mémoires cache.
La première est d'ailleurs souvent implémentée directement dans le processeur (elle est nommée L0)
Encore plus loin, et encore moins rapide d'accès, il y a la RAM.
Enfin, encore plus loin, il y a le disque.
Le processeur a une fréquence trop grande, par rapport au temps d'accès à la RAM pour qu'il puisse lire à chaque cycle horloge un octet de la RAM par exemple.
De ce fait, la mémoire cache sert de tampon (une zone transitoire) entre le processeur et la RAM.
Ainsi, sans parler encore du disque, pour des programmes utilisant beaucoup de variables ou de mémoire, la limitation de vitesse d'exécution est plus due au temps d'accès à la RAM qu'à la fréquence du processeur.
En fait, pour un programme donné, avec son algorithme, pour optimiser sa vitesse, il faut au maximum limiter les échanges RAM/cache.
Ce qu'il faut savoir aussi, c'est que lorsque le processeur va chercher ne serait-ce qu'un octet dans la RAM, en fait il lit tout une "ligne" (minimum 64octets) qu'il transfère dans la mémoire cache.
Mais avant cela, il regarde si la donnée n'est pas déjà dans le cache. Si elle y est déjà, il ne va pas voir la RAM, et l'accès est beaucoup plus rapide.
Le cache étant fini, quand il est plein et qu'il doit charger une nouvelle ligne, il en élimine une plus ancienne évidement.
Et donc, pour optimiser (ce qui ne peut se faire à ce niveau qu'en assembleur je pense), on ne lit pas les données en RAM n'importe comment, dans n'importe quel ordre : après en avoir lue une, on utilise au maximum celles qui ont été chargées en même temps dans le cache.
D'où l'intérêt évidemment de travailler sur des zones mémoires contigües et intelligemment ordonnées, et pas des données eparpillées dans la RAM.
La technique de "prefetching" (prélecture en français) consiste à lire quelques données bien placées dans la RAM, pour faire charger en cache toute une zone dont on a besoin, et travailler avec ces données avant de passer aux suivantes.
On parle aussi de cache concernant la RAM, vis-à-vis de l'accès au disque.
L'accès au disque est lent, et on a tout intérêt à garder en RAM ce dont on a besoin pour faire tourner un programme, plutôt qu'aller les chercher à longueur de temps sur le disque.
Ainsi, pour comparer deux fichiers par exemple, si on charge totalement les fichiers en RAM (readdata(#file,*mem)) et qu'on travaille avec les zones mémoires, ça va plus vite que de faire des boucles avec des "readstring()" par exemple. Quand je dis plus vite, ça peut être sans exagération plusieurs milliers de fois plus vite. (j'ai testé avec des fichiers de 30Mo, et j'ai des résultats de cet ordre)
Et si on se place au dessus du niveau d'un programme, ie au niveau du système, un des grands problèmes, qui donne lieu à de nombreuses recherches, c'est de savoir ce qu'on garde en RAM.
C'est peut-être le problème majeur concernant l'amélioration des systèmes : la détermination d'algorithmes gérant la RAM.
Bon, je vais me coucher
(ma crise de mégalomanie est passée !)J'espère que j'ai pas dit trop bétises.
J'invite ceux qui ont des précisions à donner, d'autres problèmes du genre à exposer à le faire ici.
Même si c'est pas du code, c'est bon à savoir pour régler les problèmes quand un programme galère...
D'ailleurs, je propose à ceux que ça intéresse de mettre ici des codes faisant la même chose différemment pour mettre en évidence les différences de vitesse d'exécution.