Par exemple, sur mon Mac Mini avec Bootcamp, Team Fortress 2 fonctionne à environ 20fps sous OSX et 80fps sous Windows. Cela semble être un cas courant. Pourquoi est-ce?
Par exemple, sur mon Mac Mini avec Bootcamp, Team Fortress 2 fonctionne à environ 20fps sous OSX et 80fps sous Windows. Cela semble être un cas courant. Pourquoi est-ce?
Réponses:
Les pilotes Direct3D sur Windows sont ridiculement optimisés, parfois pour des jeux spécifiques, et développés par des fournisseurs de matériel individuels.
Les pilotes OpenGL d'Apple sont écrits et maintenus (AFAIK) par Apple, et sont destinés à une utilisation «générale» du système d'exploitation, à la composition de l'interface utilisateur et ainsi de suite. Il n'y a pas tant d'optimisation pour les jeux et le débit haute performance.
Fondamentalement, beaucoup de ressources provenant de nombreuses sources ont été utilisées pour rendre DirectX rapide sur Windows, tandis que beaucoup moins de ressources sont disponibles pour faire de même sur Mac.
Bien que je ne néglige pas l'optimisation que Microsoft a pu mettre dans Windows et / ou DirectX, je crois fermement que la plupart des programmes fonctionnent mieux sous Windows simplement parce que c'est ce sur quoi les développeurs se concentrent (c'est là que l'argent se trouve). Ils prennent des décisions de conception en pensant à Windows, puis essaient plus tard de le faire fonctionner dans d'autres systèmes d'exploitation (Mac, Linux, etc.). Je suis constamment confronté à cela au travail: d'autres projets ont tellement de mal à porter sur des systèmes non Windows parce que les développeurs l'ont traité comme une réflexion après coup. J'ai écrit à plusieurs reprises des programmes qui s'appuient sur plusieurs systèmes d'exploitation avec très peu d'effort parce que je l'ai planifié de cette façon depuis le début. Une fois que vous avez vraiment essayé de le faire (par opposition à faire à contrecœur le port après coup), vous apprenez ce qu'il faut et cela nécessite très peu d'efforts supplémentaires.
En tant qu'utilisateur Mac, j'aimerais offrir un facteur supplémentaire: le programmateur CPU sous OS X est plus «juste» que sous Windows.
C'est une sorte de sujet informatique compliqué, alors voici une façon simple de penser à votre ordonnanceur CPU: votre processeur doit jongler avec plusieurs tâches à la fois (tous vos programmes ouverts, plus les processus système en arrière-plan). Il ne peut réellement faire que deux choses à la fois (le nombre de cœurs multiplié par le nombre de threads par cœur; un i7 double cœur peut effectuer 4 tâches à la fois, par exemple). Donc, il divise tout le travail en morceaux et les alterne pour donner l'impression qu'il fait en fait beaucoup de choses à la fois. Lorsque vous exécutez deux programmes, le processeur alterne en fait entre les deux programmes, très rapidement (comme quelques microsecondes ici, puis quelques microsecondes là-bas).
Le modèle pour lequel les choses sont exécutées dans quel ordre et pour combien de temps est décidé par un "algorithme de planification". Par exemple, le planificateur à tour de rôle organise simplement les tâches dans un cercle et traite chacune dans l'ordre. Un autre ordonnanceur pourrait organiser les tâches du moins au plus longtemps restant - les petites tâches seraient effectuées rapidement et les grandes tâches pourraient devoir attendre un certain temps avant d'être effectuées.
Windows et OS X sont très différents, et leurs algorithmes de planification sont également un peu différents. Windows est un peu plus «intelligent» quant à la hiérarchisation des choses, il donne donc une priorité supplémentaire aux programmes visibles afin de faire apparaître l'ordinateur plus rapidement. OS X, cependant, est plus équitable pour les processus d'arrière-plan. Les algorithmes globaux sont sensiblement les mêmes entre les deux systèmes d'exploitation (ce sont tous les deux des files d'attente de rétroaction à plusieurs niveaux ), mais ce petit détail se traduit par une expérience utilisateur différente.
Les deux parties ont leurs avantages. Comme je l'ai dit, les programmes visibles dans Windows apparaîtront plus rapidement car ils obtiennent plus de priorité; mais si un programme visible décide de consommer beaucoup d'énergie, tout l'ordinateur en souffre un peu plus. L'ordonnanceur plus équitable d'OS X se traduit par des vitesses plus prévisibles et stables, ce qui est bon pour les opérations audio et vidéo. Par exemple, si vous lisez une chanson en arrière-plan, il est moins susceptible de bégayer lorsque vous faites d'autres choses en même temps que sous Windows.
Donc, le point à retenir est le suivant: un jeu plein écran sous Windows va obtenir une priorité élevée sur le processeur et tout ce qui s'exécute en arrière-plan devra simplement attendre. Sous OS X, c'est moins le cas.
Quelques informations techniques sur les planificateurs sont fournies ici ; le reste de cette réponse provient de mes études en informatique et de mon utilisation d'OS X au cours des 10 derniers mois, après avoir utilisé Windows pendant plus de 10 ans (et Linux occasionnellement). Je suis parfois frustré par le planificateur plus juste, mais d'autres fois j'apprécie ses avantages.
Linux, en passant, a une implémentation du planificateur encore plus équitable; c'est ce qui en fait un excellent serveur, mais à mon avis l'expérience utilisateur est dégradée. Par exemple, lorsque votre ordinateur est embourbé avec des tâches, votre curseur cessera de répondre en douceur car il a la même priorité que tout le reste. Cela ne se produit pratiquement jamais sous Windows ou OS X.
Certains jeux qui ont été "portés" sur MacOSX sont en fait des jeux Windows exécutés dans un émulateur. Bien que je n'ai pas une liste complète d'exemples, il semble qu'il y ait au moins SPORE qui était comme ça:
SPORE n'a jamais été officiellement publié sur GNU / Linux, et la version Mac a mal vieilli. Le port Mac est en fait la version Windows fournie avec Cider, qui est une technologie dépréciée enveloppant une version (désormais ancienne) de WINE autour des jeux. ( Source )
L'exécution d'un logiciel dans un émulateur est par définition plus lente que son exécution native.