For example, on my Mac Mini with Bootcamp, Team Fortress 2 runs at about 20fps in OSX and 80fps in Windows. This seems to be a common case. Why is this?
-
\$\begingroup\$ It's the same machine dual booted into either operating system. \$\endgroup\$– sansSep 1, 2011 at 19:27
-
\$\begingroup\$ dual booted as in "not a virtual machine" correct? \$\endgroup\$– horatioSep 1, 2011 at 20:59
-
1\$\begingroup\$ Yes, booting directly into either OS. \$\endgroup\$– sansSep 1, 2011 at 21:26
-
1\$\begingroup\$ I always find these questions interesting - as long as they don't devolve into mindless rants/flaming - because, as a Mac user (of 10 months), I get to see the misconceptions of Windows users. \$\endgroup\$– RicketSep 4, 2011 at 2:44
4 Answers
Direct3D drivers on Windows are ridiculously optimized, sometimes for specific games, and developed by individual hardware vendors.
Apple's OpenGL drivers are written and maintained (AFAIK) by Apple, and are intended for "general" OS use, compositing the UI and whatnot. There's no so much optimization for gaming and high-performance throughput.
Basically, a lot of resources from a lot of sources have gone into making DirectX fast on Windows, while much fewer resources are available to do the same on Mac.
-
\$\begingroup\$ I'd lean even more specifically towards the shader compiler in the driver as being a bit part of the difference. altdevblogaday.com/2011/07/20/… says that for popular games NV/AMD will even hand optimize the shaders for their hardware. \$\endgroup\$– AdamSep 1, 2011 at 22:10
-
5\$\begingroup\$ It's not only the drivers.. it's also the game developers. They usually invest more resources into optimizing for Direct3d/DirectX instead of OpenGL. Another case is when a game was initially developed just for windows and gets ported later on. That has to be a really good port (eg. may result in a lot of code rewriting) if it should achieve similar performance... which is mostly not the case. \$\endgroup\$– bummzackSep 1, 2011 at 22:30
-
\$\begingroup\$ So Team Fortress 2 is rendered in OpenGL on OSX but D3D on Windows? \$\endgroup\$– sansSep 3, 2011 at 18:03
-
\$\begingroup\$ sans, yes, Direct3D is Windows-only, so any game on any other platform is rendered using OpenGL (or software..). Windows does support OpenGL as well; but most Windows versions of games will use Direct3D because as mentioned, the drivers for Windows are usually much more optimized for D3D. \$\endgroup\$– RicketSep 4, 2011 at 2:25
While I won't discount the optimization that Microsoft may have put into Windows and/or DirectX, I strongly believe that most programs perform better on Windows simply because that's what the developers focus on (that's where the money is). They make design decisions with Windows in mind, and then later try to make it work in other OSs (Mac, Linux, etc.). I constantly run into this at work: other projects have so much trouble with porting to non-Windows systems because the developers treated it as an after-thought. I have repeatedly written programs that build on multiple OSs with very little effort because I planned it that way from the beginning. Once you've really tried to do it (as opposed to grudgingly doing the port after-the-fact), you learn what it takes and it requires very little extra effort. Most of the performance differences are caused by design decisions made at the beginning of the project.
-
\$\begingroup\$ The curiosity of a non-coder here: What happens to the performance when you design for multiplatform? For example, will your multiplatform game run as fast on Windows as a Windows-focused version would have? \$\endgroup\$ Sep 2, 2011 at 4:35
-
\$\begingroup\$ @Jason: It's more about the time spent and platform specificity. There is nothing stopping a developer from writing code which is completely optimised for Windows, writing separate code which is entirely optimised for OSX, and then just switching which is used based on the platform. However, the time and thus resources spent to do so often outweigh the benefit of doing so. \$\endgroup\$ Sep 2, 2011 at 5:00
-
\$\begingroup\$ @Jason: In that case, it really depends on how well you've designed your game (and when I say design I mean planning, not the actual coding) and how divergent the different OSs are. If they are very different, then Jordaan's comment is appropriate where you have to address each OS seperately. But with common interfaces like OpenGL, and over time different APIs borrow concepts from each other, they have all become rather similar. So today it is more a excercise in matching features and designing your software to be able to use each of the features without excluding an OS. \$\endgroup\$– KloxSep 2, 2011 at 13:44
As a fellow Mac user, I'd like to offer an additional factor: the CPU scheduler in OS X is more "fair" than in Windows.
This is sort of a complicated computer science topic, so here's a simple way to think of your CPU scheduler: your processor has to juggle many tasks at once (all your open programs, plus background system processes). It can only actually do a couple things at once (the number of cores times the number of threads per core; a dual-core i7 can do 4 tasks at once, for example). So it splits all the work into pieces, and alternates between them so that it looks like it's actually doing a lot of things at once. When you run two programs, the processor is actually just alternating back and forth between processing those two programs, really fast (like, a few microseconds here, and then a few microseconds there).
The pattern for which things are executed in what order and for how long is decided by a "scheduling algorithm". For example, the round robin scheduler just arranges the tasks in a circle and processes each one in order. Another scheduler might arrange the tasks from least-to-most time remaining - small tasks would be done quickly, and big tasks might have to wait a while before being done.
Windows and OS X are very different, and their scheduling algorithms are a bit different as well. Windows is a little "smarter" about prioritizing things, so it gives extra priority to visible programs in order to make the computer appear faster. OS X, however, is more fair to background processes. The overall algorithms are much the same between the two OSes (they are both multilevel feedback queues), but this little detail results in a different user experience.
Both sides have their advantages. Like I said, visible programs in Windows will appear faster because they get more priority; but if one visible program decides to take a lot of power, the whole computer suffers a bit more. OS X's more fair scheduler results in more predictable and stable speeds, which is good for audio and video operations. For example if you're playing a song in the background, it's less likely to stutter when you do other things at the same time than in Windows.
So, the takeaway point is this: a full-screen game in Windows is going to get high priority on the CPU and anything running in the background will just have to wait. In OS X, this is less the case.
Some technical info about the schedulers is given here; the rest of this answer is from my computer science education and my usage of OS X over the past 10 months, after having used Windows for over 10 years (and Linux occasionally). I am sometimes frustrated by the more fair scheduler, but other times I appreciate its advantages.
Linux, by the way, has an even more fair scheduler implementation; this is what makes it a great server, but in my opinion the user experience is degraded. For example, when your computer is bogged down with tasks, your cursor will stop responding smoothly because it's given the same priority as everything else. This basically never happens in Windows or OS X.
Some games that have been "ported" to MacOSX are actually Windows games running within an emulator. While I don't have a complete list of examples, it seems that there is at least SPORE that was like that:
SPORE was never officially released on GNU/Linux, and the Mac version aged poorly. The Mac port is actually the Windows release packaged with Cider, which is a depreciated technology wrapping a (now old) version of WINE around games. (Source)
Running a software within an emulator is by definition slower than running it natively.