"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."
Et pourtant si tu ne respectes pas tes 30 images/s ton film est illisible, idem pour le son. Pour un jeu, si le temps de réaction est au dessus d'une certaine valeur, c'est injouable. C'est ça le TR mou.
"Cela permet de calculer un temps statistique d'exécution, mais il ne pourra pas être garanti avec précision."
Oui et on s'en contre-fou. On détermine un ou une série de path d'execution long, on prends 50% de marge et c'est bon (avec cache froid, sans appel système, ni lock). Dans la vrai vie.
gcc -MM c'est pas mal. Mais globalement, make, c'est pas top. cmake semble avoir la faveur de beaucoup de monde. si tu as un petit projet, tout recompiler ne prend en général pas trop de temps, non plus.
[^] # Re: allocation à l'arrache
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Je crée mon jeu vidéo E01 : les systèmes à entités. Évalué à 2.
"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."
Et pourtant si tu ne respectes pas tes 30 images/s ton film est illisible, idem pour le son. Pour un jeu, si le temps de réaction est au dessus d'une certaine valeur, c'est injouable. C'est ça le TR mou.
"Cela permet de calculer un temps statistique d'exécution, mais il ne pourra pas être garanti avec précision."
Oui et on s'en contre-fou. On détermine un ou une série de path d'execution long, on prends 50% de marge et c'est bon (avec cache froid, sans appel système, ni lock). Dans la vrai vie.
gcc -MM c'est pas mal. Mais globalement, make, c'est pas top. cmake semble avoir la faveur de beaucoup de monde. si tu as un petit projet, tout recompiler ne prend en général pas trop de temps, non plus.
"La première sécurité est la liberté"