Announcement

Collapse
No announcement yet.

Rust 1.12 Programming Language Released

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

  • Rust 1.12 Programming Language Released

    Phoronix: Rust 1.12 Programming Language Released

    Rust 1.12 has been released as the newest version of this popular programming language with a focus on "fast, reliable, productive: pick three."..

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Michael I was going to mention you on twitter about this new release, but you were faster

    Comment


    • #3
      Nice release but when will we have non-lexical lifetimes/borrows in Rust?

      Comment


      • #4
        Incredible how inventive this language is. AFAIK some of it's features now get ported over to c++, like how the iterators are implemented (details in the link below). I really hope rust gets used more in critical code paths in the future and/or more of it's features find their way into future c(++) standards.
        Over the past couple of years on and off, I’ve been experimenting with pushing the limits of software font rendering performance. The…

        Comment


        • #5
          I'm really really wanting to move over to Rust. But the borrowing system makes parallel computation extremely tedious (at least for what I do).

          You can see a very poor example of using threads in The Rust Book:


          The example is under section Safe Shared Mutable State. The example aims to show you how to use threads to process 3 items. You should be able to process those 3 items in parallel with no problem in any other language that supports threads. Their example solution, however, ends up not benefiting from using threads at all because they introduce a lock on the entire array to make the borrow checker happy! Now only one thread can access that array at a time and the other 2 threads have to wait for the first to finish. Then the second thread runs and the last remaining thread has to wait. And then finally the last thread runs. Essentially, you'd be better off not using threads at all. It would be slightly faster without threads.

          Processing/accessing/assigning disjoint sets of elements of arrays with threads is a pretty common task in numerical algorithms. Rust's borrowing system makes this very difficult to do efficiently presently. It's so bad that people had to craft special libraries that chop an array up so that the borrow system will let threads own each chunk for processing to achieve true parallelism. But this is not sufficiently flexible. You may need dynamic chunks since not all elements are processed in the same amount of time.

          Here's a stackexchange asking how to do something very basic with threads:
          I have a massive vector that I want to be able to load/act on in parallel, e.g. load first hundred thousand indices in one thread, next in another and so on. As this is going to be a very hot part ...


          If they can make the borrowing system aware of safe parallel programming paradigms, I'm definitely going to start using Rust for my projects.

          Comment


          • #6
            Originally posted by nslay View Post
            I'm really (...) for my projects.
            I'm curious now - if I have 2 datasets (like 2 vectors) - can I process them in a true parallel way in Rust like for example pthreads do? (I haven't learned Rust yet)

            Comment


            • #7
              Originally posted by nslay View Post
              If they can make the borrowing system aware of safe parallel programming paradigms, I'm definitely going to start using Rust for my projects.
              Have you taken a look at rusts futures implementation: https://github.com/alexcrichton/futures-rs

              There you have a thread pool thats equal to the number of threads you cpu supports and then give them work via futures.

              Comment


              • #8
                popular programming language

                Is this a joke? I never ever heard about rust being used in some good applications, web or desktop. Everyone now uses C# or C++14 which is dying slowly too. For web everyone uses PHP, some maniacs still use python or ruby. What's rust?

                Comment


                • #9
                  Ezio21 people still start projects using PHP? I don't know anyone that does.
                  Node.js & Go seem to be popular now, and C# might also get popular with .NET Core.
                  Java is also being used in some new projects, it seems. But PHP? really?

                  Comment


                  • #10
                    Originally posted by nslay View Post
                    I'm really really wanting to move over to Rust. But the borrowing system makes parallel computation extremely tedious (at least for what I do).

                    You can see a very poor example of using threads in The Rust Book:


                    The example is under section Safe Shared Mutable State. The example aims to show you how to use threads to process 3 items. You should be able to process those 3 items in parallel with no problem in any other language that supports threads. Their example solution, however, ends up not benefiting from using threads at all because they introduce a lock on the entire array to make the borrow checker happy! Now only one thread can access that array at a time and the other 2 threads have to wait for the first to finish. Then the second thread runs and the last remaining thread has to wait. And then finally the last thread runs. Essentially, you'd be better off not using threads at all. It would be slightly faster without threads.

                    Processing/accessing/assigning disjoint sets of elements of arrays with threads is a pretty common task in numerical algorithms. Rust's borrowing system makes this very difficult to do efficiently presently. It's so bad that people had to craft special libraries that chop an array up so that the borrow system will let threads own each chunk for processing to achieve true parallelism. But this is not sufficiently flexible. You may need dynamic chunks since not all elements are processed in the same amount of time.

                    Here's a stackexchange asking how to do something very basic with threads:
                    I have a massive vector that I want to be able to load/act on in parallel, e.g. load first hundred thousand indices in one thread, next in another and so on. As this is going to be a very hot part ...


                    If they can make the borrowing system aware of safe parallel programming paradigms, I'm definitely going to start using Rust for my projects.
                    I'm the author of the Parallel implementation in Rust. The borrowing system was designed exclusively for safe parallel programming practices, and it just happened to also be useful everywhere else in single-threaded applications. The book has great examples of what not to do and how to do it properly. There are also many crates available to provide higher level features and convenience, such as rayon, which provides parallel work-stealing iterators that will only execute in parallel when it improves performance, which you are looking for.

                    The Safe Shared Mutable State example is perfect as it is. A vector in any language, like an array, does not point to data, but pointers to memory addresses. With a mutable vector, if you were to grow the size of the vector, the vector would be allocated into a new region of memory. If you did not lock a vector within a Mutex, the other threads would continue attempting to access invalid memory addresses, not knowing that the addresses have changed. You are asking for Rust to enable support for incredibly unsafe parallel programming practices.

                    Comment

                    Working...
                    X