Aucun ordinateur ne peut garantir une exécution dans un temps donné, parce que tout simplement il ne le peut pas physiquement. La seule chose qu'un processeur peut éventuellement garantir, c'est le nombre de ticks processeurs qui seront alloués à une instruction. Et c'est en comptant ces ticks par instruction qu'on peut déterminer en combien de ticks un programme peut s'exécuter. Cela permet de calculer un temps statistique d'exécution, mais il ne pourra pas être garanti avec précision.
Ce que tu appelle du RT mou, ce n'est pas du RT. C'est une exécution sous contrainte de temps, mais ça n'a rien à voir avec une quelconque garantie.
C'est gentil de dire que je raconte n'importe quoi pour ensuite me paraphraser. Quand je dis « Il sait simplement qu'un .C va être compilé en .o », ça veut bien dire qu'il va vérifier le ctime du .C et lui appliquer une commande pour le transformer en .o. Je n'excluait pas d'autres suffixes.
J'aime la fiabilité. C'est énervant quand un programme est lent, mais c'est la panique quand il tombe en marche pour aller plus vite. En l'occurrence, j'ai bien déjà tenté d'utiliser les mécanismes de génération de dépendance, mais il faut bien avouer que ça ne fonctionne pas toujours. Je préfère quand ça ne marche jamais, ou quand ça marche tout le temps, je déteste l'entre-deux plein de terreur, plein de sombritude. Mais si tu as une ressource qui peut m'aider, tu es le bienvenue (et non, je ne replongerais pas dans autoshit, je tiens à conserver ma santé mental :D ).
[^] # Re: allocation à l'arrache
Posté par LupusMic (site web personnel, Mastodon) . En réponse à la dépêche Je crée mon jeu vidéo E01 : les systèmes à entités. Évalué à 2.
Aucun ordinateur ne peut garantir une exécution dans un temps donné, parce que tout simplement il ne le peut pas physiquement. La seule chose qu'un processeur peut éventuellement garantir, c'est le nombre de ticks processeurs qui seront alloués à une instruction. Et c'est en comptant ces ticks par instruction qu'on peut déterminer en combien de ticks un programme peut s'exécuter. Cela permet de calculer un temps statistique d'exécution, mais il ne pourra pas être garanti avec précision.
Ce que tu appelle du RT mou, ce n'est pas du RT. C'est une exécution sous contrainte de temps, mais ça n'a rien à voir avec une quelconque garantie.
C'est gentil de dire que je raconte n'importe quoi pour ensuite me paraphraser. Quand je dis « Il sait simplement qu'un .C va être compilé en .o », ça veut bien dire qu'il va vérifier le ctime du .C et lui appliquer une commande pour le transformer en .o. Je n'excluait pas d'autres suffixes.
J'aime la fiabilité. C'est énervant quand un programme est lent, mais c'est la panique quand il tombe en marche pour aller plus vite. En l'occurrence, j'ai bien déjà tenté d'utiliser les mécanismes de génération de dépendance, mais il faut bien avouer que ça ne fonctionne pas toujours. Je préfère quand ça ne marche jamais, ou quand ça marche tout le temps, je déteste l'entre-deux plein de terreur, plein de sombritude. Mais si tu as une ressource qui peut m'aider, tu es le bienvenue (et non, je ne replongerais pas dans autoshit, je tiens à conserver ma santé mental :D ).