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