On ne parle pas ici de temps réel, mais de jeux vidéos. C'est bien ce que je reproche un peu à ton propos. Si je voulais faire mon chaint, j'aurais pu commencer à parler des problèmes d'orthogonalité d'un code défini dans le header, inliné dans tous les modules ; des problèmes de compilation qui verrons le jour quand la structure d'une classe sera changée, et que tous les modules l'utilisant ne sont pas recompilé (le problème classique de make qui ne prend pas en compte les en-têtes, car il ne peut pas), etc.
L'overcommit memory est une optimisation acceptable quand la fiabilité n'est pas priomordiale, mais que la vitesse d'exécution l'est. C'est le cas typique d'un jeu vidéo. Je suis cependant moins enchanté lorsque c'est une base de données qui est trompée par l'OS. Sur ce genre de machines, j'aurais tendance à désactiver l'overcommit (en plus de la swap).
[^] # 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.
On ne parle pas ici de temps réel, mais de jeux vidéos. C'est bien ce que je reproche un peu à ton propos. Si je voulais faire mon chaint, j'aurais pu commencer à parler des problèmes d'orthogonalité d'un code défini dans le header, inliné dans tous les modules ; des problèmes de compilation qui verrons le jour quand la structure d'une classe sera changée, et que tous les modules l'utilisant ne sont pas recompilé (le problème classique de make qui ne prend pas en compte les en-têtes, car il ne peut pas), etc.
L'overcommit memory est une optimisation acceptable quand la fiabilité n'est pas priomordiale, mais que la vitesse d'exécution l'est. C'est le cas typique d'un jeu vidéo. Je suis cependant moins enchanté lorsque c'est une base de données qui est trompée par l'OS. Sur ce genre de machines, j'aurais tendance à désactiver l'overcommit (en plus de la swap).