• thelittleblackbird@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    8 days ago

    Ummmm sure?

    I don’t want to start that extremely old flame war of native VS jit code but…

    Proton is not an emulation, it is a translation to native code, and while it has some drawbacks (more memory usage, more time at start up to compile things) it can unlocks a lot of potential when the hw support new capabilities, this is the reason that some dx10 games run faster on Linux…

    • KubeRoot@discuss.tchncs.de
      link
      fedilink
      English
      arrow-up
      0
      ·
      8 days ago

      I might be wrong, but I don’t think proton is either? It’s running x86 instructions either way, wine just provides a way to load it from the windows executable and library formats, and together with proton they provide implementations of windows libraries for those executables to use.

      • bufalo1973@piefed.social
        link
        fedilink
        English
        arrow-up
        0
        ·
        8 days ago

        I guess most of the process is just using a wrapper to translate the call to a Windows library to the equivalent call to a Linux library.

        • KubeRoot@discuss.tchncs.de
          link
          fedilink
          English
          arrow-up
          1
          ·
          5 days ago

          I think most of the work is in the fact that there often isn’t an “equivalent call”, and it can be quite a lot of code to make it work. One funny thing is the whole esync-fsync-ntsync issue, where synchronization is done differently on Linux and on windows, and translating it was a big performance hit, and difficult to do accurately. If I understood correctly, esync, fsync and ntsync were a series of kernel patches implementing additional synchronization code in the kernel, with ntsync actually replicating the windows style.