Announcement

Collapse
No announcement yet.

Initial Benchmarks Of Microsoft's WSL2 - Windows Subsystem For Linux 2 On Windows 10 Is A Mixed Bag

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

  • #21
    I see what they did, they bypassed their own shitty ass IO subsystem so HyperV could manage it instead. If IO occurs inside a vm, then that should be enough to prevent windows from flooding the CPU with context switches. And if they don't have hardware virtualisation implemented or not implemented well, then that would explain the poor compute performance. Typical MS.....

    Comment


    • #22
      Originally posted by dragorth View Post
      I wonder how many cores WSL2 allocates? Doesn't WSL1 allow the use of all available cores? Could this be some of the issue in this testing, in addition to this being prerelease and based on Hyper-V?
      I think you are most likely correct. WSL2 for me only allocated 8 vcpus (I have 32 available in WSL1) and I haven't found a way to override that via Hyper-V commands ala Set-VMProcessor. I asked the MS devs about it a few days ago, but they never responded.

      Comment


      • #23
        Originally posted by polarathene View Post

        I don't quite get what you're saying here about Docker? Docker shares a kernel with it's docker host, doesn't virtualize it.
        Docker is a container. You're misunderstanding what i'm saying.

        andy22 They can do it wrong, I don't care. I understand it's a hard thing to hear but you don't have to run your containers in a VM nor should you. The correct approach is containers on metal. Linux containers also have more security issues than other container systems because of the way they were designed. (CGroups and Namespace)

        Comment


        • #24
          Originally posted by k1e0x View Post

          Docker is a container. You're misunderstanding what i'm saying.

          andy22 you don't have to run your containers in a VM nor should you. The correct approach is containers on metal. Linux containers also have more security issues than other container systems because of the way they were designed. (CGroups and Namespace)
          I know that Docker is containers not VM. You didn't quite clarify what I was asking, instead just saying I misunderstand? Well no shit... I specifically said "I don't quite get what you're saying".

          In mac and to a degree windows, your containers have to run in a VM anyway. This doesn't mean it's bad to run a container in a VM on linux too though, you can get pretty much bare metal performance if you use KVM properly, which addresses those security issues you bring up about it.

          Comment


          • #25
            Originally posted by polarathene View Post

            I know that Docker is containers not VM. You didn't quite clarify what I was asking, instead just saying I misunderstand? Well no shit... I specifically said "I don't quite get what you're saying".

            In mac and to a degree windows, your containers have to run in a VM anyway. This doesn't mean it's bad to run a container in a VM on linux too though, you can get pretty much bare metal performance if you use KVM properly, which addresses those security issues you bring up about it.
            You don't need to run a Linux kernel to run GNU/Linux binaries, if a binary can find all the system call APIs the Linux kernel has then it just runs. Many other people have done it. Sun, FreeBSD etc (Wine did the reverse) if they can do it I don't see why some of the largest software development companies on the planet can't. Yes they have more work to do.. but they have a lot more resources to do it.
            Last edited by k1e0x; 15 June 2019, 10:18 PM.

            Comment


            • #26
              Originally posted by k1e0x View Post
              You don't need to run a Linux kernel to run GNU/Linux binaries, if a binary can find all the system call APIs the Linux kernel has then it just runs. Many other people have done it. Sun, FreeBSD etc (Wine did the reverse) if they can do it I don't see why some of the largest software development companies on the planet can't. Yes they have more work to do.. but they have a lot more resources to do it.
              Except Linux kernel syscalls applications use don't stay the same. FreeBSD linux syscall implementation has many limitations that is with a kernel with permission model close to the Linux kernel. Windows NT has a complete alien permission model to the Linux one.

              It would be good if the interfaces you need to support only stopped at userspace but that is not the case.
              https://cilium.io/ and seccomp https://lwn.net/Articles/656307/ come to mind.

              Result of containers using BPF for security is you don't only have to implement the Linux kernel syscalls you have to implement all the BPF hooks as well and a BPF verifer and BPF JIT for performance.

              So you have all the syscalls of Linux + all the /proc directory files + all the /sys directory files + all the cgroup files and finally all the BPF stuff hooks. By this point you have had to fairly much rewrite the complete core of the Linux kernel.

              k1e0x you are basically underestimating how big of a nightmare this is. WSL1 just cannot do it. And by the time you implement all the hooks traps and conversions you will end up with something slow.

              Comment


              • #27
                I'm not sure I'd call Clear Linux the "gold standard" for Intel performance on Linux just yet. Michael has shown it has some "clear" advantages here and there, but the reality is that it is far from production or daily driver ready. Those looking for a drop-in replacement for Arch or Gentoo for optimization alone should LOOK ELSEWHERE. Several major factors will limit Clear Linux use as a current development desktop:


                1) limited bundle selection/number - the OS design limits the number of bundles used, and individual packages aren't accessible easily. It is built mainly around container/infrastructure, with development as a secondary focus. Optimized binaries for math or other domains are a far lower priority.

                2) reliance on flatpak for "undesirable" packages - if you want something added, and it exists in flatpak, you will be told to use that and not a native solution. Further, generating a native solution isn't trivial, but the included tools and documentation are extensive.

                3) #1 and #2 are both side-effects of the stateless design philosophy of the OS. Which makes a lot of sense for infrastructure / container OS, but not a lot for a desktop

                4) it is far buggier than Arch or Gentoo, and obscure breakages are often not prioritized. See github issue list before venturing forth. This is especially frustrating when diagnosing your own system.

                That said, I keep Clear on a second drive and check it frequently. The build system that Clear uses is a really neat setup, and could be a powerful tool for building optimized packages. Some of the above issues are also due to the size of the development team. Every one of them have been responsive to issues and on top of things as time permits.

                Comment


                • #28
                  Anyone know what Clear is doing with lame to get it so fast?

                  Comment


                  • #29
                    Originally posted by willmore View Post
                    Anyone know what Clear is doing with lame to get it so fast?
                    They do a lot of profiling. I can't answer specifically for lame though, I do know that many of their optimizations are not safe. Basically under no circumstance should clear linux be used in a production environment. Most of the modifications they make aren't even available in patches and would have to be manually duplicated. And quite a lot of them are hardcoded modifications. I think optimizing linux is a great idea, but the way Clear linux does it is just plain ignorant and selfish and unsafe.

                    Comment

                    Working...
                    X