Définir l'accélération - Page 1

En physique quand on prend un élément en mouvement, il peut se définir (entre autres) par sa position, sa vitesse et son accélération.

Si on prend un programme lambda, sans interaction avec l'extérieur (pas de prompt utilisateur). Par exemple un calcul de Pi. Sa position serait un snapshot de l'état de l'ensemble de la machine (ram, rom, électrons en cours de mouvement...). La direction définissant le sens vers lequel va un élément (un vecteur simple), on pourrait parler de direction dans un programme, qui permet de déterminer l'instruction suivante (on a la connaissance de la succession des instructions qui définissent le programme). La vitesse serait liée à la vitesse de passage d'une étape d'exécution à une autre.

Comment définiriez-vous la notion d'accélération pour un programme ?
(étant la dérivée de la vitesse)
Comment la mettre en évidence, comment l'utiliser ?

Et pour lancer le sujet

!call Godzil
--- Call : Godzil appelé(e) sur ce topic ...
Il est assez fort en physique je crois.

kim (./1) :
Comment définiriez-vous la notion d'accélération pour un programme ?

Ben heu... puisque tu définis ta notion de position ("Sa position serait un snapshot de l'état de l'ensemble de la machine (ram, rom, électrons en cours de mouvement...)"), l'accélération est simplement la dérivée seconde de cette position
Si tu n'arrives pas à calculer cette accélération, c'est que ta notion de position est mal exprimée. Il faut la mettre en équation, et à partir de là, plus de pb

Oula faut arreter la fumette

Note : je n'ai ni bu, ni fumé, ni pris une quelconque drogue en pensant ça, c'était pendant que je mangeais mon boudin aux pommes que j'y ai pensé

C'est quoi la marque de ton boudin ??

deja tu sais avant de vouloir etudier un systeme il faut pouvoir le caracteriser. Tu ne sais meme pas quelle vitesse tu veux exprimer, or il peut y en avoir beaucoup...

./7 : le problème n'est pas là
./8 : une vitesse c'est la caractérisation d'un temps de déplacement d'un état à un autre différent. Tu peux définir un état comme un snapshot de l'univers contenant l'ensemble du système et ses variables. La différence peut être vue de plusieurs manières mais principalement par le nombre d'éléments ayant changé d'état. Après c'est qu'une vision des choses, mais si tu as une meilleure proposition...

kim (./8) :
./7 : le problème n'est pas là

Ben moi je pense aussi que si (cf ./3)

Bein si le probleme n'est pas la il n'y a pas de probleme

Bah, déjà la vitesse comme tu la définis existe, mais n'a aucun intérêt pratique, quand on parle de "vitesse" en informatique, on désigne en général une fréquence, l'inverse du temps d'exécution (du programme entier, pas juste d'une instruction).

On pourrait définir l'accélération exactement de la manière de laquelle tu as défini la vitesse, mais ça ne correspond encore plus à rien (Qu'est-ce qu'on en a à battre si on passe d'une instruction lente à une rapide? C'est le temps d'exécution total qui compte!). Le seul concept d'accélération utile en pratique est le speedup: la réduction du temps d'exécution, soit absolu (-∆t), soit relatif (-∆t/t₀). Comme pour la "vitesse", ça n'a plus rien à voir avec l'accélération d'une particule.

./11 : j'ai jamais dit que c'était utile de connaître ce genre de données, je pose juste la question de l'existence.
Cela dit, vue la direction que tu sembles vouloir prendre dans ton post, je dirais que ça pourrait avoir une utilité. L'accélération étant une variation de vitesse, on peut parfois avoir besoin de ralentir une exécution de manière "uniforme" (une décélération quoi). Exemple con : ntpdate quand on change d'heure : un changement brusque est mauvais, c'est connu.

L'accélération dans le même sens que ta vitesse existe, il faut juste continuer la dérivation discrète, tu peux même continuer avec la variation de l'accélération, la variation de cette variation etc. C'est juste l'utilité que je ne vois pas.

C'est juste une question que se pose kim, pour le fun. Arrête de chercher de l'utilité partout

est-ce que la recherche de l'utilité est vraiment utile ?

heu la vous parlez d'une vitesse moyenne qui est caracterisée par la variation d'un ensemble de parametres qui n'ont aucun sens. D'ailleur je peux te trouver une vitesse nulle avec ces etats la alors que le programme peut tout a fait tourner.

sauf que le temps, lui,aura changé, et donc ton état aura changé, il y a bien variation.

heu tu sais tu restes assis sur ta chaise, le temps passe et ta vitesse relative au sol est nulle lol.

Vu que j'ai été appelé je vais donner mon point de vue, que d'autre (hippo ? spectras ?) détailleront sans doute par la suite.


Soit une machine considérée comme N (grand) éléments "atomique" capables d'opérations simples.

Ces éléments tous assemblés constituent le processeur qui va séquencer l'exécution d'un programme.

La vitesse du programme est donc définie par le nombre de ses instructions traitées en un nombre fixe de cycles du processeur.

La position, est bien entendu le rang donné à un instant T dans la séquence que constitue le programme.

L'accélération ou la décélération peut être définie de deux manières (peut être plus mais deux me viennent à l'esprit comme ça):
1) L'augmentation (ou la diminution) du nombre de cellules allouées au programme par le processeur (augmentation permise par exemple par la finalisation d'un traitement qui libère des cellules)
2) Les opérations d'anticipation qui permettent de réduire le temps d'un traitement traitement sur une cellule.

Contrairement à ce que Kevin peut avancer, l'accélération est souvent cruciales en grosses structures d'entreprise. L'exemple le plus évident à comprendre est ce qu'on appelle le load balancing dynamique, c'est à dire la répartition sur plusieurs "moteurs" (que ce soit du réseau, du cpu, du disque...) de la charge avec une évolution dynamique ET intelligente permettant des croissances décroissances de vitesse d'exécution en fonction des priorités et des répartitions/utilisations par process simultanés.

