I guess I’m behind in times as wouldn’t emulation cause the game to be slower on Linux than on Windows?
I tried switching to Linux when I was a kid, but figured out quickly that my scrap computer could only play my games natively. I’m not sure how it wouldn’t always be slower on Linux unless the game was built for Linux.
It is a translation layer. All it’s doing is intercepting syscalls embedded in the executable process by presenting what looks like an interface for the kernel it is trying to call, but is actually a translation layer to the true host kernel, mapping the Windows syscalls to their near-equivalent for the Linux kernel. This differs from emulation as the calls are being translated at a higher level whereas emulators translate the low level machine code sent to the processor.
So Proton and Wine essentially just pretend to be the core Windows processes and services a Windows environment provides to applications. It’s a Windows interface to a Linux kernel on the backend. And virtually every syscall on Linux will always be faster than on Windows/NT. So you get faster syscall responses with a neglible and wholly insubstantial added overhead that I would reckon is hard to quantify because it is in fact so damn small that the only way I can think of to observe it is to attach a debugger, which slows down the application process notably so that human’s can peer into the execution stack.
TL;DR: no, Windows applications have theoretically been faster on Linux than they ever were on Windows since Wine’s inception.
really did not expect today to be my turn to recite the infamous WINE homily. Whoever sends out the t-shirts, I’m a men’s x large, hopefully there are still some of that size unclaimed
In case you’re unaware, the “deep inhale” is because that phrasing is historically tied to the WINE project, as per their website (winehq.org):
Wine (originally an acronym for “Wine Is Not an Emulator”)
And at this point it’s like a 10-year old meme (if not 20) to bring it up when someone may seem unaware of the distinction between emulation and what Wine does.
It is a bit tired of a reference, and I imagine somewhat off-putting of a response to receive when you don’t know the reference yourself. The acronym is in the spirit of the GNU one (“GNU’s Not Unix”), and as the other commenters have explained the fact that wine does something different than emulation is very relevant when you get into the nitty-gritty details, so it has extra sticking power in terms of memes in linux/foss communities.
This exactly. I’d had a long day and never before had the opportunity to be first in a thread to reply with “Wine Is Not an Emulator”, so I got over-excited and typed that all out so I could get that sweet dopamine rush.
Others replied about WINE translation layer, but once binary is loaded in memory the kernel juat runs the code it does not care that it is linux or windows code, because to the systembit is chip instructions. It is why LinuxOS was fully able to run DOS way back when
So from my experience, I replaced my 8+ year old omen laptop with an MSI 3 years ago then installed garuda on the omen. Tested some games on each and the performance was similar until graphics were set to ultra just dye to the hardware difference. Before installing linux that laptop performance was struggling, so it really breathed life back into it and made it viable again. Hell my wife uses it to play stardew valley now and I used it to play ffxiv a few times.
The translation is more like a reimplementation, and sometimes that reimplementation is faster than native. But it’s also because the Linux kernel is faster in some areas, and typically more memory efficient too.
And it’s partly also the quality of GPU drivers, especially in the case of AMD (although they have been getting better on the Windows side in recent years).
It’s not really emulation. It’s running on the same architecture and most of the windows libraries can be used as is with mostly only the win32 library that needs to be wrapped. That already existed for years as wine. It’s mostly graphics and peripherals that are broken.
The most important thing proton added to improve gaming was a DirectX translation layer that translates to Vulcan and also loads of fixes and additions to wine.
Not a lot of games run faster but apparently in some situations, the Vulcan precompiled shaders seem to run better than native windows, although that probably means they could make their native version better as well. For older games, the Vulcan translation layer is a lot more efficient and faster than native. Also CPU and IO heavy games might run faster on the Linux kernel.
I guess I’m behind in times as wouldn’t emulation cause the game to be slower on Linux than on Windows?
I tried switching to Linux when I was a kid, but figured out quickly that my scrap computer could only play my games natively. I’m not sure how it wouldn’t always be slower on Linux unless the game was built for Linux.
deep inhale
WINE IS NOT AN EMULATOR
It is a translation layer. All it’s doing is intercepting syscalls embedded in the executable process by presenting what looks like an interface for the kernel it is trying to call, but is actually a translation layer to the true host kernel, mapping the Windows syscalls to their near-equivalent for the Linux kernel. This differs from emulation as the calls are being translated at a higher level whereas emulators translate the low level machine code sent to the processor.
So Proton and Wine essentially just pretend to be the core Windows processes and services a Windows environment provides to applications. It’s a Windows interface to a Linux kernel on the backend. And virtually every syscall on Linux will always be faster than on Windows/NT. So you get faster syscall responses with a neglible and wholly insubstantial added overhead that I would reckon is hard to quantify because it is in fact so damn small that the only way I can think of to observe it is to attach a debugger, which slows down the application process notably so that human’s can peer into the execution stack.
TL;DR: no, Windows applications have theoretically been faster on Linux than they ever were on Windows since Wine’s inception.
I think you mean:
Wine is not an emulator ^is ^not ^an ^emulator ^^is ^^not ^^an ^^emulator ^^^is ^^^not ^^^an ^^^emulator ^^^^is ^^^^not ^^^^an ^^^^emulator ^^^^^is ^^^^^not ^^^^^an ^^^^^emulator ^^^^^^…
really did not expect today to be my turn to recite the infamous WINE homily. Whoever sends out the t-shirts, I’m a men’s x large, hopefully there are still some of that size unclaimed
Thanks for the information, no need for the deep inhale lol.
In case you’re unaware, the “deep inhale” is because that phrasing is historically tied to the WINE project, as per their website (winehq.org):
And at this point it’s like a 10-year old meme (if not 20) to bring it up when someone may seem unaware of the distinction between emulation and what Wine does.
It is a bit tired of a reference, and I imagine somewhat off-putting of a response to receive when you don’t know the reference yourself. The acronym is in the spirit of the GNU one (“GNU’s Not Unix”), and as the other commenters have explained the fact that wine does something different than emulation is very relevant when you get into the nitty-gritty details, so it has extra sticking power in terms of memes in linux/foss communities.
This exactly. I’d had a long day and never before had the opportunity to be first in a thread to reply with “Wine Is Not an Emulator”, so I got over-excited and typed that all out so I could get that sweet dopamine rush.
Others replied about WINE translation layer, but once binary is loaded in memory the kernel juat runs the code it does not care that it is linux or windows code, because to the systembit is chip instructions. It is why LinuxOS was fully able to run DOS way back when
One would think that, but I’ve seen many claims that it actually runs faster. I wouldn’t know personally, I haven’t used Windows in 5 years
So from my experience, I replaced my 8+ year old omen laptop with an MSI 3 years ago then installed garuda on the omen. Tested some games on each and the performance was similar until graphics were set to ultra just dye to the hardware difference. Before installing linux that laptop performance was struggling, so it really breathed life back into it and made it viable again. Hell my wife uses it to play stardew valley now and I used it to play ffxiv a few times.
Maybe it’s a case of less bloat in Linux over Windows?
The translation is more like a reimplementation, and sometimes that reimplementation is faster than native. But it’s also because the Linux kernel is faster in some areas, and typically more memory efficient too.
And it’s partly also the quality of GPU drivers, especially in the case of AMD (although they have been getting better on the Windows side in recent years).
It’s not really emulation. It’s running on the same architecture and most of the windows libraries can be used as is with mostly only the win32 library that needs to be wrapped. That already existed for years as wine. It’s mostly graphics and peripherals that are broken.
The most important thing proton added to improve gaming was a DirectX translation layer that translates to Vulcan and also loads of fixes and additions to wine.
Not a lot of games run faster but apparently in some situations, the Vulcan precompiled shaders seem to run better than native windows, although that probably means they could make their native version better as well. For older games, the Vulcan translation layer is a lot more efficient and faster than native. Also CPU and IO heavy games might run faster on the Linux kernel.