Il faut remarquer que la taille des "problèmes" à résoudre augmente aussi. La "puissance" de calcul brute augmente vite (supposons qu'elle est proportionnel au nombre de transistors, qui d'après la loi de Moore double tous les deux ans), mais les choses qu'on demandent augmentent aussi. Bon évidemment, c'est assez dépendant de l'application, mais beaucoup de problèmes ne peuvent pas voire augmenter leur taille aussi vite que la puissance de calcul.
Si un problème est de complexité O(n), on peut le doubler quand la puissance de calcul double. S'il est de complexité O(n2), on ne peut doubler la taille pour un même temps de calcul que lorsqu'on quadruple la puissance de calcul.
Alors évidement, la plupart des applications de tous les jours ne font pas de calcul intensif, mais par exemple le nombre de pixel qu'un programme doit afficher a tendance à quadrupler quand la taille (en nombre de pixels dans une direction) double. C'est pas nécessairement intensifs en calculs (ça dépend de ce qu'on veut afficher, et puis si c'est "complexe" et "3D" ce sera fait en partie par le GPU), mais on trouve ce genre de trucs un peu partout.
Après à la limite ça va dans ton sens, sur la partie "les applications aujourd'hui sont des trucs imbriqués dans tous les sens" (si j'ose résumé comme ça) parce qu'on gagne plus en vitesse si on utilise le meilleur algo connu en O(np) et pas celui plus simple en O(nq) avec q > p. (Enfin ça dépend de n et de la constante cachée dans le O.) Donc un développeur qui connait (ou se renseigne) son domaine et qui utilise le bon algo dans un truc à l'archi compliqué pourra (peut-être) faire un programme plus rapide qu'un développeur qui fera une archi plus simple mais avec un moins bon algo. Le mieux étant probablement l'archi simple avec le bon algo, mais ça demande du temps (et de l'investissement.)
C'est plus simple de passer de 4 Go de ram à 24Go pour pouvoir dire "ouais, il y a peut-être une fuite mémoire, mais bon, avec 24Go de ram vous aurez de la marge, faudra surement redémarrer l'appli pour une maj avant que la fuite n'ait tout pris." (à peu près l'idée d'un truc qui a été fait ici… /o\)(je suis l'utilisateur pas le dev, mais en même temps je suis nul en IHM donc je ne critique pas trop)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
# Complexité
Posté par 2PetitsVerres (Mastodon) . En réponse au journal De l'inéluctable progrès de l'informatique, ou pas.. Évalué à 5.
Il faut remarquer que la taille des "problèmes" à résoudre augmente aussi. La "puissance" de calcul brute augmente vite (supposons qu'elle est proportionnel au nombre de transistors, qui d'après la loi de Moore double tous les deux ans), mais les choses qu'on demandent augmentent aussi. Bon évidemment, c'est assez dépendant de l'application, mais beaucoup de problèmes ne peuvent pas voire augmenter leur taille aussi vite que la puissance de calcul.
Si un problème est de complexité O(n), on peut le doubler quand la puissance de calcul double. S'il est de complexité O(n2), on ne peut doubler la taille pour un même temps de calcul que lorsqu'on quadruple la puissance de calcul.
Alors évidement, la plupart des applications de tous les jours ne font pas de calcul intensif, mais par exemple le nombre de pixel qu'un programme doit afficher a tendance à quadrupler quand la taille (en nombre de pixels dans une direction) double. C'est pas nécessairement intensifs en calculs (ça dépend de ce qu'on veut afficher, et puis si c'est "complexe" et "3D" ce sera fait en partie par le GPU), mais on trouve ce genre de trucs un peu partout.
Après à la limite ça va dans ton sens, sur la partie "les applications aujourd'hui sont des trucs imbriqués dans tous les sens" (si j'ose résumé comme ça) parce qu'on gagne plus en vitesse si on utilise le meilleur algo connu en O(np) et pas celui plus simple en O(nq) avec q > p. (Enfin ça dépend de n et de la constante cachée dans le O.) Donc un développeur qui connait (ou se renseigne) son domaine et qui utilise le bon algo dans un truc à l'archi compliqué pourra (peut-être) faire un programme plus rapide qu'un développeur qui fera une archi plus simple mais avec un moins bon algo. Le mieux étant probablement l'archi simple avec le bon algo, mais ça demande du temps (et de l'investissement.)
C'est plus simple de passer de 4 Go de ram à 24Go pour pouvoir dire "ouais, il y a peut-être une fuite mémoire, mais bon, avec 24Go de ram vous aurez de la marge, faudra surement redémarrer l'appli pour une maj avant que la fuite n'ait tout pris." (à peu près l'idée d'un truc qui a été fait ici… /o\)(je suis l'utilisateur pas le dev, mais en même temps je suis nul en IHM donc je ne critique pas trop)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.