Minecraft disponible sur PSVITA

non-tu-ne-peut-pas-désolé

Pourquoi Minecraft 1.8 est si lent ?

Cela ressemble à un cri de désespoir, ce message que sp614x a posté sur son forum dédié à son Mod Optifine. Il introduit ainsi son discours: “Minecraft 1.8 a tellement de problème de performance que je ne sais pas par quoi commencer”.

sp614x, auteur du célèbre Mod Optifine qui est certainement le mod le plus populaire de Minecraft, réputé pour les améliorations des performances qu’il propose au jeu, sp614x propose aux joueurs de finir le travail que Mojang ne fait pas.

Il y a quelques mois, Mojang avait proposé à sp614x de lui racheter son Mod, ce qu’il a refusé. Une bonne nouvelle pour la communauté, car c’est probablement grâce à lui que Minecraft 1.8 gagnera peut être en performance! Car en créant ce Mod, il a montré ses talents de développeur, et sa réputation l’a suivi jusque chez Mojang qui écoute désormais ses conseils attentivement :-)

————

Le problème principal et le plus horrible avec Minecraft 1.8 est l’allocation mémoire. Actuellement le jeu réserve environ 50Mo de mémoire par seconde lorsque le joueur est immobile, et jusqu’à 200Mo/s en mouvement. C’est juste fou.

Que se passe-t-il lorsqu’un jeu réserve 200 Mo par seconde de mémoire, et la libère immédiatement après ?

1 – Avec la limite par défaut de 1Go (soit 1000 Mo) et une utilisation moyenne de 200Mo chaque seconde, Java est obligé de lancer le garbage collector au moins toutes les 4secondes, sinon la mémoire sera saturé (et le jeu plantera). À 60fps (images par seconde), une image s’affiche en 16ms. Afin de ne pas ralentir le jeu, l’opération ne devrait pas durée plus de 10 à 15ms. Dans un temps minimal, il devra déterminer lesquels parmi la centaine de millier d’objets nouvellement créer en mémoire peuvent être libéré et lesquels ne le peuvent pas. C’est un boulot énorme qui nécessite un processeur très puissant pour le faire en moins de 10ms.

2 – Pourquoi ne pas réserver plus de mémoire ?
Réservons 4Go de RAM à Minecraft. Pour cela vous aurez besoin d’avoir au moins 8Go de mémoire dans votre ordinateur car la mémoire réellement utilisé par le jeu est le double de celle vu par Java. Si la VM décide d’utiliser l’ensemble de la mémoire alloué, cela espacera les cycles du garbage collector (20 secondes au lieu de 4), mais cela augmentera également leur durée par 4, donc toutes les 20 secondes vous auriez un ralentissement.

3 – Pourquoi ne pas utiliser la garbage collection incrémentale ? (ndt: gérer la mémoire en continue)
La dernière version du launcher Minecraft active la gestion de la mémoire en continue par défaut, ce qui en théorie doit remplacer un gros cycle du garbage collector par plein de petits cycles incrémentaux. Le problème c’est que la durée de ces cycles et l’instant de leur exécution est très aléatoire. Cependant ils sont plus court (peut-être 50%) qu’un cycle complet. Cela signifie que les FPS commence a varié de manière aléatoire, et que les joueurs subissent des piques de lag régulier. Un FPS constant avec des piques de lag réguliers ont été remplacé par un FPS variable avec des piques de lag aléatoires. Cette stratégie ne fonctionne que si vous avez un processeur puissant, pour que les piques de lag soit suffisant court pour être imperceptible.

4 – Comment cela fonctionnait dans les Releases précédentes ?
Les versions précédentes étaient beaucoup moins gourmandes en mémoire. Le code original de Notch (jusqu’à la Release 1.3) alloué entre 10 et 20 Mo par seconde, ce qui était beaucoup plus facile à gérer et optimiser. Le rendu à lui seul ne consommait que 1 à 2 Mo par seconde, il était créé spécifiquement pour consommer le moins de ressource possible (réutilisation de buffer, etc.). Avec 200Mo/s on repousse les limites et on force le GC a faire beaucoup plus de travail qui prend du temps. S’il était possible de controller comment et quand le GC fonctionne, peut-être il serait possible de mieux répartir le travail du GC pour le rendre imperceptible. Malheureusement Java ne permet pas actuellement ce genre de contrôle.

