Announcement

Collapse
No announcement yet.

Preview: Ubuntu's Performance Over The Past Two Years

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

  • #91
    Originally posted by BO$$ View Post
    Snoooor. We were talking about desktop linux. Where most of the time such optimizations are just a rogue programmer showing off, sacrificing code readability thinking he's clever.
    then would be fun hear you whine cuz some guy was lazy to optimize his code and your wifi card take 5m to get signal or crying because some dev that like you thinked "lol SSD are cheap enough this days, why worry about excessive write operations" when your SSD wear out in some months instead of years or have your fast enough core2 computer boot in 5m because you know it works in haswell fast enough, so why care.

    1 small optimization maybe is uninteresting but thousands of small optimizations make a big difference

    Comment


    • #92
      Originally posted by frign View Post
      You might want to check out the eudev-project, which is a fork of udev.
      Once could literally spend months optimizing the crappy code there (and the eudev-devs have already done a great job on that).
      For example, you often stumble upon loop-declarations like this, which are unoptimisable by the compiler (from libudev-device.c):

      Code:
      for (;;) {
          if (*b == 0)
              return (char*) a;
          if (tolower(*a) != tolower(*b))
              return NULL;
          a++, b++;
      }
      Fix (could be better, with pre-increments and a safer loop):
      Code:
      for (; *b; a++, b++){
          if (tolower(*a) != tolower(*b))
              return NULL;
      }
      return (char*) a;
      Some people really should change their mindsets about how to write software. Excusing yourself with faster computers leads to this careless coding-style and performance-bottlenecks add up, even in home-computing.
      it looks like fun certainly, ill check systemd code and study those loops[i switched to systemd all my gentoo boxes] but certainly those loops are UGLY and using chars that way could lead to many not so funny things.

      mmm this look like could be ported to use more safer types but ill have to track why in freezing hell they need to use char and even worse compare them inside a loop

      Comment


      • #93
        What the function does

        Originally posted by jrch2k8 View Post
        it looks like fun certainly, ill check systemd code and study those loops[i switched to systemd all my gentoo boxes] but certainly those loops are UGLY and using chars that way could lead to many not so funny things.

        mmm this look like could be ported to use more safer types but ill have to track why in freezing hell they need to use char and even worse compare them inside a loop
        Remember, those are char-arrays. It is a string-modification-function, which strips a certain prefix from a given string.

        Let's say b is "message_" and a is "message_outgoing";
        The function effectively removes the prefix and returns a* "outgoing".

        In case a doesn't begin with "message_", the function returns NULL.
        When we reach the end of b (the terminating NULL-character), the function returns a*.

        Given the fact b could be ill-formed and never contain a NULL-character, you're right: This function could be safer.

        Comment


        • #94
          Originally posted by frign View Post
          Remember, those are char-arrays. It is a string-modification-function, which strips a certain prefix from a given string.

          Let's say b is "message_" and a is "message_outgoing";
          The function effectively removes the prefix and returns a* "outgoing".

          In case a doesn't begin with "message_", the function returns NULL.
          When we reach the end of b (the terminating NULL-character), the function returns a*.

          Given the fact b could be ill-formed and never contain a NULL-character, you're right: This function could be safer.
          well that much i get but i'm not a friend of handling logic messing with actual words unless is absolutely necessary[except for php/JS] but i need track to kernel side API to check if this is imposed by the interface[this is what i meant, my bad] maybe it can be improved with other datatypes or re factoring the algorithm logic, ofc i need some time to study the code for that

          Comment


          • #95
            Algorithm

            Originally posted by jrch2k8 View Post
            well that much i get but i'm not a friend of handling logic messing with actual words unless is absolutely necessary[except for php/JS] but i need track to kernel side API to check if this is imposed by the interface[this is what i meant, my bad] maybe it can be improved with other datatypes or re factoring the algorithm logic, ofc i need some time to study the code for that
            If we knew for sure that a begins with b, then it would be as simple as a = a + strlen(b).
            Because that's not the case, we have to do it with this technique.

            It's also not logic-messing, but the processing of device-identifiers (part of eudev), so there's no real way around char-arrays, which are factually 8 bit unsigned-integer-arrays (effective enough) and in need to be returned.

            In case you have a better idea, please let me know.

            Comment


            • #96
              It's still getting there. I'd have to say that 10.04 was pretty much the fastest release I've ever used. System speed slowed down in releases after (even with Xubuntu), but 13.04 is somewhat closer to getting back. I tried out the Ubuntu 13.10 Alpha dev release for awhile and was pretty impressed with the speed. That was with Unity running so hoping that Xubuntu 13.10 will be equally speedy.

              Comment


              • #97
                Originally posted by frign View Post
                If we knew for sure that a begins with b, then it would be as simple as a = a + strlen(b).
                Because that's not the case, we have to do it with this technique.

                It's also not logic-messing, but the processing of device-identifiers (part of eudev), so there's no real way around char-arrays, which are factually 8 bit unsigned-integer-arrays (effective enough) and in need to be returned.

                In case you have a better idea, please let me know.
                well i have some idea like XML/UUID for device identifiers/atomic operation but i need to update my knowledge since i got those ideas when udev and hal were mainstream and many things changed from those days

                Comment


                • #98
                  Originally posted by synaptix View Post
                  It's still getting there. I'd have to say that 10.04 was pretty much the fastest release I've ever used. System speed slowed down in releases after (even with Xubuntu), but 13.04 is somewhat closer to getting back. I tried out the Ubuntu 13.10 Alpha dev release for awhile and was pretty impressed with the speed. That was with Unity running so hoping that Xubuntu 13.10 will be equally speedy.
                  Did you use vanilla 13.10 or did you use the XMir PPA? Because the first, right now, gives a false impression which doesn't correlate for Unity with what end users will see, since right now it uses X.org. For Xubuntu, the alpha is closer to what you will get, since it will keep using X.org on 13.10.

                  Comment


                  • #99
                    Originally posted by frign View Post
                    The good side-effect of knowing Gentoo is that when I get to setup Debian on a client's computer I know how to fix problems, because I learned how it works (Debian/Ubuntu and Gentoo are actually very similar on the low level).
                    This is something that I never had imagined by myself.

                    Originally posted by frign View Post
                    On the technical side, having a fast computer, of course, makes it hard to see which system's faster. My current computer is a quad-core i7 one, so I shouldn't see any difference, too.
                    For testing purposes, I set up Gentoo on a smaller system (fit-PC2 by CompuLab) and compared it to a fresh installation of Debian (Xfce). Especially using the Desktop Environment, you could notice some differences.
                    Humans are actually quite sensitive when it comes to little time-delays.
                    Debian ran just fine and I don't have any reason to complain. But using Gentoo on the other hand, it was noticeably faster. That was my personal experience and I might just fall for the placebo-effect, but everyone's free to do benchmarks.

                    If you search for benchmarks on the net, you normally find ones comparing different optimization-levels (which is BS). Honestly, no one really did a comparison between Gentoo and Debian for example (Correct me if I'm wrong).
                    I don't know any modern comparison with a binary distro. Some forums posters in the internet report about a 10% speed advantage, but fail to give any detail of what exactly compared and how. I have also seen the -Os/O2/O3 comparisons, but nothing about USE-flags

                    Comment


                    • Benchmarks are needed

                      Originally posted by juanrga View Post
                      I don't know any modern comparison with a binary distro. Some forums posters in the internet report about a 10% speed advantage, but fail to give any detail of what exactly compared and how. I have also seen the -Os/O2/O3 comparisons, but nothing about USE-flags
                      I'm sure we need some real benchmarks to actually have a basis for argumentation.
                      I don't think there is an _overall_ 10% speed advantage, but there's definitely even more in some areas.

                      Comment


                      • Originally posted by juanrga View Post
                        I don't know any modern comparison with a binary distro. Some forums posters in the internet report about a 10% speed advantage, but fail to give any detail of what exactly compared and how. I have also seen the -Os/O2/O3 comparisons, but nothing about USE-flags
                        The thing about comparing use-flags is that, first, there are too many variants, and second, it, by definition, means there is no feature parity when doing the comparison. Benchmarks are only extrapolated when there is feature parity. The point in use-flags is not loading things you don't use, and this is inherently a custom setting for a custom user, and thus not extrapolated. The closest you can get to actually make a valid comparison is stating you will always compare minimal features for a given package with default in another distro, with the same optimization flags (so to compare only the overhead introduced by features).

                        Comment


                        • Good idea!

                          Originally posted by mrugiero View Post
                          The thing about comparing use-flags is that, first, there are too many variants, and second, it, by definition, means there is no feature parity when doing the comparison. Benchmarks are only extrapolated when there is feature parity. The point in use-flags is not loading things you don't use, and this is inherently a custom setting for a custom user, and thus not extrapolated. The closest you can get to actually make a valid comparison is stating you will always compare minimal features for a given package with default in another distro, with the same optimization flags (so to compare only the overhead introduced by features).
                          Yes, I think you have to go this way.
                          Going minimal may be the best choice.

                          Comment


                          • Originally posted by frign View Post
                            I'm sure we need some real benchmarks to actually have a basis for argumentation.
                            I don't think there is an _overall_ 10% speed advantage, but there's definitely even more in some areas.
                            I agree benchmarks are needed. I would confess that less than a 10% disappoints me.

                            Originally posted by mrugiero View Post
                            The thing about comparing use-flags is that, first, there are too many variants, and second, it, by definition, means there is no feature parity when doing the comparison. Benchmarks are only extrapolated when there is feature parity. The point in use-flags is not loading things you don't use, and this is inherently a custom setting for a custom user, and thus not extrapolated. The closest you can get to actually make a valid comparison is stating you will always compare minimal features for a given package with default in another distro, with the same optimization flags (so to compare only the overhead introduced by features).
                            Many benchmarks/reviews there out are not extrapolated to user specific hardware/software: different chipset, memory, disks, gpus, drivers, kernel, libs, and apps version can make differences in scores. However benchmarks/reviews are useful to get an idea.

                            If it is possible to benchmarks three different kernels, or ten different OSs, or six different CPUs, why couldn't be benchmarked five different use-flags in the same system, just to see what happens? They would be useful to get an idea.

                            Comment


                            • Originally posted by juanrga View Post
                              Many benchmarks/reviews there out are not extrapolated to user specific hardware/software: different chipset, memory, disks, gpus, drivers, kernel, libs, and apps version can make differences in scores. However benchmarks/reviews are useful to get an idea.

                              If it is possible to benchmarks three different kernels, or ten different OSs, or six different CPUs, why couldn't be benchmarked five different use-flags in the same system, just to see what happens? They would be useful to get an idea.
                              The point was that you have no way to tell what brought the improvement, or if any user will use that use-flags at all. You could do for many combinations, but that would make it harder to read and would take a lot more time. You can get the idea with the method I proposed, anyway.

                              Comment

                              Working...
                              X