Announcement

Collapse
No announcement yet.

Firefox 68 Integrates BigInt Support

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

  • #11
    Originally posted by debianxfce View Post

    C/C++ beats rust in real world applications.
    https://benchmarksgame-team.pages.de...-are-fast.html
    What's that: the link that you provided exactly falsifies your claims - it not only shows that Rust is faster than C++, but also that Rust's results are more consistent than both C and C++.

    Can you now provide a link that supports your claims?
    Last edited by pkese; 05-26-2019, 06:55 AM.

    Comment


    • #12
      Originally posted by debianxfce View Post
      Firefox runs slower than Chrome/Chromium.
      https://www.phoronix.com/scan.php?pa...-73-Benchmarks
      Rust and other bad choices slows down.
      What makes you think that Rust is the problem?

      I'm not a Rust programmer, I used to program C++ but I can see many cases where it is easier to extract some extra performance out of Rust than C++. For example the OOP approach in C++ includes virtual methods which include a small performance penalty due to need of dereferencing each time such methods are called. Similarly Rust makes it easier to avoid some memory allocations. Then there are cases where one'd normally use ARC pointers in C++ (with extra cost of managing reference count at each use) in cases where one could rely on Rust's borrow checker to safely program many of these pointer usages without reference counting altogether.

      To me it appears that Rust really enables better ratio of level of abstratcions divided by cost of abstractions than C++.
      But I might be wrong... as I said I don't know Rust as well as C++...

      What's your experience with Rust?
      Last edited by pkese; 05-26-2019, 07:17 AM.

      Comment


      • #13
        BigInt should've never been in the language, and I think it's the cat -v of EVCMA-262. It breaks semantics like having the binary + operator not throw exceptions for arbitrary types, which doesn't hold for the case where arguments are of type Number and BigInt. Not to mention, a single numeric type (Int32 used for Array indices and as the intermediate type used in bitwise binary operations doesn't really count, and it fits into Number nicely) was one of the best things about the language since the very beginning.

        I think Bigint should be implemented via libraries, as it serves little purpose, breaks the language and takes away the best thing about it. BigInts will have niche use, and wasting time to implement that functionality for little benefit is a waste. I'd rather have people spend time to figure out more pressing issues like the pipe operator, standardizing dynamic imports, tail calls and as patters (lack of which is pretty annoying).

        But of course, Ecma is wasting time with things like classes (which are sugar for a subset of how Objects can be handled, taking away the power of prototype-based inheritance) and broken variable declarations (const should've enforced immutability of values declared with it, Object.seal() got into the language along with it).

        In general, I'm not too happy with the way this language is heading, rather than embracing FP as the only decent paradigm, and focusing on what's good in the language and expanding upon it, Ecma is focusing on making Java refugees comfortable so they can continue writing crappy code.

        Oh, and they could add some super-strict mode that outright throws on bad code that uses features such as var declarations to enforce writing code to modern standards.

        Comment


        • #14
          Originally posted by andyprough View Post
          I turned on webrender on Firefox Nightly 69.0a1 tonight. Playing videos caused the CPU usage to basically double. I couldn't see any discernible difference in playback, so I turned it back off.
          Yeah I'd much rather love to see hw accelerated video decode and display support since I watch youtube for hours every day.

          Comment


          • #15
            Originally posted by debianxfce View Post
            Rust and other bad choices slows down.
            Nonsense. Rust compiles into native code via LLVM backend, has no runtime GC and zero-cost abstractions, why would it yield a slow code? C++, on the other hand, requires an extreme care to produce an equally performant (and. more importantly, reliable) code, because it has copy semantics by default (e.g. string or vector assignment is a copy operation), abstraction penalty, overuse of shared_ptrs, etc.
            You can certainly use only a subset of C++ (like C) working with raw pointers and manual memory allocation but so can you do it with Rust albeit is way more safer way.

            Comment


            • #16
              Originally posted by dremon_nl View Post
              overuse of shared_ptrs [in C++]
              Is there an alternative to shared_ptr in C++ with a better performance and the same safety guarantees?

              Comment


              • #17
                Originally posted by phoronix View Post
                Phoronix: Firefox 68 Integrates BigInt Support

                In addition to Firefox 68's WebRender slated to deliver much better performance, another headlining feature of this next Mozilla Firefox web-browser update is BigInt support...

                http://www.phoronix.com/scan.php?pag...BigInt-Support
                Originally posted by RealNC View Post
                Eh, no. More like 2^53.
                Originally posted by cb88 View Post

                Larger than 2^53.. JS can already handle numbers up to 2^53.

                https://developer.mozilla.org/en-US/...Objects/BigInt
                Indeed. The article should be corrected. Instead of:

                BigInts are a new JavaScript primitive for integers that are suffixed with an n and can handle values up to 253 in value.
                it should be:

                ... and can handle values larger than 253.
                Also, although the article HTML source code uses 2<sup>53</sup>, it is being displayed as 253 in Chrome and Firefox.

                Comment


                • #18
                  My dyslexic ass read that as "Blight Support" and my first though was "those fucking cliff racers".

                  I didn't realize there would be math involved.

                  Comment


                  • #19
                    Originally posted by atomsymbol View Post

                    Is there an alternative to shared_ptr in C++ with a better performance and the same safety guarantees?
                    Not in a standard library, but I am pretty sure there are 3rd-party solutions with better performance. There is also unique_ptr for move semantics but I wouldn't use it as it's quite easy to produce undefined behavior with it. Rust, on the other hand, has two reference-counted types: Rc for single-threaded use and Arc for multithreading, ARc being naturally slower due to atomicity. That's the inherent difference between the classical languages which were not designed for concurrent and asynchronous programming and the language which was built for that from ground up.

                    Comment


                    • #20
                      Well, there's certainly nothing horribly wrong in choosing Rust. It basically does a lot of stuff I already strive to do very hard in C++, by default. As for the zero cost abstractions, rustc is able to optimize out ton of stuff, as almost any C++ compiler. No performance issues worth talking about, at least for large majority of work to be done.

                      As for the shared_ptr, if shared semantics is what you strive for, there's little what can be done, that is better. Arc is similar to sharedptr as I see it, perhaps with better multithreaded safety (Rust is not my forte, so I may be off).

                      Now, if you do really low level system performance development, then C++ may provide slightly more flexibility at the cost of loss of hand holding, and you also need a seasoned veteran to do it, which is harder to find and pay for.

                      Comment

                      Working...
                      X