Announcement

Collapse
No announcement yet.

Busd Taking Shape As A D-Bus Broker Written In Rust

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

  • #21
    Originally posted by archkde View Post
    how do "terrible CPU usage" and "just as fast" go together?
    Sometimes you do sacrifice CPU at the alter of going faster. On such case is using polling instead of interrupts for higher throughput on IO. Another is to let multiple threads do work that might overlap a little bit (say query a cache and query a db at the same time, throwing the slower one away). Maybe mipmap'ing an image into different LOD levels even though you only need one immediately so that you can switch while zooming. So across disciplines there are cases.

    The case where I think there is work still to be done here is in thread/pool/task/async type things. How you go from 0 workers to 1 worker (extremely common) can often be wasteful. (Do you wake up all threads saying I have a job for you? Do you round robin a fixed pool? Do you work steal? Do you create n_cpu threads at startup? Do you create a heartbeat thread? etc)

    Anyway, this is why we should be profiling and using that profiler data to have meaningful conversations about software implementation.

    Comment


    • #22
      will try this at some point, if when I swap over nothing breaks, that would be a succsess in my books.

      Comment


      • #23
        Another (third) software doing the same thing with the same speed, but more complicated compilation?

        Comment


        • #24
          Originally posted by bkdwt View Post
          Have you noticed that Rust fans only know how to rewrite pieces of software and rarely create something new?
          No, we didn't. Not many people are capable of noticing things that are not true.

          Comment


          • #25
            Originally posted by zaps166 View Post
            Another (third) software doing the same thing with the same speed, but more complicated compilation?
            true. I hate how hard it is to build busd

            cd code
            git clone https://github.com/dbus2/busd.git
            OR
            wget https://github.com/dbus2/busd/archiv...s/0.3.1.tar.gz
            <extract if needed>
            cd busd
            cargo build --release
            install ...

            Comment


            • #26
              An interesting talk (though hard to watch, stage presence was not his strong suit). It seems like a good option to use Rust for this, since the dbus broker is privileged and talks to unprivileged processes. It thus forms a security barrier.

              I'm a bit surprised by the choice of tokio, since zbus uses async-std instead. I wonder what the reason for tokio here was. I also wonder how the work stealing of tokio will work out for battery usage (my understanding is that work stealing scheduling works well when the system is almost fully loaded or very lightly loaded, but has issues with in between where threads compete for work to do causing un needed churn).
              ​​​
              I look forward to seeing how this evolves.
              ​​

              Comment


              • #27
                Originally posted by Vorpal View Post
                I'm a bit surprised by the choice of tokio, since zbus uses async-std instead. I wonder what the reason for tokio here was.
                ​​
                Probably might have something to do with async-std not having had a release for over two years until recently? I don't do much async rust myself to provide much input to why tokio beyond that though.

                Comment


                • #28
                  Originally posted by bug77 View Post

                  Rust is mostly meant to be a systems programming language. What "new" do you need in that area? What "new" are you expecting in any area, really?

                  On a more serious note, a DBus broker seems like a premier candidate for Rust, memory errors in such a component can open some serious holes in a system.
                  rust with tokio async (that busd uses) is not a systems programming language. change my mind.

                  Comment


                  • #29
                    Originally posted by fitzie View Post

                    rust with tokio async (that busd uses) is not a systems programming language. change my mind.
                    By that analogy C with pthreads is not a system language either. The point is that the assumption that using some sort of runtime system="managed"=slow and inefficient is absolutely not true.

                    Comment


                    • #30
                      Originally posted by zeenix147 View Post

                      Rust is NOT a managed language. I didn't show memory usage because there was no reason to. If you have done any research whatsoever, you'd know that Rust's performance comes pretty close to C (even better than C++).



                      Push back where? Do you see any assembly in the dbus-broker or dbus-daemon code? We snowflakes also write unsafe code where it bring performance benefits and even write C or assembly when needed.
                      Agreed, Rusts performance in getting it's zealots to shout Rust everywhere is simply unmatched

                      Comment

                      Working...
                      X