Slashdot Mirror
Wine vs Windows Benchmarks
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."
We need real benchmarks! Get some Windows worms/viruses/trojans running on WINE and then we'll have some real-world benchmarks!
I say good day to you sir!
while i realise that postings to a dev list shouldn't be taken as gospel, why would a dev list posting of benchmarks be assumed to be doctored? of course i would expect this from a marketing dept, but a dev list?
chris
"Physics is like sex. Sure, it may give some practical results, but that's not why we do it." - R. Feynman
I've quite impressed with the performance of WINE, however these stats can be a little deceiving. These stats are based on a game that works. Getting the game to work in the first place can be quite a challenge. But for the part-time gamer that doesn't wanna be chained to Windows, this is a great alternative indeed!
http://religiousfreaks.com/The results aren't exactly surprising - Wine is excelling in what Linux is generally better than Windows in doing - memory management, hard drive speed, and related matters (stressing generally there, because of course different apps give different results). This is Gentoo after all, it's built for speed. Then the heavier the load on the video drivers the more the superiority of the Windows drivers takes hold, so for the graphical stuff things don't work as fast.
Congrats to the Wine devs!
To me this seems to be more a test of the linux implementation of teh video card drivers.. and NOT the wine system itself.
i think a wider suite of tests would be required.. and not just the preformance/gaming orinted stuff.
-- Shoe Lace
Speaking as someone who used to be a Wine-hater, Wine has definitely come a long way. My impression of Wine for years was that it a) was impossible to install and configure, b) didn't run anything other than solitaire, and c) caused major instability to desktops.
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.
STOP . AMERICA . NOW
...it makes you feel relaxed, slightly fogged and, in sufficient quantities, happily drunk. Windows, on the other hand, just makes you feel angry and frustrated. Give me wine!
oh, wait, you were discussing software?
Anyone else notice the funny stuff going on with the statistics? All the statistics are reported as percentages of the XP value, with higher = better. That means that if wine is "+ 90%", it's performing less than twice as fast as XP. But if it's "- 90%", XP is performing ten times faster!
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.
Well, my experience with Wine/Cedega has been that for the games and applications that work, the disk-access tends to be faster. Not necessarily because the actual disk is being accessed faster, but because the filesystem (in my case reiserfs) is speedier to read.
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).
I know this is repeat info for most people, but for the newbies...
There's actually an online application database where people have submitted their experiences/successes in getting Windows apps to run under Wine. If you want to see how well Office 2k3 works under Wine, this'd be the first place to look. Conversely, if you have success running a given Windows app, be sure to submit your experiences. Feedback to the App DB not only helps other Wine users, but is helpful feedback for Wine developers on outstanding compatibility issues.
The URL is: http://appdb.winehq.org/
Okay, I *like* WINE. It's a great piece of software, and very useful. But it doesn't make Linux a drop-in Windows replacement. If you decide "Gee, I think I should use Linux as a desktop" (I do), then it's icing on the cake if WINE runs something. It's not reasonable to simply expect a given piece of software to run flawlessly under WINE, though.
Any program relying on (nontrivial) preemptive multithreading will be buggy.
Nobody said they were doctored; the slashdot editor said "take it with a grain of salt". I see a lot of reasons to do so:
Honestly? The results probably aren't manipulated, but the presentation is very clearly set up with a number of tricks (perhaps without him/her realizing it) to give the impression that Wine "kicked some serious ass", when for the most part, it did horribly.
Please help metamoderate.
These results aren't presented to try to make Wine look better, nor is the author, consciously or unconsciously, trying to make it appear faster. These results simply were not meant to be used to say that Wine is better than Windows, and only Slashdot would try to make it appear that way. The real point of these comparisons, as is apparent if you read the Wine weekly summaries, is to give the Wine developers an idea of what areas need to be improved, and what areas are adequate. Green obviously means "at least as fast as Windows", which means that it's good. There is no point in grouping them any other way, since they don't care if they are 50% better or 1% better. Also, your criticisms of why this benchmark doesn't give a good idea of the relative speeds of Wine and Windows are quite wide of the mark (though they are valid complaints). The real reason why this benchmark cannot be used to gauge relative speeds is that it doesn't cover real world work loads. They measure a very small number of very specific things, mostly related to gaming and 3D performance. The benchmarks they ran that weren't related to that were designed to test the *hardware* speed, not the speed of the API. The Wine developers know this, and that's what the comment about taking it with a grain of salt means. It's probably adequate to give a rough idea of what parts of Wine need to be improved, but it is nowhere close to a comprehensive comparison of the speed of Windows and Wine, and was never meant as such.
Wine is most certainly a reverse engineering effort. The problem is that you don't fully understand what reverse engineering includes.
Reverse engineering also includes the following process:
This is black box reverse engineering. You treat some piece of software as a block box, write tests for it, figure out what the "box" is doing, and recreate that behavior. No decompilation required, no source code required, just lots of tests and ingenuity. This has the benefit that no copyright violations are required (since you never decompile the original program). This process is also used in clean room design, except step 3 is replaced with a documentation step -- instead of code being the result of the process a specification is the result. Compaq did this to reverse-engineer the IBM PC BIOS.
Wine is most certainly doing this, as it's the only way to determine undocumented connections between various APIs. Mono certainly does this ("what's this member supposed to do, and is Mono's version following that behavior properly?"). Another way to think of this is for bugs -- does this Mono code do what the .NET equivalent code does? If not, we'll get a bugzilla entry for it, and (eventually) fix it. This bug-report/fix cycle can also be considered as black box reverse engineering, since the bug-report is itself a test, through which we can determine what the actual functionality should be.
Decompilation is generally not legal, since it can lead to copyright violations. Black box reverse engineering is legal, and any attempt to limit black box reverse engineering would kill the interoperability market, since no compatible hardware/software could ever be created unless the original manufacturer permitted it.
Throughout most of my career, I've understood reverse engineering to be what you do when you DON'T have the source code. I think the wikipedia entry mentions that this is the most common interpretation. It can be extremely difficult and time consuming. I've done it on major projects a few times in my career. It is neither easy nor efficient, but sometimes the only choice you have.
It's also common to talk about reverse engineering hardware, where the innards of a chip may be deduced by observing its inputs and outputs. I worked on a project at a startup where we had to do that, because the original hardware developers were long gone, and no VHDL could be discovered, yet we had to write drivers for their (buggy) chips in order to make a deadline. At the same company we had to reverse engineer the workings of a (buggy) Fiber Channel PCI card, because the manufacturer would not give us the support we needed to make our deadlines. They were rather surprised when we talked to them about the details of their (proprietary, embedded in an ASIC) DMA engine that we deduced via logic analyzers and oscilloscopes.
Those projects were SO difficult compared to reading (even obscure) code, that I really think that using the one phrase for both activities is confusing and sometimes even deceptive.