ThreadTweak — un mod technique pour optimiser et ajuster les priorités des threads du processeur dans Minecraft

ThreadTweak — un mod technique pour optimiser et ajuster les priorités des threads du processeur dans Minecraft

ThreadTweak est un petit mod technique pour Minecraft qui expose les paramètres de la façon dont le jeu répartit le travail sur les cœurs du processeur : le nombre de threads de travail dans les pools clés et la priorité de chacun d'eux. En vanilla, ces valeurs sont codées en dur et identiques pour tous — ce qui n'est pas toujours optimal pour un système spécifique ou à côté d'un logiciel en arrière-plan actif. Tous les paramètres sont sauvegardés dans le fichier threadtweak.json et appliqués après le redémarrage du jeu.

Ce que le mod change exactement

L'outil agit à deux niveaux : la taille des pools de travail et la priorité des threads.

Taille des pools de travail — c'est le nombre de threads séparés en lesquels le jeu divise les tâches parallèles au lancement et à certains moments de la session de jeu : l'assemblage de l'atlas de textures, la migration d'anciens mondes, certaines opérations de chunks. En vanilla, cette taille est automatiquement liée au nombre de cœurs du processeur avec une limite supérieure. En pratique, certaines tâches se mettent mal à l'échelle — plusieurs threads ne travaillent pas plus vite qu'un seul, et la surcharge due à la coordination entre eux ne fait qu'augmenter.

Priorité des threads — une échelle de 1 à 10 que Java transmet au système d'exploitation comme recommandation sur à qui donner le temps processeur en premier. La priorité standard de tous les threads Minecraft est 5. Réduire la priorité des pools en arrière-plan ne ralentit généralement pas le jeu de manière notable, mais libère des ressources pour d'autres processus : navigateur, chat vocal, logiciel d'enregistrement vidéo. L'augmenter au-dessus de 5 donne rarement un coup de pouce — le système d'exploitation divisera quand même le temps processeur entre les applications actives, et la synchronisation entre les propres threads du jeu peut devenir moins stable.

Quand la configuration offre un réel avantage

Il n'y a pas beaucoup de scénarios où le contrôle manuel des pools et des priorités modifie sensiblement l'expérience, mais ils sont spécifiques :

• Jouer en parallèle avec un stream ou un enregistrement. Sur les systèmes de 4 à 6 cœurs, OBS et Minecraft se disputent le processeur. Abaisser la priorité des Main et IO Worker à 2–3 réduit les micro-saccades dans la vidéo sans perte de FPS visible dans le jeu.

• Processeurs faibles ou anciens. Avec 2 à 4 cœurs physiques, vanilla répartit les threads de travail sur tous ceux disponibles, ce qui fait perdre périodiquement du temps au thread de jeu principal. Limiter threadCount.main à 1–2 supprime une partie de ce bruit.

• Processeurs multicœurs avec charge en arrière-plan. Sur les systèmes de 12+ threads, où la compilation, les torrents ou les sauvegardes s'exécutent en parallèle, baisser les priorités fait de Minecraft un "voisin silencieux" qui ne consomme pas toutes les performances du planificateur du système d'exploitation.

Sans ces conditions, la modification donne un effet dans la marge d'erreur de mesure des FPS.

Configuration du mod

La configuration peut être ajustée directement dans le fichier config/threadtweak.json. Le format est un JSON standard, qui s'ouvre avec n'importe quel éditeur de texte.

Si le fichier n'existe pas, il est créé automatiquement lors du premier lancement du jeu après l'installation du mod.

Paramètres du fichier de configuration

La configuration contient deux groupes : threadCount (taille du pool) et threadPriority (priorité des threads). Toutes les valeurs sont des nombres entiers.

Conclusion

ThreadTweak comble une niche très étroite — le contrôle manuel des pools et des priorités des threads pour les cas où le planificateur Java standard gêne. Dans un jeu simple en solo sans applications en arrière-plan, le gain de FPS se situera dans la marge d'erreur. Le mod a un réel sens sur les processeurs faibles, lors d'un streaming ou d'un enregistrement parallèle, ou lorsque le système est constamment occupé par d'autres processus gourmands en ressources. En soi, il n'accélère pas le jeu — il ne fait que redistribuer les ressources entre les threads, il n'y a donc aucune raison d'en attendre un effet de boost magique.