Announcement

Collapse
No announcement yet.

How A KDE Developer Used C++17 & Boost.Python For About A 8,000x Speed-Up

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

  • How A KDE Developer Used C++17 & Boost.Python For About A 8,000x Speed-Up

    Phoronix: How A KDE Developer Used C++17 & Boost.Python For About A 8,000x Speed-Up

    Open-source developer Antonio Larrosa who contributes to KDE and openSUSE has been developing a command-line music manager called Bard. He's written an interesting post about how he sped up some of his operations by around eight-thousand times faster...

    http://www.phoronix.com/scan.php?pag...CXX-Boost-Perf

  • #2
    After "optimizations" like this, my immediate response is that it's amazing how BAD it was before.

    Comment


    • #3
      I never have this problem. Mostly because I start every project in C or C++.

      Not even for performance to be honest, mostly to reduce dependencies and the typical PIP environment versioning bullshite that my users would have to go through if I use anything else

      "I just want to run the darn software, I don't want to become a PIP / NPM / CPAN mirror" is what I always find myself thinking if a software package is not C or C++.

      Did C++17 and Boost.Python have to be used? Or is it because of lazyness that a small / trivial custom binding was not written?

      Comment


      • #4
        Yet another example how C++ with STL and OpenMP (and threading in general) is superior to anything else.

        Now waiting for Rust zealots to hijack the thread.

        Comment


        • #5
          Originally posted by anarki2 View Post
          After "optimizations" like this, my immediate response is that it's amazing how BAD it was before.
          my thought exactly

          if it was me i would hide under the table and hope no one ever notices the speedup

          Comment


          • #6
            Originally posted by cen1 View Post
            Yet another example how C++ with STL and OpenMP (and threading in general) is superior to anything else.
            Python is a glorified scripting language designed to let people write code easily... interpreted, and also single-thread by design.

            Now waiting for Rust zealots to hijack the thread.
            He would get similar improvements with rust too. The issue here is Python, not some magical quality of C++.

            Any compiled language with multi-threading support will blow away Python and friends.
            Last edited by starshipeleven; 07-11-2018, 09:05 AM.

            Comment


            • #7
              • It is possible to get 2x speedup on AMD64 by using 64-bit long instead of the 32-bit int
              • I don't know the range of the integer values in the fingerprint

              Comment


              • #8
                I did some work on improving the AlbumThing XMMS2 client, which is written in Python. Apart from porting it to Python 3 and GTK+ 3, I found out why it was so dog slow at loading the cover art. Although it was doing it asynchronously, Python sucks at threading so much that it still locked up the entire UI for at least 10 seconds on startup. I didn't break out any C++ but was able to use the multiprocessing module to load the cover art in an entirely separate process. There's still a couple of rare glitches to sort out and I need to cache the images locally when the server is remote but compared to before, it's a joy to use.

                Comment


                • #9
                  Originally posted by cen1 View Post
                  Yet another example how C++ with STL and OpenMP (and threading in general) is superior to anything else.

                  Now waiting for Rust zealots to hijack the thread.
                  C++ is faster than Python, so Rust is worse than C++. Brilliant logic. 👌
                  You're the one mentioning Rust. The performance improvement that was observed is because of the swap from a slow interpreted bytecode language to a fast compiled language with threading support. Which is... expected. You're not supposed to use those scripting languages when dealing with logic that has to be this quick.

                  Originally posted by atomsymbol
                  • It is possible to get 2x speedup on AMD64 by using 64-bit long instead of the 32-bit int
                  Eeh. I'm not that sure. I wouldn't be surprised if his code could be vectorized by the compiler, in which case this wouldn't really matter.

                  Comment


                  • #10
                    Originally posted by atomsymbol View Post
                    • It is possible to get 2x speedup on AMD64 by using 64-bit long instead of the 32-bit int
                    Which is why you should use std::int_fast32_t, which will pick correctly for your platform.

                    Comment

                    Working...
                    X