Il y a un autre cas où la gestion directe est quasiment indispensable: pour le temps-réel et tout ce qui s'en rapproche. Par exemple un synthé audio, ou bien un moteur de rendu pour un jeu.
Alors en temps réel "dur" : ie garantie de temps de réponse (j'appuie sur le bouton et dans moins de cent cycles CPU il se passe quelquechose) le plus souvent oui. Encore que généralement pour faire du vrai temps réel dur il faut un kernel temps réel, ce qui implique pas mal de choses au niveau de l'architecture de l'OS lui même et du matériel sous-jacent.
Mais en temps réel "mou" : ie garantie de temps d'éxecution (j'ai 200 threads qui tournent, je veux que tous les calculs soient finis dans 200ms) ca devient beaucoup plus discutable. En effet au niveau allocation mémoire les questions de type "ai-je le temsp de lancer un appel système pour libérer l'espace mémoire ?", "dois-je défragmenter la mémoire pour gagner des perfs ?", "puis-je utiliser un segment mémoire déjà dispo mais trop grand pour moi, ou dois-je en reserver un autre ?" etc. sont légions. Et très vite le besoin d'un arbitre se fait sentir (ben oui 200 threads qui discutent les uns avec les autres au niveau perf c'est moyen...). Et le garbage collector, quand il est bien conçu (et conçu dans cette optique) est un arbitre absolument fantastique. Avec la multiplication des coeurs (et donc des threads) je suis prèt à parier qu'il va devenir de plus en plus dur pour les programmeurs C de battre les GC dans une optique temps réel mou. Donc les jeux et les logiciels d'édition musicale risquent d'avoir recours à des GC de plus en plus souvent.
[^] # Re: Fausse idée sur les garbages collectors
Posté par Jerome Herman . En réponse au journal Encore une histoire de récupérateur de mémoire. Évalué à 4.
Alors en temps réel "dur" : ie garantie de temps de réponse (j'appuie sur le bouton et dans moins de cent cycles CPU il se passe quelquechose) le plus souvent oui. Encore que généralement pour faire du vrai temps réel dur il faut un kernel temps réel, ce qui implique pas mal de choses au niveau de l'architecture de l'OS lui même et du matériel sous-jacent.
Mais en temps réel "mou" : ie garantie de temps d'éxecution (j'ai 200 threads qui tournent, je veux que tous les calculs soient finis dans 200ms) ca devient beaucoup plus discutable. En effet au niveau allocation mémoire les questions de type "ai-je le temsp de lancer un appel système pour libérer l'espace mémoire ?", "dois-je défragmenter la mémoire pour gagner des perfs ?", "puis-je utiliser un segment mémoire déjà dispo mais trop grand pour moi, ou dois-je en reserver un autre ?" etc. sont légions. Et très vite le besoin d'un arbitre se fait sentir (ben oui 200 threads qui discutent les uns avec les autres au niveau perf c'est moyen...). Et le garbage collector, quand il est bien conçu (et conçu dans cette optique) est un arbitre absolument fantastique. Avec la multiplication des coeurs (et donc des threads) je suis prèt à parier qu'il va devenir de plus en plus dur pour les programmeurs C de battre les GC dans une optique temps réel mou. Donc les jeux et les logiciels d'édition musicale risquent d'avoir recours à des GC de plus en plus souvent.