Preamble
I would like to spend some time with the community to discuss a new technology. Well, not really “new” per se (it’s been in use since 2007), but it’s certainly something that’s recently gone under the crosshairs of my ire.
I speak of the Cider system, a method to deploy Windows games to the Mac cheaply and quickly.
So let’s have a discussion on this system. As usual, I hope you like text.
What is Cider?
From the TransGaming site: “TransGaming’s Cider™ Portability Engine is a proprietary technology that allows PC games to be enabled on Apple’s Intel Macs without the traditionally expensive and arduous need to redevelop a game from the ground-up. Cider acts as a “wrapper” around the PC game dynamically translating PC API calls to the Mac OS X operating system. As such, games can be enabled with Cider in a matter of days to weeks as opposed to the typical man years that traditional development takes.”
Why use Cider? (or: what’s the point?)
Cider is often used as a too-little-too-late correction for a major mistake made in early development: the use of Windows-only APIs like .NET, Direct3D, DirectSound, GDI, etc. Programs written to use these APIs can’t run on platforms other than Windows without the use of an emulation layer.
The .NET Framework – Strictly speaking, i don’t find a lot of utility in the .NET framework and tend to use other tools that the framework was meant to simplify. However, it is a best-option in a lot of circumstances for game developers. Portability is probably the biggest thing to this. By “portability”, we speak strictly of Microsoft-only systems; desktop and handheld devices, but the big deal here for the gaming industry is the Xbox portability. Since it’s a gaming platform, it makes it possible to have one’s product be both a PC game and a console game without much additional overhead. Compare this to the Wii method which includes a separate system the size of a 4U server.
DirectX – DirectX is a multitude of utilities from complex graphic rendering to control handling (keyboard, mice, and game control pads) to sound and music playback. Along with the .NET framework, DirectX is used because it works on Window 95 and above, Windows CE (to a limited extent), and most importantly, the Xbox.
Who uses Cider? (or: Dear God, why?)
At this point, game companies, rather exclusively, make use of Cider. You might know a few games: The Sims 3, Spore, City of Heroes and EVE Online to name a few.
Cider’s aim is to make porting a Windows game to Mac a lot easier, eliminating many hours of coding time. For instance, DirectX isn’t supported on Mac OS X, so the graphics API would need to be remapped to use OpenGL. Generally speaking, Mac games from major distributors don’t use Cocoa or Quartz, but rather OpenGL. The reason for this is simple: OpenGL works on pretty much anything. Mac OS X, Linux, FreeBSD, Windows, the iPhone, etc.
By why use DirectX at all if compatibility is an issue? There’s a few reasons. Several years ago, DirectX was a lot better in terms of performance than OpenGL. As a result, several companies spent good sums of money to train their developers to use DirectX Instead of switching to OpenGL, companies generally avoid the extra cost of training and continue to use DirectX. Once a game is done, it’s passed along to a separate team that does the port. Because all the code is in place as far as what a function call can do, it’s basically a codeswap; DirectX calls translated to OpenGL calls. Of course, it’s a lot more complex than this, but this is the general idea to the average layman; consider it like a game with a story written in English being translated to Japanese.
The process really is a long one, however, so a lot of money and hours need to go into it.
So what’s the problem? (or: The Domino Effect)
Know the saying “you get what you pay for”? It doesn’t apply here. Mac gamers pay as much as Windows players, and find that their experience is really diminished. That’s because Cider runs as an emulation layer.
There are various types of emulators. Full hardware emulators (i.e. Bochs, QEMU, etc), virtualizers (i.e. VMware, VirtualBox), and API wrappers (i.e. Wine, Crossover, Cider, etc). Full hardware emulators deal with translating machine code between two completely different architectures. This is perhaps the most complex and painful part of emulation. It causes tremendous overhead unless it’s done very well (i.e. a combination of dynamic recompilation and jitting). In the case of an API wrapper, the overhead shouldn’t be as much. The hard work is already done. The code is already native (x86 or x86_64).
Unfortunately, nobody has yet done an API wrapper particularly well. Current API wrappers such as Wine run much slower than they should. A majority of the Windows APIs can be mapped to POSIX API calls without much effort. Windows threads become pthreads. Windows critical sections become pthread mutexes. DirectX calls become OpenGL calls. But the overhead of an API wrapper such as Cider is much more tremendous than one might expect.
Is there much of a performance impact? Oh yes. Cider doesn’t care if you have more than one processor. Your state-of-the-art graphics card will be chugging along as if it were a 3-year old model. OpenCL, which is coming out in 10.6? Worthless. The Physical Address Extension (PAE) that allows you to run on more than 4GB of RAM? Likely going to be ignored. That’s to name just the hardware limitations.
On top of this, there are software issues. The method of coding to make DirectX fast isn’t the same method as to make OpenGL fast. It’s going to run slower because the original code for the game is totally unmodified. Additionally, and probably the biggest hit to performance, is the translation of the common WinAPI functions, such as page fault handling. Page fault handling is a very basic need; it’s not unusual to see a page fault delta of 20,000 per second on a very active application (i.e. games, which is what this is all about!).
Transgaming, the company that makes Cider and Cedega, have based their products on Wine for Linux. Since Transgaming is making these products with gaming use in mind, we might expect to see that Cedega outperforms Wine. Let’s run some basic micro-benchmarks and see how Cedega and Wine perform compared to native execution on Windows XP. Tests with the largest differences are shown in bold (thanks to Darek Mihocka for the great micro-benchmarking tool!).
Windows XP on a 2.33GHz Intel Core 2 Duo:
test 1 os crit 2 : 237 ms, 79000 ps/instr, 12 MIPS, 184.3 clk
test 2 os try ok : 11 ms, 3666 ps/instr, 272 MIPS, 8.5 clk
test 3 os pg flt : 71 ms, 2366666 ps/instr, 0.422 MIPS, 5528.4 clk
test 4 os virtqr : 14 ms, 466666 ps/instr, 2 MIPS, 1089.1 clk
test 5 os virtpr : 16 ms, 533333 ps/instr, 1 MIPS, 1244.2 clk
test 6 os isbadr : 150 ms, 5000000 ps/instr, 0.200 MIPS, 11665.0 clk
test 7 os isgood : 47 ms, 15666 ps/instr, 63 MIPS, 36.5 clk
test 8 os vxpflt : 71 ms, 2366666 ps/instr, 0.422 MIPS, 5528.4 clk
test 9 CmpExch 2 : 214 ms, 71333 ps/instr, 14 MIPS, 166.4 clk
test 10 GetInpSt : 9 ms, 3000 ps/instr, 333 MIPS, 6.9 clk
test 11 GetQStat : 1186 ms, 395333 ps/instr, 2 MIPS, 922.4 clk
test 12 PeekMsg : 1377 ms, 459000 ps/instr, 2 MIPS, 1071.1 clk
test 13 MemMap 2 : 107 ms, 3566666 ps/instr, 0.280 MIPS, 8332.1 clk
test 14 QueryPrf : 5243 ms, 1747666 ps/instr, 0.572 MIPS, 4078.6 clk
Linux running Wine v1.0.1, on the same 2.33 GHz Intel Core 2 Duo:
test 1 os crit 2 : 295 ms, 98333 ps/instr, 10 MIPS, 229.4 clk (1.24x slower)
test 2 os try ok : 12 ms, 4000 ps/instr, 250 MIPS, 9.3 clk (1.09x slower)
test 3 os pg flt : 163 ms, 5433333 ps/instr, 0.184 MIPS, 12679.3 clk (2.29x slower)
test 4 os virtqr : 44 ms, 1466666 ps/instr, 0.681 MIPS, 3425.8 clk (3.14x slower)
test 5 os virtpr : 91 ms, 3033333 ps/instr, 0.329 MIPS, 7091.1 clk (5.68x slower)
test 6 os isbadr : 156 ms, 5200000 ps/instr, 0.192 MIPS, 12151.0 clk (1.04x slower)
test 7 os isgood : 71 ms, 23666 ps/instr, 42 MIPS, 55.2 clk (1.51x slower)
test 8 os vxpflt : 173 ms, 5766666 ps/instr, 0.173 MIPS, 13485.5 clk (2.43x slower)
test 9 CmpExch 2 : 217 ms, 72333 ps/instr, 13 MIPS, 168.7 clk (2.43x slower)
test 10 GetInpSt : 34990 ms, 11663333 ps/instr, 0.085 MIPS, 27447.0 clk (3887.78x slower)
test 11 GetQStat : 34967 ms, 11655666 ps/instr, 0.085 MIPS, 27447.0 clk (29.48x slower)
test 12 PeekMsg : 42974 ms, 14324666 ps/instr, 0.069 MIPS, 33811.5 clk (31.20x slower)
test 13 MemMap 2 : 2545 ms, 84833333 ps/instr, 0.011 MIPS, 212090.9 clk (23.78x slower)
test 14 QueryPrf : 4723 ms, 1574333 ps/instr, 0.635 MIPS, 3674.0 clk (1.12x faster)
Linux running Cedega 7.3.1 on the same 2.33GHz Core 2 Duo:
test 1 os crit 2 : 286 ms, 95333 ps/instr, 10 MIPS, 222.4 clk (1.21x slower)
test 2 os try ok : 24 ms, 8000 ps/instr, 125 MIPS, 18.6 clk (2.18x slower)
test 3 os pg flt : 1995 ms, 66500000 ps/instr, 0.015 MIPS, 155533.3 clk (28.10x slower)
test 4 os virtqr : 7 ms, 233333 ps/instr, 4 MIPS, 544.4 clk (2.0x faster)
test 5 os virtpr : 96 ms, 3200000 ps/instr, 0.312 MIPS, 7477.5 clk (6.00x slower)
test 6 os isbadr : 1975 ms, 65833333 ps/instr, 0.015 MIPS, 155533.3 clk (13.16x slower)
test 7 os isgood : 102 ms, 34000 ps/instr, 29 MIPS, 79.3 clk (6.00x slower)
test 8 os vxpflt: FAILED!! (games using vectored exception handling would crash)
test 9 CmpExch 2 : 289 ms, 96333 ps/instr, 10 MIPS, 224.7 clk (1.35x slower)
test 10 GetInpSt : 4925 ms, 1641666 ps/instr, 0.609 MIPS, 3830.8 clk (547.22x slower)
test 11 GetQStat : 4796 ms, 1598666 ps/instr, 0.625 MIPS, 3732.8 clk (4.04x slower)
test 12 PeekMsg : 41978 ms, 13992666 ps/instr, 0.071 MIPS, 32859.1 clk (30.49x slower)
test 13 MemMap 2 : 2983 ms, 99433333 ps/instr, 0.010 MIPS, 233300.0 clk (27.88x slower)
test 14 QueryPrf : 4078 ms, 1359333 ps/instr, 0.735 MIPS, 3174.1 clk (1.09x faster)
Oddly enough, the use of Cider is actually worse than using the open-source Wine. The result: a far less enjoyable experience, but probably more enjoyable than, say, running a Windows game in Parallels or VMWare Fusion.
In short, you get what the game developer paid for. Low performance for a low price.
If you’ve play Spore on the Mac platform at all (which I have and I’m throughly unimpressed with the game), then you’re probably thinking that I’m taking things out of proportion. Well no, I’m really not. Games like Spore and the Sims 3 aren’t exactly what we call graphics intensive, but games like EVE Online have the potential for very intensive sequences (namely battles). Here’s the bottom line: you’ll never find games like Bioshock, Crysis or even Portal running on the Mac (more on Portal later).
Should I be concerned? (or: So what’s the problem exactly?)
The use of Cider drops the bottom line. Little additional development is required and the price tag is a lot less than porting to native code.
Should you be concerned? Oh yes. Cider encourages developers to be lazy in the porting process, allowing them to exploit the Mac and Linux gaming markets with underachieving products.
In general, Macs can be good gaming platforms, specifically due to the hardware used in Macs on a given day. Not the best hardware, but certainly among the top. If you’re going to run a Windows game in BootCamp, then you’re going to be pretty well off on high detail modes, even on the laptop models (at least the newer ones). Using a Cider port, however, means that you might be getting intermittent frames, even on low detail modes.
This isn’t really a big deal though if you don’t play games, right? I beg to differ. Games are fairly complex in the emulation layer support they require. The main reason that we’re seeing this behaviour in games is because it’s the one industry that lacks porting the most.
It’s fairly safe to say that constructing a wrapper for other applications would be a lot easier, particularly if the wrapper is not a lot more than Wine. Imagine if other corporations started adopting the Cider method of porting. What could we see?
Imagine Adobe Photoshop or Premiere ported with a Cider wrapper. Or Autodesk Maya, Blender or Bryce. All of these have ports in native code, but what if, in the recessed economy, these companies decide to go the Cider route to cut the bottom line?
This would be a very good way to effectively ruin the Mac platform. While more apps could theoretically be used on Mac OS X, they would all be running in an emulation layer, cutting back on performance. If you use these utilities for a job, there’s a good chance that you would think twice before buying a Mac due to the performance issues.
Apple is trying to make a habit out of optimization. It’s the key focus of Snow Leopard. Unfortunately, no amount of optimized code on the part of Apple will matter if companies start favouring the Cider method outside the gaming industry. Already, gamers that were originally excited to hear of big names like EA coming to the Mac platform are instead feeling disenfranchised rather than empowered. Now imagine if this was happening in the video industry or the graphical arts industry.
It’s been said by some others that Cider could means the death of Mac gaming as we know it, but the potential here is so much more dangerous. It also has lasting implications.
Unintended consequences (or: Piracy Made Easy)
I stated before that I was going to get back to Portal, and now I am. There has been a Cider port of Portal running around for some time now, but it’s not based from Valve.
It is in fact a product of a new fresh mode of piracy. The advent of Cider has actually done more for the piracy movement than anyone else. Generally speaking, pirates understand that they’re already getting more than they are paying for, so certain graphical issues (some things won’t render, namely shaders) aren’t that big of a deal.
However, Portal and Half Life 2 are both critically acclaimed and are on many lists for people as a “must play at least once”. It would thus make sense that they would be targets for piracy. With Cider, that which wasn’t possible without a name brand virtualizer is now possible to run on the Mac, albeit without the quality that you would expect from a natural port.
Pirates don’t care. Free is free and it’s hard to complain when a cracked product is perfectly playable, even if it’s not pristine in graphical quality.
Afterword (or: Digression)
Cider really has a lot going for it in the future, and that’s inescapable. Being able to make any graphically dependent program truly cross platform is really no small feat, and the near-guarantee that a product can work on multiple platforms without significant code changes is a rather tempting reason to use it.
This however really brings to bear the use of the term “cross compatible”. A program that requires a virtualizer certainly does fall under the definition, but something like Cider isn’t so easy to classify. It’s not really even a grey area; it’s more like a splotchy murk. I worry that there might be a point in time that it start affecting the work I do. I rather enjoy the Mac platform, but I’d be damned if I use it to run a dozen wrapped applications instead of a dozen applications with native code.
I mean, the Mac version of Word is bad enough as it is.
