Wine vs Windows Benchmarks 286
PeterBrett writes "Tom Wickline recently posted to the Wine development list announcing that he'd done some benchmarks comparing Windows XP to Wine. They should be taken with the requisite dose of salt, but Wine has certainly come a long way."
Compatibility more important than speed! (Score:5, Interesting)
Then I tried Codeweavers' "Crossover Office," essentially a pre-configured Wine with graphical configuration and installation tools, and everything changed. I currently use all of the following under Fedora Core 4:
- Microsoft Office XP
- Wordperfect 12 (word processor only)
- Photoshop 6
- Framemaker 7
They all installed using the standard CD install, without my having to jump through any crazy hoops or type a single command, and they all run flawlessly and are great for serious work. They sit right in my KDE menu like all other applications and it's a real head-turner to be able to show up to work with my laptop running Linux and then pop into Word XP and Framemaker.
Wine works incredibly well after all, it's just more "raw material" than "finished product." Get someone to write a user-friendly front end for it (ala Codeweavers' Crossover Office) and it offers a very high level of Windows compatibility to Linux users.
Re:Maybe a grain of salt, but it's what I'd predic (Score:3, Interesting)
I don't make fun of your hair do I?! So stop making fun of my favorite distro!
Funny statistics (Score:5, Interesting)
So whatever this is measuring (and I concur that it seems to be mostly Linux graphics drivers), it's not reporting the results particularly well.
Re:Compatibility more important than speed! (Score:4, Interesting)
Why would you run a Windows-only compiler on Linux? But, more importantly, #2:
Why would you run an allegedly platform-dependent runtime on an emula^H^H^H^H compatibility layer?
These tests don't really put Wine in a good light (Score:2, Interesting)
Filesystem, graphics driver (Score:5, Interesting)
The other wonderful thing I've found about Wine is the graphics abstraction layer. My laptop has a GeForce FX5600 (mobile) card in it. It's actually rather spiffy for most games still, but sucked ass at Battlefield 2 in windows, popping up the warning that my graphics drivers were out of date. Well, it seems that the drivers are tied to the laptop in windows to co-habitate with the power-saving etc etc... so I couldn't update from the official NVidia ones. And of course, my laptop vendor doesn't offer updates for anything over a year old it seems.
In linux, however, the normal NVidia accelerated driver works. The game runs on that faster than in windows, and with better detail levels. I don't know if it's just that the Cedega HAL does a better emulation for the software bits, or if it's due to the more-up-to-date driver, but it's a much less painful experience in Linux.
Lastly, my soundcard. SB Live 5.1. Abit dated, but with livedrive still a very nice functional card, except that the windows drivers will eventually/randomly freeze in most directX intensive games. Running in linux... no problemo. That's actually why I switched to Cedega/Debian almost completely (too many losses in Warcraft from lockups).
Re:The tests are meaningless! (Score:4, Interesting)
Missing the most crucial test (Score:3, Interesting)
Re:on a dev list (Score:5, Interesting)
Read the article. These aren't dev-created benchmarks, but standard benchmark suites like 3DMark and Quake 3.
Some of the tests look really weird. For instance, in the 3DMark2000 Fill Rate test, Single Texture on Wine gets 2,402.8 MTexels/s and 11% behind Windows, but on the Multi-Texture test it soars to 6,695.1 MTexels/s and 74.5% in front of Windows. There's got to be some freaky driver code or something implemented oddly or some background process that wasn't noticed.
I don't think these benchmarks were run rigoriously enough to say anything, except that Wine is capable of running 3DMark.
Re:Maybe a grain of salt, but it's what I'd predic (Score:2, Interesting)
transgaming (Score:2, Interesting)
Example of distorted statistics (Score:4, Interesting)
1. Most of Wine's wins are in the 0-2% mark. Means nothing except _inconclusive_; otherwise where is the variance, num tests to justify this?
2. Wine's perf is bad in the tests it lost
3. Old test suites were used
4. As some one said, If Wine is 90% faster it means it is 90% faster. If it is 90% slower it means it is 10 times slower!!!
BUT, what is really impressive is that Wine actually managed to run all the tests. The compatibility is indeed impressive. This benchmark would have been very credible had it not played with the numbers and colors.
Maybe a troll, but here is my argument against Wine:
Windows is moving to WinFX. Then it makes more sense to emulate WinFX's API than Win32 API. (WinFX does use Win32 extensively underneath, but why emulate 2 API's??). In the longer term, the answer to Windows compatibility is not Wine, it is MONO [mono-project.com].
Re:Very Impressive! (Score:3, Interesting)
My sister in law runs ubuntu and I have had a go at getting some windows games running under wine for her son. What I would like to see is a windows environment which she can use to install these things herself.
As it is I have to mount the CD, find the installer executable and run it under wine. This is a bit difficult to explain to a non technical person.
DirectX: vendor-lock-in and avoid paying to SGI (Score:2, Interesting)
Yes. Vendor-lock-in is what Microsoft generally does well.
Re:Maybe a grain of salt, but it's what I'd predic (Score:5, Interesting)
Um, the question was whether he'd see a marked improvement changing from debian/ubuntu -- and given that Debian uses the same kernel as gentoo, and the same apps, it's very unlikely that there will be any difference in performance unless it comes from the "-fmad-compile" options. [In my experience, the -fmad-compile won't make any difference in practice either unless you're talking about very specialized balls-to-the-wall code like scientific computing or whatever.]
The "0 swapping happening" is an attribute of the linux kernel, not the distro; I notice the same thing under debian (in fact I generally see no disk i/o at all unless I'm writing files, because of linux's excellent disk caching). If the OP is having problems with swapping it means that he doesn't have enough memory for the apps he's using; a distro change is unlikely to help with that.
Re: Very Impressive! (Score:3, Interesting)
Sorry, that can't be true. The Win32 documentation is fairly comprehensive, but it is absolutely horrible on the fringes. There is NO WAY you could implement an API from it and expect it to be able to run real world apps. The docs for RPC, OLE, Shell, Common Controls, Win16 are particularly atrocious. More likely you code to the API and then discover the 101 ways that apps break the APIs and the 101 ways that the APIs differ from the specs through test cases and you make your changes accordingly.
On top of that, the header files alone are filled with macros, switches, messages, uuids, flags which aren't even mentioned in the docs, or whose underlying values are not specified.
So perhaps there is not reverse engineering in the sense of disassembling Windows to see what is going on, but there certainly is reverse engineering of the APIs via test cases and headers by looking up the real headers.
Reverse engineering is... (Score:5, Interesting)
That sentence came from the Oxford American Dictionary. To me that sounds as if reverse engineering has more to do with cloning products than just coming up with an alternative implementation which is what Wine is. All that Wine does is create a blackbox that works like the Windows API from the point of view of a Windows application but using totally different internals. Reverse engineering would be if they had recreated the internals more or less exactly using components replicated as far as possible from the originals in which case they would have to recreate the Windows source code from binaries somehow. You could also point to the AMD processors that implement the x86 instruction set, internally they are radically different from the Intel originals but to Windows they function the same. If that was reverse engineering I somehow suspect AMD would have gotten it's pants sued of by now. Instead Intel has now adopted the AMD64 instruction set that AMD came up with which is basically just x86 extended to 64 bit. The 'Mono' implementation of the Microsoft
You did raise an interesting point about limited reverse engineering which is probably true. In order to clear up inconsistencies and undocumented features in the Windows API the Wine team probably did some analysis of Windows. Surprisingly enough I recenty found out that this is actually permissable under copyright laws, at least in my own country, if the manufacturer is reluctant to issue full and comprehensive documentation and it is vital to the success of your project and you are not attempting to replicate the internals of the undocumented product just determine how it works to fill in patchy documentation which is the case with Microsoft and the Wine team in this case, they are not making a bolt for bolt replica of Windows. From what I can tell Wine is not doing anything illegal or unethical if they were producing line for line copies of Windows system binaries by reverse engineering Windows source code that would be another matter.
Re:What do you think reverse engineering is ? (Score:3, Interesting)
However, if we're going to take Wikipedia to be gospel, then let's read all of it, including:
The Samba software, which allows systems that are not running Microsoft Windows systems to share files with systems that are, is a classic example of software reverse engineering, since the Samba project had to reverse-engineer unpublished information about how Windows file sharing worked, so that non-Windows computers could emulate it. The WINE project does the same thing for the Windows API, and OpenOffice.org is one party doing this for the Microsoft Office file formats. [emphasis mine]
I have no idea if the WINE engineers have disassembled (or as you say decompiled) Windows binaries or not. My point remains that this is not the determining factor in deciding if it is reverse engineering or not: meaning that disassembly is not necessarily a feature of reverse engineering.