5 – Pourquoi Minecraft 1.8 consomme autant de mémoire ?
C’est la partie la plus intéressante: plus de 90% des allocations mémoires ne sont pas du tout nécessaires. La majorité de la mémoire est alloué pour rendre la vie des développeurs plus facile.
– La majorité des objets qui sont alloué sont abandonné immédiatement
– Toutes les fonctions qui avant utilisaient 3 paramètres x, y, z (de type valeur, sans besoin d’allocation mémoire) ont été remplacé par un seul paramètre “BlockPos” (de type objet, qui nécessite d’allouer de la mémoire) qui sont immutable (non modifiable). Cela signifie que si vous voulez modifier la valeur, vous devez instancier un nouvel objet. C’est un gâchis énorme de la mémoire.
– Le chargement des chunks réserve énormément de mémoire juste pour envoyer les données. L’excuse sera certainement le “multithreading”, cependant ce n’est pas du tout nécessaire (regardez Optifine 1.7).
– Et la liste continue encore et encore …

Globalement le problème est que les développeurs ne se soucient pas de la gestion mémoire et utilise les méthodes de développement à la mode sans chercher à comprendre les conséquences. La mode étant que “immutable c’est bien”, “alloué de la mémoire est plus rapide que le cache”, ” le GC est rapide en ce moment”, etc.

Allouer de la mémoire est réellement plus rapide que le cache (Java est même plus rapide que C++ pour la gestion de la mémoire dynamique), mais la libération de la mémoire n’est pas plus rapide, et n’est pas prévisible du tout. Minecraft est une application “temps-réel” et a besoin d’un framerate (fps) stable, et pour cela il doit garder une utilisation mémoire minimal, ou bien gérer lui-même sa libération de sa mémoire, ce qui n’est pas possible actuellement avec Java.

6 – Que peut-on faire pour corriger ce problème ?
S’il y a 2 ou 3 endroits dans le code qui gaspille beaucoup de mémoire (bug), Optifine pourra corriger les problèmes individuellement. Dans le cas contraire une grosse refonte interne du moteur jeu sera nécessaire, ce qui est une tache énorme non faisable par Optifine.

7 – Exemple
Voici un exemple de l’activité du GC, on y voit en particulier les piques de lag (en rouge sur la courbe):

http://i.imgur.com/viOy1Cc.png

– Le FPS moyen est de 50fps
– Le GC s’active toutes les 7 à 20 images
– Il y a entre 1 et 2 piques de lag chaque seconde, à cause du GC

————

TheMogMiner semble avoir été réceptif à ces remarques très constructives, et à immédiatement demandé plus de détail à sp614x, lui demandant même ses coordonnées pour entrer en contact direct.

TheMogMiner déplore une mauvaise communication dans l’équipe de développement chez Mojang:
“J’aurai pu dire que de nombreuses allocations de petits objets étaient une mauvaise chose, mais personne ne me l’a demandé”
“L’utilisation des BlockPos au lieu des triplés d’entiers me semble stupide, stupide, stuuuupide.”

TheMogMiner ira jusqu’à se demander pourquoi sp614x n’a pas été recruté par Mojang: “Je ne vais pas prétendre savoir pourquoi nous n’avons pas recruté sp614x. Cela a eu lieu avant mon arrivé. Si j’avais le choix, j’aurai aimé qu’on le recrute lui aussi, parce qu’il serait intéressant d’avoir une autre personne talentueuse avec qui travailler.”

Finalement Notch avait un gros défaut, un défaut avoué, il ne savait pas utiliser le multithreading.
La 1.8 corrigera ce manque, mais détruira toutes les optimisations que Notch maitrisait parfaitement, les optimisations dans la communication des données de rendu.

Espérons que ces conseils permettent aux développeurs de Mojang de corriger le tir, en réécrivant une énième fois le code de Minecraft.