Announcement

Collapse
No announcement yet.

Wine 3.10 vs. Ubuntu 18.04 vs. Windows 10 Desktop Performance

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by duby229 View Post
    No it does -not-. You need to look at what CSMT actually does. It causes every core to constantly context switch, it flushes and refills every pipeline repeatedly. And while it's doing that it's incapable of doing -anything- else. It wastes almost every cycle on every core.
    Not sure how I missed this (sorry), but FYI Wine is not a kernel-land application. So it can't control context switching directly, only on threads. Threads are an abstraction offered by the kernel.

    Context switches are slow, but what's really slow with them is synchronization, since it's on the order of micro-seconds. That's 1000 times slower than nanoseconds btw. Busy waiting avoids this particular problem at the expense of fully utilizing the thread that's waiting. With busy waiting the result will be ready as soon as it is ready, not 1000 nanoseconds later.
    Last edited by Weasel; 23 June 2018, 03:26 PM.

    Comment


    • #42
      Originally posted by Michael View Post

      I guess you didn't read the text of the article to understand the point of these benchmarks.
      No i read it, its simple logic, why benchmark some use case with minor importance, before some really important use cases are tested? Its like journalism is good to write articles, about something what really interesting for people, otherwise your are wasting paper and time. There were not Wine tests for long time and first one should be about major use cases.

      Its like OpenArena testing, its game which nobody playing and Windows port is bad, it dont much all other benchmarks results.. even if difference in performance would be 100%, who cares about such results?
      Wine is for games, MS office and Photoshop.. if zillions generic multi platform benchmarks / apps with few users has good performance in Wine and major apps dont, it means that Wine is failing for majority of its users and their plans..

      Comment


      • #43
        Originally posted by ruthan View Post
        Its like journalism is good to write articles, about something what really interesting for people, otherwise your are wasting paper and time.
        Michael is awesome at what he does and the fact he has so many people on his forums, is so widely quoted by outside source and that he is running a successful business doing it is all the evidence anyone should need of that. If you think he could improve upon what he does, you might want to first think about how you could improve on your interpersonal skills.

        Also: just because you don't find one article interesting and useful doesn't mean other don't.

        Comment


        • #44
          Originally posted by ruthan View Post
          Wine is for games, MS office and Photoshop..
          Keep your opinion to yourself. You don't own Wine and you're not the center of the world so who are you to speak what it is made for?

          Wine is for every Windows application that runs on it.

          I'd really appreciate if Michael tested with WINEDEBUG=-all as previously mentioned though (in this case probably not much difference I guess, except maybe the file benchmark).

          Comment


          • #45
            Its more important for Wine to have compatability with Windows apps, preferably 99%, over speed. I'd rather be able to run the apps a little bit more slowly, rather than not at all.

            Comment


            • #46
              Originally posted by Weasel View Post
              Not sure how I missed this (sorry), but FYI Wine is not a kernel-land application. So it can't control context switching directly, only on threads. Threads are an abstraction offered by the kernel.

              Context switches are slow, but what's really slow with them is synchronization, since it's on the order of micro-seconds. That's 1000 times slower than nanoseconds btw. Busy waiting avoids this particular problem at the expense of fully utilizing the thread that's waiting. With busy waiting the result will be ready as soon as it is ready, not 1000 nanoseconds later.
              You don't know how processors work? I mean that is more or less what you just said.... Context switching is something a processor does when a thread gets interupted, and when it happens it flushes and refills the pipeline. It's even worse on SMT cores because both threads get flushed even if they are completely unrelated. And while a core is flushing and refilling it is incapable of doing anything at all. It can't even wait!! It's not waiting, it's flushing and refilling over and over endlessly. Even if it could do something it can't. Context switching gets triggered by software that interupts a thread. And that's exactly what CSMT does and in fact is -designed- to do. It almost as if it was intentionally made to cripple every processor it touches such that it isn't capable processing anything at all!! CSMT is completely retarded.
              Last edited by duby229; 24 June 2018, 07:04 AM.

              Comment


              • #47
                Originally posted by duby229 View Post
                You don't know how processors work? I mean that is more or less what you just said.... Context switching is something a processor does when a thread gets interupted, and when it happens it flushes and refills the pipeline. It's even worse on SMT cores because both threads get flushed even if they are completely unrelated. And while a core is flushing and refilling it is incapable of doing anything at all. It can't even wait!! It's not waiting, it's flushing and refilling over and over endlessly. Even if it could do something it can't. Context switching gets triggered by software that interupts a thread. And that's exactly what CSMT does and in fact is -designed- to do. It almost as if it was intentionally made to cripple every processor it touches such that it isn't capable processing anything at all!! CSMT is completely retarded.
                Man, userland software does not control the context switching directly. The kernel interrupts threads (or cores) and does context switching at its leisure. How else would you have two threads running in a single processor system? There's a massive amount of context switches even with threads that have no "waiting" at all if your CPU is single core because the kernel decides to run them for small amounts of time each (unless one is higher priority).

                Of course, when you use synchronization then a context switch is guaranteed, that's why it's so slow. But you don't control when a spinlock (busy waiting loop) gets context switched, only the kernel decides. That's why spinlocks are usually faster if you don't have to wait a lot of time because they avoid context switches (and also ONLY if you have free CPU cores available to use by the kernel, otherwise it's a massive drag, literally wasted time).

                CSMT would thus be horrible if you don't have enough free (unused) cores.

                Comment


                • #48
                  Originally posted by Weasel View Post
                  Man, userland software does not control the context switching directly. The kernel interrupts threads (or cores) and does context switching at its leisure. How else would you have two threads running in a single processor system? There's a massive amount of context switches even with threads that have no "waiting" at all if your CPU is single core because the kernel decides to run them for small amounts of time each (unless one is higher priority).

                  Of course, when you use synchronization then a context switch is guaranteed, that's why it's so slow. But you don't control when a spinlock (busy waiting loop) gets context switched, only the kernel decides. That's why spinlocks are usually faster if you don't have to wait a lot of time because they avoid context switches (and also ONLY if you have free CPU cores available to use by the kernel, otherwise it's a massive drag, literally wasted time).

                  CSMT would thus be horrible if you don't have enough free (unused) cores.
                  CSMT is horrible period.... It doesn't matter how many cores your processor has 1 or 100 CSMT is designed to thrash it to a complete dead halt.

                  Comment


                  • #49
                    Originally posted by duby229 View Post
                    Yes CSMT causes major issus. It causes massive amounts context switching. It forces every core to constantly flush and refill over and over. When you turn on CSMT and you see every core hit 100% CPU use, that's not because those cores are busy, instead it's because they are -NOT- busy at all and only flushing and refilling. Just because CSMT thrashes your CPU doesn't mean its doing anything useful, its actually not.
                    Is this with a specific game?

                    Comment


                    • #50
                      Pretty impressive performance overall.

                      I can confirm the poor file creation performance though. I recently installed Stars in Shadow under Wine that unpacked ~40000 files (quite stupid to have that many files, but nothing I can do). Even with an SSD, as far as I remember it took ~2 hours. Oh, and by the way, Stars in Shadow runs fine-ish, with some non-game-breaking graphics artifacts (r600+AMD CPU). Someone should add it to appdb...

                      Comment

                      Working...
                      X