- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
Linux vs Windows tested in 10 games - Linux 17% faster on Average::Computers, hardware, software and gaming in Spanish and English
Linux vs Windows tested in 10 games - Linux 17% faster on Average::Computers, hardware, software and gaming in Spanish and English
It must be very hard to exactly compare games between Windows and Linux because it’s possible that emulation in Proton, WINE or the driver means some settings or extensions might not be enabled even if they appear to be. DirectX emulation is also bound to slow things down so a game probably has to be use OpenGL or Vulkan directly.
So while I can well believe that Linux can keep up and possibly exceed Windows, it needs a careful technical eye to ensure a true comparison is happening.
Wine is not an emulator
Wine is an emulator. It might not have started as such when it was winelib but it is now, especially when running binaries. If in doubt read their own FAQ where they take pains to describe it depends what you’re doing and what is meant by emulation.
Go read the code. It’s a reimplementation of core Windows DLLs. Quite a clean one. There is also a daemon that fakes a NT kernel. It’s worth a read.
I know what it is thanks. I even contributed code a long time back to it.
Then why are you saying it’s going to pay any kind of emulation cost? It’s not really much different to what MS do. NT has it’s own sys calls that MS call in their Win32 implementation. WINE calls POSIX calls in their’s.
Well done contributing anyway. I haven’t, but I crawled all over the source when I developed on Windows as it was better than MSDN for the semi-documented stuff (that was only documented at all because EU forced them).
I didn’t and I don’t know where you got the idea I did.
Cool, well happy it was just a miss understanding, but I’m clearly not the only one who thought you were saying that. Might be worth clarifying in you earlier posts.
but the E literally stands for emulator
(I’m kidding)
Just in case someone sees this and doesn’t understand all this, WINE is an acronym that literally means “WINE Is Not an Emulator.”
And it is an emulator these days. Their own website says it and it’s obviously one just thinking about it for a second. The reason it started with that acronym was because originally you could take Windows source code, compile it against winelib and run it natively. It is an emulator when actual Windows binaries are executed against it.
I suppose I am not sure entirely what constitutes an emulator and what doesn’t, but I always thought an emulator mimics (emulates) a certain systems architecture, i.e. has to be slower by design than the real thing. In wine, however, windows system calls are replaced / re-routed to the underlying linux system calls which are often much faster, which is why wine often exceeds windows in performance executing windows binaries (assuming you can get them to run at all :)
An emulator simulates hardware with software. That’s why it’s slower than running on the original hardware, unless you’re running on a hardware significantly faster than the original.
But Wine is not an emulator because it mimics software with different software. You still run on the same hardware, that’s why wine/proton only runs on x86.
So the whole “wine is not an emulator” might sounds like pedantry but it’s not. It’s an important distinction. Because it’s not an emulator there is no inherent perf cost.
thanks, this is exactly my understanding, just worded better because I was apparently linguistically challenged on my previous post… :D
WINE has a FAQ on the matter - https://wiki.winehq.org/FAQ#Is_Wine_an_emulator.3F_There_seems_to_be_disagreement
Short story, it depends what you use WINE for and the perspective you’re looking from. I think from a binary’s POV that thinks it is calling Windows OS it is emulation.
It’s getting hard to do just between AMD and Nvidia on Windows.
I’m old enough to remember the days when reviewers showed macro shots of the wires in half life 2 to test AA between different cards.
Does anyone even test that enabling “Ultra” settings results in the same configuration across vendors/generations? I’m pretty sure LTT Labs found cases where it wasn’t.
ltt labs, good one
To be fair if anyone is motivated to discover flaws in testing methodology and publicly disclose them right now it’s Labs.