Announcement

Collapse
No announcement yet.

Firefox 68 Integrates BigInt Support

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

  • #21
    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.
    Only a small part of Firefox is written in Rust. They wouldn't exchanged parts of it, if it wouldn't gain on performance. You should do your recherche, before you post...

    Comment


    • #22
      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.

      Chrome uses systemd-inhibit and prevents the Xfce power manager to work. Chrome supports the Alsa audio and Debian Firefox supports too. The perfect browser is yet to see.
      Why doesn't the Xfce team create a browser?
      Last edited by Vistaus; 05-26-2019, 02:07 PM.

      Comment


      • #23
        Originally posted by Vistaus View Post

        Why doesn'n the Xfce team create a browser?
        I thought that I'd maybe get one day without an IBM conspiracy theory. Damn you Vistaus

        Comment


        • #24
          Originally posted by debianxfce View Post
          Mozilla do not care about users,
          ^ Truth. Mozilla: the choice of the hipster generation. I'll never use that trash again. Andreessen must be cringing at how far his creation has fallen.

          Comment


          • #25
            Originally posted by torsionbar28 View Post
            ^ Truth. Mozilla: the choice of the hipster generation. I'll never use that trash again. Andreessen must be cringing at how far his creation has fallen.
            I'm sure you arrived at this conclusion after frustrating first-hand experiences. It's easy to get bitten by some change in software as complex as a browser, and to conclude that if upstream did that, it doesn't care about its users. But firstly, all changes are compromises, and what bothers you may improve the general userbase's experience.

            But what really strikes me about your comment is the idea that Mozilla makes less user-focused decisions than Google, Microsoft, or Apple (to cite the biggest browser vendors), which is pretty much indefensible. Mozilla has a decades-long record of fighting for the user's and the Internet's freedom, privacy. The other three are pretty much the opposite. If you want to influence a browser with bug reports and code contributions, Firefox is the only reasonable option.

            You may not like today's Firefox, but it's the only mainstream browser that ultimately cares about the web and its users rather than a corporate agenda. And we sorely need it to counter the Blink monoculture.

            Comment


            • #26
              Originally posted by Steffo View Post
              Only a small part of Firefox is written in Rust. They wouldn't exchanged parts of it, if it wouldn't gain on performance. You should do your recherche, before you post...
              Argued about that here so many times before, it falls on death ears, some people just took a dislike to rust and can't process some basic observations:
              • Rust is just as fast as C/C++ at the language level. The differences are minimal, there are benchmark wins on both sides, usually not much bigger than background noise.
              • Rust makes complicated code much easyer. Firefox tried and failed multiple times to parallelize their render and css using C++, but succeeded with Rust. Often, naive/idiomatic rust code will be much closer to theoretical max performance than naive/idiomatic C++ code.
              • Firefox is still overall slower than Chrome mainly due to javascript performance, which is still written in C++. Page layout and css parsing, which Firefox has rewritten in Rust, are faster in Firefox.

              Comment


              • #27
                Originally posted by Vistaus View Post

                Why doesn't the Xfce team create a browser?
                Actually they did, Midori is under the Xfce4 umbrella...

                https://goodies.xfce.org/projects/applications/midori

                Comment


                • #28
                  Originally posted by Danielsan View Post

                  Actually they did, Midori is under the Xfce4 umbrella...

                  https://goodies.xfce.org/projects/applications/midori
                  Yeah, and Eolie is a web browser by the GNOME Team just because it's hosted on their GitLab...

                  Comment


                  • #29
                    Originally posted by Vistaus View Post

                    Yeah, and Eolie is a web browser by the GNOME Team just because it's hosted on their GitLab...
                    Actually it seems exactly as you stated...

                    Comment


                    • #30
                      Originally posted by dremon_nl View Post
                      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.
                      I think the difference between C++ pointers and Rust pointers is smaller than this. C++ has (sort-of) two pointer types as well: T* and shared_ptr<T>.
                      • T* (or T&) can be used in single-threaded scenarios as long as the top-level function caller refers to the object via a single shared_ptr<T> to prevent its deallocation and as long as the object does not escape to the heap or elsewhere. If it escapes to heap or to upper scope or to another thread (that is: the object outlives the scope in which is has been created), it needs to be encapsulated in a shared_ptr<T>.
                      • shared_ptr<T> is suitable in multi-threaded scenarios for passing objects between threads
                      Maybe C++ should divide shared_ptr<T> into two types:
                      • shared_ptr_st: for use in single-threaded code
                      • shared_ptr_mt: for use in multi-threaded code
                      • shared_ptr_mt cannot be directly assigned nor converted to-or-from shared_ptr_st, which should help the programmer to reason about concurrency
                      • The C++ compiler is unable to enforce the rule that everything reachable through a shared_ptr_mt must be shared_ptr_mt as well (struct fields), so it is up to the programmer to ensure this rule holds

                      Comment

                      Working...
                      X