Announcement

Collapse
No announcement yet.

Trying To Make Ubuntu 18.10 Run As Fast As Intel's Clear Linux

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

  • #21
    ITT people still think that libraries get loaded entirely and not only the parts that are actually used (mapped in memory, pages get allocated only when accessed the first time).

    Comment


    • #22
      Originally posted by s_j_newbury View Post
      There is an organised effort to learn from Clear Linux for Gentoo here: https://github.com/InBetweenNames/gentooLTO

      Of course Gentoo was ahead of game here, no doubt Clear Linux had a lot of groundwork prepared by Gentoo "Ricers"... err I mean users! ;-)
      Funny you mention that. I plan on switching from Antergos to Gentoo using that overlay. Just a combination of wanting a more optimized system, wanting to learn Linux a bit more, and wanting to get rid of SystemD. I want to like SysD, but I just can't. Not sure why. I don't want to start a SystemD pro/con thread.

      There's also Solus Linux which implements a lot of what Clear has done.

      If it wasn't for my need for a really intricate ZFS configuration I'd probably already be on Gentoo. Documentation for ZoL encryption (with the 0.8.0 beta) is pretty lacking right now, GRUB only likes certain ZFS settings so it has to be installed on a separate drive with special ZFS settings or with a different file system, then there's me never using Gentoo so I have to figure out what directory is used for what and set encryption, compression, dedup (I have assloads of ram), etc accordingly...but when you get it all right, damn is it worth it...lots of crap to do, but it'll be nice to be able to snapshot boot and root, emerge @world, and rollback if it breaks. It's real fun figuring all this out.

      Comment


      • #23
        The problem with running workloads inside Docker/containers is that the I/O performance can end up degraded.
        phoronix
        Michael

        This can be solved with 2 simple docker configs:

        Code:
           /usr/bin/docker run  \
                -v /srv/:/srv \
                --net host \
                --ulimit nofile=65535 \
                your_docker_image
        the -v will bind mount the host /srv to the docker /srv, making any IO on this path as the real host IO call, not layers involved so no performance lost. Of couse, no snapshots, layer discard, docker pause, can be applied to this bind mount. Also, not recommended to have multiple docker using the same files (but also depend a lot of what it is trying to do)

        the -net host will allocate the docker network directly to the host, so again no translation layers nor conversions. Network performance will be almost as the real host performance. Of course, this way you can only have one port 80 service for all dockers, so not all people can use it as it may block running multiple dockers that require the same ports... but when it can be used, you get the native network performance. We use different port numbers for each app, environment, site, etc so we do not have port collision.

        the --ulimit is just for any container that may be hitting limits, can be expanded or removed depending of what the docker image need.

        We use this docker config in almost all ours services and in all benchmarks we have done, you get almost the same performance as running in the host directly. As having containers make it easier to control and test, we use this for almost everything... we even run the mysql server inside a container

        Anyway, if you want to test docker without network and disk degradation due to the docker layers, use this options
        Last edited by higuita; 31 October 2018, 05:18 PM.

        Comment


        • #24
          Originally posted by dungeon View Post

          I think 2.28 they both use now, so that is not a reason of possible diff anymore:



          I don't see so much big difference like before, as you can see in these benchmark results it mostly comes from clear docker now

          So we can conclude that glibc version was indeed primary reason for big difference before
          2.26+ has some optimisatons that Intel does at https://clearlinux.org/blogs/transpa...l-architecture

          Comment


          • #25
            There are two significant optimisations in Clear Linux that are hard to replicate:

            - this huge collection of performance related patches that might clash with another distro's patchset: https://github.com/clearlinux-pkgs

            - AutoFDO that only works on Intel CPUs: https://clearlinux.org/blogs/improve...imizer-autofdo - this can probably be replaced with PGO that works everywhere and needs the same profiling run as AutoFDO, so only compile/link flags differ

            Comment


            • #26
              Originally posted by AndrewDB View Post
              The next important question of course is, do you really need that extra speed in most cases,
              In an overpopulated world strained on resources, with climate change, code that is compiled in a way that runs inefficiently is selfish and immoral and unacceptable. The number of people using modern PCs that are crippled by code that is compiled to be able to run on PCs older than the sun is way, way too high. And then we can get into talking about productivity loss of each of those users - computers are a large part of most of human productivity and even a tenth of a percent increase per user would be significant over the population. Plus, even minor slowdowns in software can make UX really bad, and thus all speedups are likely to reduce user frustration. And yes, almost all software I use has seemingly nonsensical, and sometimes major, slowdowns that do frustrate many people including myself on a daily basis. Reducing those even by a slight amount would increase UX. Both speed and power efficiency should be MAJOR goals of every operating system, and the answer to your question is always yes, no exceptions.

              This isn't a Linux-specific problem but it affects Linux just as much as any other.
              Last edited by Holograph; 02 November 2018, 10:57 AM.

              Comment


              • #27
                Originally posted by Holograph View Post
                In an overpopulated world strained on resources, with climate change, code that is compiled in a way that runs inefficiently is selfish and immoral and unacceptable. The number of people using modern PCs that are crippled by code that is compiled to be able to run on PCs older than the sun is way, way too high. And then we can get into talking about productivity loss of each of those users - computers are a large part of most of human productivity and even a tenth of a percent increase per user would be significant over the population. Plus, even minor slowdowns in software can make UX really bad, and thus all speedups are likely to reduce user frustration. And yes, almost all software I use has seemingly nonsensical, and sometimes major, slowdowns that do frustrate many people including myself on a daily basis. Reducing those even by a slight amount would increase UX. Both speed and power efficiency should be MAJOR goals of every operating system, and the answer to your question is always yes, no exceptions.

                This isn't a Linux-specific problem but it affects Linux just as much as any other.
                Amen brother.

                Don't forget slower code = much more power wasted as well. Slow code contributes to global warming.

                Comment


                • #28
                  Maybe if you try with Debian instead of Ubuntu, you will get couple of more wins.

                  Comment


                  • #29
                    So something that's been bugging me since last year's article, where do you find the compile flags that clear linux uses? I've never been able to find a list of flags that are the same as the list provided on the first page of this article. Where are you getting these from?

                    Comment

                    Working...
                    X