Discussion :

[ManusDei]

j'aimerai bien trouver un cours pour débutant (mais qui qui se complexifie crescendo) qui permet de faire un point sur le matériel qui compose un ordi (processeur, disque dur, Ram, bus....) et qui explique comment un programme utilise ces différents matériels
- lorsqu'on fait un variable ou elle est sauvegardée, pourquoi là et pas ailleurs... quand on écrit sur le disque pourquoi c'est long...
- j'aimerai bien aussi comprendre c'est quoi un bus, un temps de latence, de la mémoire cache, pourquoi il y en a plusieurs.... pourquoi on a plusieurs petits processeurs plutôt qu'un seul plus gros....etc

Pour te donner quelques chiffres, le temps nécessaire pour accéder à une donnée dans la mémoire cache est de l'ordre de quelques nano-secondes. Dans la mémoire RAM, c'est plusieurs dizaines de nanosecondes. Dans le disque-dur, c'est plus long.

C'est un ordre de grandeur, car ces différentes valeurs sont différentes selon le processeur, la mémoire RAM, et le chaque disque dur

Et pour faire une (très grosse) simplification (il y a d'autres facteurs), c'est plus rapide de trouver une donnée dans un cache de 1Mo que dans un disque dur de 100Go car tu c'est plus rapide de trouver un boulon particulier dans un petit sac que dans un camion.

Edit : J'ai simplifié pour éviter qu'il pose des questions sur les différentes technologies (pourquoi on fait pas un cache de 100Go si ça va plus vite qu'un disque dur ?) avant d'avoir la base.

[therwald]

c'est plus rapide de trouver une donnée dans un cache de 1Mo que dans un disque dur de 100Go car tu c'est plus rapide de trouver un boulon particulier dans un petit sac que dans un camion.

Il y a d'autres facteurs qui dominent largement le problème e la taille. Un disque de 100Go a de forte chance d'être un disque dur mécanique et non SSD. Or c'est infiniment plus long de déplacer une tête de lecture physiquement que de sélectionner un registre électronique, même parmi un grand nombre. (La preuve étant que les SSD (clefs USB, "disques durs" SSD) sont nettement plus rapides que les disques durs mécaniques pour des tailles comparables.

[koala01]

Il y a d'autres facteurs qui dominent largement le problème e la taille. Un disque de 100Go a de forte chance d'être un disque dur mécanique et non SSD. Or c'est infiniment plus long de déplacer une tête de lecture physiquement que de sélectionner un registre électronique, même parmi un grand nombre. (La preuve étant que les SSD (clefs USB, "disques durs" SSD) sont nettement plus rapides que les disques durs mécaniques pour des tailles comparables.

Et encore, si on veut être tout à fait complet, il faut prendre en compte les caractéristiques du chemin parcouru par les données quand elles doivent aller d'un périphérique à l'autre (en considérant le processeur comme un périphérique pour le coup).

Il faut comprendre que les données au niveau d'un ordinateur ne sont jamais que des successions de 1 et de 0 : le courent passe ou il ne passe pas.

Chaque "partie du système" (le processeur, la RAM ou le support quelconque, le trajet suivi par les information) est susceptible de fonctionner à une fréquence donnée, ou, si tu préfères, pendant un certain temps qui correspond à la division d'une seconde par la valeur de la fréquence (on parle de "cycle").

Si tu as une succession aléatoire de 5 valeurs (0 ou 1) qui doit passer par une même broche, par un même cable (ou équivalent), il faudra 5 cycles minimum pour arriver à faire "passer" les cinq valeurs par le cette broche ou ce cable.

La transmission des données est donc limité à la capacité maximale du "système" le plus lent par lequel elles doivent transiter.

C'est un peu comme si deux tronçons d'autoroutes à cinq bandes étaient reliés entre eux par une route à voie unique limitée à 30 km à cause de la présence d'une école: sur le tronçon "d'entrée", il y a beaucoup de voitures qui peuvent arriver très vite en même temps, mais elles seront toutes "bloquées" à la fin du premier tronçon par le fait qu'il n'y a qu'une voiture qui peut passer, à vitesse très réduite, sur la petite route.

Le deuxième tronçon ne sera donc jamais utilisé au maximum de sa capacité, simplement parce que le nombre de voitures qui arrive dessus est limité, et ce, même si elles peuvent de nouveau rouler à 120km/h.

C'est pour cela qu'il arrive régulièrement qu'un ordinateur donné, bien qu'il dispose du meilleur processeur et de la meilleure RAM possible mais "mal équilibrés" du fait de la vitesse à laquelle les données peuvent transiter de l'un à l'autre, est parfois plus lent et moins performant qu'un autre ordinateur, utilisant un processeur et de la RAM un peu plus lents, mais plus adaptés à la vitesse à laquelle les données peuvent transiter de l'un à l'autre.

Et c'est pour cela qu'un disque dur prévu pour être branché sur un port USB3 ne présentera jamais qu'un taux de transfert équivalent à l'USB1 s'il est branché sur un tel port, ou qu'une clé USB1 ne présentera jamais de taux de transfert supérieur à ce qu'on peut attendre de la part de l'USB1, même si elle était branchée sur un port USB3.

En un mot comme en cent : la capacité maximale de toute chaine n'est jamais supérieure à la capacité maximale du maillon le plus faible

Tout cela pour bien te faire comprendre que l'on peut épiloguer pendant 106 ans sur "ce qui est plus rapide qu'autre chose", on en reviendra toujours au même point : il y a (beaucoup) trop de facteurs à prendre en ligne de compte pour pouvoir se faire une idée précise autre que "au coup par coup".

Le seul point sur lequel le développeur C++ a réellement le contrôle (en dehors d'une organisation des données qui permette une mise en cache plus efficace) est l'algorithme utilisé pour obtenir le résultat escompté.

Tu peux décider de passer par Berlin, Londres, Varsovie et Vladivostok pour aller de Bruxelles à Paris, mais cela te prendra beaucoup plus de temps pour le faire que si tu décidais d'aller de Bruxelles à Paris "en ligne droite".

Le reste, c'est de l'optimisation prématurée, qui ne doit être envisagée qu'à partir du moment où:

• tu es sur d'avoir le "meilleur" algorithme qui soit
• tu as une application fonctionnelle
• tu as fais des tests pour évaluer clairement l'endroit qui pose des problèmes de performances.

Il existe d'ailleurs une règle empirique qui dit que l'on passe 80% du temps d'exécution sur 20% du code.

Cela signifie que tu n'auras qu'un bénéfice très limité à essayer d'optimiser (autrement que par de meilleurs algorithmes) 80% de ton code

[membreComplexe12]

merci tous pour ces compléments
je vais lire un bouquin là dessus un de ces quatre et regarder la documentation que vous m'avez énoncée.
encore merci
A bientôt