Ca a un impact direct sur la réduction des coûts et la "mode" des multicoeurs pour les CPU ou des serveurs par partitionnement virtualisé (l'inverse d'un cluster, N serveurs virtuels sur une machine physique) mettent en évidence l'importance de la gestion de l'accélération/décélération des process lors de leur répartitions respectives...

Et pour le clin d'oeil à un autre topic, on ne parle pas d'une demi ou de trois secondes mais d'un batch qui pourra ne durer qu'une journée au lieu d'une semaine quand il restait cloisonné sur un nombre fixe de cellules...

heu je veux bien mais faut preciser à quelle echelle tu te mets parce que l'acceleration au niveau du processeur n'implique pas forcement une acceleration au niveau applicatif et vis versa.

oula je doit être fatigué, j'arrive pas a lire le moindre des pavés du topic (je tenterais de répondre à sa, à tête reposé)

Ou alors on peut avoir une autre définition amusante, pour lequel la position est un vecteur composé de l'ensemble des systèmes à états contenus dans ta machine.
Ca peut s'étudier sur un système de Turing, mais le souci que tu vas avoir c'est que théoriquement tu as un vecteur d'une infinité de composantes.

Par ailleurs, je suis pas convaincu que la notion de vitesse ait un sens en temps discret ?
(Sachant que même en temps continu, ta position n'est pas dérivable).

Ben pour pouvoir définir une vitesse il suffit de définir une distance sur l'ensemble des positions (donc il faut évidemment commencer par définir l'ensemble des positions), si ton temps est discret (donc ton système est caractérisé par une suite de positions), la vitesse v_n au temps n peut être définie comme la distance entre les positions P_n et P_n+1, et ensuite l'accélération ben c'est tout simplement v_n+1–v_n ^^

./1 > remarque que ce que tu dis ne permet pas vraiment de définir une accélération (si j'ai bien compris), parce qu'il s'agit d'une vitesse moyenne sur des intervalles variables :
en effet au lieu d'avoir un temps régulier (une succession d'instants également espacés) où à chaque instant tu as une position donnée et où il faut définir la distance entre deux positions, j'ai l'impression que tu suggères que chaque étape de l'exécution correspond à une position et que la distance entre deux positions est fixe, c'est alors le temps mis pour passer d'une position à la suivante qui est variable. Donc tu as une vitesse moyenne du système entre deux positions consécutives, mais tu n'as pas une vitesse calculée à intervalles réguliers, qui te permettrait de calculer une accélération.

C'est comme si tu prends un train qui doit faire un certain trajet, si toutes les secondes, tu relèves sa position, et tu regardes la distance avec la position précédente, tu obtiens une vitesse (vitesse moyenne sur une seconde, mais c'est à ça que correspond la vitesse instantanée si on travaille en temps discret). Si maintenant tu fais la différence entre deux vitesses consécutives tu obtiens l'accélération instantanée de ton train. Pas de problème.

Mais si au lieu de faire ça, tu regardes le temps écoulé à chaque fois que le train passe dans une gare, tu pourras calculer des vitesses moyennes sur chaque portion de trajet, et tu pourras dire : tiens entre la troisième gare et la quatrième le train est allé en moyenne 10% plus vite qu'entre la deuxième et la troisième, c'est une évolution de la vitesse moyenne, mais on peut pas vraiment appeler ça une accélération ^^

bah si, c'est tout à fait possible, en fait c'est juste l'accélération dont on aurait enlevé les hautes fréquences ^^ (la fréquence de coupure étant plus ou moins élevée selon que le trajet entre les gares est plus ou moins rapide)

Sally (./24) :
Ben pour pouvoir définir une vitesse il suffit de définir une distance sur l'ensemble des positions (donc il faut évidemment commencer par définir l'ensemble des positions), si ton temps est discret (donc ton système est caractérisé par une suite de positions), la vitesse v_n au temps n peut être définie comme la distance entre les positions P_n et P_n+1, et ensuite l'accélération ben c'est tout simplement v_n+1–v_n ^^

tu as défini l'accélération comme la dérivée de la vitesse scalaire, mais c'est pas comme ça qu'on la définit en physique (sinon un changement brusque de direction sans changement de vitesse ne correspondrait pas à un choc) : pour ça il faut pouvoir définir des distances entre différences de positions... mais bon, dans le cas général il n'y a pas de distance qui donnerait une notion d'accélération intéressante, donc c'est un peu idiot ^^

Mais c'est pire que d'avoir enlevé les hautes fréquences puisque c'est la distance entre deux gares consécutives qui est fixe et pas la durée du trajet. Ce que tu dis s'appliquerait si par exemple on mesurait la position toutes les heures, mais là ça peut être complètement irrégulier, donc je ne dis pas qu'on ne peut rien calculer du tout mais je sais pas si on peut calculer quelque chose qui ressemble vraiment à une accélération...

Pour le reste > oui effectivement, je visualisais un mouvement en ligne droite donc j'ai pas pensé à ça ^^

Sally (./27) :
Mais c'est pire que d'avoir enlevé les hautes fréquences puisque c'est la distance entre deux gares consécutives qui est fixe et pas la durée du trajet. Ce que tu dis s'appliquerait si par exemple on mesurait la position toutes les heures, mais là ça peut être complètement irrégulier, donc je ne dis pas qu'on ne peut rien calculer du tout mais je sais pas si on peut calculer quelque chose qui ressemble vraiment à une accélération...

ben si, c'est juste la fréquence de coupure qui varie...