←back to thread

Games run faster on SteamOS than Windows 11, Ars testing finds

(arstechnica.com)
400 points _JamesA_ | 5 comments | 25 Jun 25 19:40 UTC | HN request time: 1.524s | source
Show context
lenerdenator ◴[26 Jun 25 02:15 UTC] No.44383647[source]▶
When SteamOS and Ganoo/L00nockz become first-class gaming citizens, that's when I'm building a gaming PC for the first time since 2012.

I'm a Mac guy now mainly because of my job and I like UNIX-y stuff now, but of course, gaming is even more lacking than Linux.

We're so close. Once AAA releases and GPU drivers get there, it's over the cliff, and I could see that being in the next five years.

replies(4): >>44383851 #>>44384415 #>>44387154 #>>44388086 #
arvinsim ◴[26 Jun 25 03:02 UTC] No.44383851[source]▶
I have always wanted Windows to move to Unix so that I can have the best of both worlds(software development and video games). Glad that we are close to that reality.
replies(1): >>44385390 #
1. windward ◴[26 Jun 25 08:32 UTC] No.44385390[source]▶
You'd also need a sane filesystem.
replies(1): >>44387949 #
2. p_ing ◴[26 Jun 25 14:43 UTC] No.44387949[source]▶
Windows has NTFS and ReFS. Both are quite sane and performant.
replies(1): >>44388597 #
3. windward ◴[26 Jun 25 15:53 UTC] No.44388597[source]▶
I know. Neither are either. git is noticeably slower, the locking is untenable, the case-insensitivity is a source of bugs.
replies(2): >>44388962 #>>44390677 #
4. p_ing ◴[26 Jun 25 16:33 UTC] No.44388962{3}[source]▶
Both file systems support case sensitivity.

Use DevDrive in a virtual disk or secondary volume, there are significant performance gains for things like git, nodejs modules, etc.

It helps to know the system. The perf would be an issue with any file system on Windows due to the file system filter architecture.

Locking is a function of the NT executive and not of the file system. It was a design decision. I’ll see if I can dig up the reasoning later.

5. p_ing ◴[26 Jun 25 19:55 UTC] No.44390677{3}[source]▶
From the NT Design Workbook, oplocks.

> Because the NT OS/2 I/O system is asynchronous by nature, the ability to make a request and then have it completed at a later time makes it natural for implementing oplocks. Further, because synchronization is required by the file system to determine when the caller has completed its oplock update transfers, the file system can use this feature to block open requests to a file by queueing the I/O Request Packet (IRP) to its internal file control structure until the oplock owner lets it know that it is finished.