Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Mozilla

Brave Browser Claims 69x Better Performance For Its Ad-Blocker After Switching From C++ To Rust (zdnet.com) 337

The Brave web browser "claims to have delivered a '69x average improvement' in its ad-blocking technology using Rust in place of C++" reports ZDNet.

They cite a blog post by Brave performance researcher Dr. Andrius Aucinas and Brave's chief scientist Dr. Ben Livshits: The improvements can be experienced in its experimental developer and nightly channel releases... "We implemented the new engine in Rust as a memory-safe, performant language compilable down to native code and suitable to run within the native browser core as well as being packaged in a standalone Node.js module," the two Brave scientists said. The new engine means the Chromium-based browser can cut the average request classification time down to 5.6 microseconds, a unit of time that's equal to a millionth of one second.

Aucinas and Livshits argue that the micro-improvements in browser performance might not seem significant to end users but do translate to good things for a computer's main processor. "Although most users are unlikely to notice much of a difference in cutting the ad-blocker overheads, the 69x reduction in overheads means the device CPU has so much more time to perform other functions," the pair explain.

Their blog post notes that loading a web page today can be incredibly complex. "Since loading an average website involves 75 requests that need to be checked against tens of thousands of rules, it must also be efficient."
This discussion has been archived. No new comments can be posted.

Brave Browser Claims 69x Better Performance For Its Ad-Blocker After Switching From C++ To Rust

Comments Filter:
  • Today I learned (Score:4, Insightful)

    by Anonymous Coward on Sunday June 30, 2019 @10:58PM (#58852912)

    ...that 5.6 microseconds is one millionth of one second. Who knew ?!

    • uh, basic English comprehension fail, dude, it says a microsecond is a *unit* of time equal to one millionth of a second.

      5.6 microseconds isn't a '**unit** of time'. Unit = 1. It's not ambiguous.

      • by Vreejack ( 68778 ) on Monday July 01, 2019 @07:24AM (#58854120)

        No, it's ambiguous and badly written. Many people will perceive "5.6 microseconds" as the subject of the following clause. I just showed this to two other people who also misread it. It's natural to perceive "equal to one microsecond" as written to be referring to "5.6 microseconds", which is utterly jarring.

        It may be that people accustomed to thinking of measurements (scientists? engineers?) do not readily separate the units from the quantity but automatically think of "x units" as a single idea and not a pair of separable, parseable words.

  • by iggymanz ( 596061 ) on Sunday June 30, 2019 @11:02PM (#58852928)

    That only means the C++ code was bloated crap, there is nothing magic about Rust for speed improvement. A well written program in either language will be about as fast

    • by Anonymous Coward on Monday July 01, 2019 @12:55AM (#58853208)

      No necessarily bloated but certainly extremely poorly and inefficiently written. I don't care what the languages are, that sort of comparison reflects on the programmers, not the languages.

    • by Tough Love ( 215404 ) on Monday July 01, 2019 @01:03AM (#58853220)

      That only means the C++ code was bloated crap, there is nothing magic about Rust for speed improvement. A well written program in either language will be about as fast

      Maybe it's easier to write a well written program in Rust than C++.

      • More likely it is easier to write efficient code second time around, after you've patched the first version for all the edge conditions and special cases and actually understand what the design needs to deal with now
      • by serviscope_minor ( 664417 ) on Monday July 01, 2019 @08:25AM (#58854386) Journal

        Seems unlikely, Rust doesn't have substantially different expressiveness from C++.

        The point of Rust was to be able to write native code with fine grained multithreading, which is extremely hard to get right in C++ because it's hard to get right in general and C++ provides no tools to help. The most that will give is an improvement promotional top the number of cores.

        Due to the borrow checking, I could believe that the rust compiler can make additional deductions about aliasing that the C++ compiler cannot (though the compiler is less mature). If you're very very lucky you could get a factor of 4 speedup, e.g. if the compiler can then ruin three auto vectorizerand the stars align.

    • by AmiMoJo ( 196126 ) on Monday July 01, 2019 @03:33AM (#58853494) Homepage Journal

      TFA is complete bollocks. If you look at the actual blog post from Brave it's clear that the performance boost is from changing from the an Adblock Plus algo to a more efficient uBlock Origin / Ghostery algo: https://brave.com/improved-ad-... [brave.com]

      The move to Rust was entirely incidental. They just happened to implement the new filter system in Rust instead of C++, that's all. The performance boost is from the new algorithm.

      • "The new algorithm with optimised set of rules is 69x faster on average than the current engine.

        For the popular filter list combination of EasyList and EasyPrivacy it achieves class-leading performance of spending only 5.7μs on average per request."

        Is it time to start tagging dashslot summaries as clickbait? Or do they want the added page loads from people replying to label it clickbait?

    • by Tom ( 822 )

      Actually, there is: Memory management.

      While C++ at least doesn't have GC (which shoots Java in the foot, then the knee and then the groin), it has such troublesome memory management that any question about that topic on stackoverflow gains numerous longwinded answers.

      Rust doesn't have that problem and thus doesn't force you to jump through hoops to manage your memory, and unless you're experienced in doing so, almost certainly shooting your performance to hell.

    • It could even be something as simple as memory usage - whereas their C++ code could have been doing the exact same algorithms as rust does, the "memory safe" Rust may suddenly not be deallocating memory until after the benchmark has been run, meaning it goes faster just long enough to measure, the users will notice no difference as that cost not measures by the benchmark is only seen by them.

    • Exactly. Thank you for saving me the time to explain that.

    • by DrXym ( 126579 )
      Yes and no. Perhaps it was bloated crap, probably running on a single thread, probably with horrible rule matching. But to rewrite it so it ran safely over multiple threads in C++ would have taken more effort than rewriting it in Rust and would have resulted in more runtime bugs.
  • No party.

  • by Anonymous Coward on Sunday June 30, 2019 @11:02PM (#58852932)

    "Brave browser realises they suck at C++"

  • by Tony Isaac ( 1301187 ) on Sunday June 30, 2019 @11:35PM (#58853016) Homepage

    You can write slow code in any language, and you can write fast code in most languages. The difference is almost entirely based on how much effort you put into optimizing your code.

    I recently optimized a spreadsheet matching algorithm that initially took 37 seconds to run. After optimizing, the same functionality took only 0.3 seconds. Same algorithm, same inputs, same outputs. Just attention to performance tuning.

    Slow code is almost always slow because nobody made it fast. Because C++ generally compiles to processor-specific op codes rather than bytecode, it should be one of the fastest languages around. If it isn't, somebody has some work to do to tune their application.

    • by DrXym ( 126579 )
      It's not just about being fast but being safe. If you're throwing the web at your code then safety is more important than raw speed. That tends to result in conservative designs which are refined over time and then left the hell alone. And the reason for this is simple - writing or rewriting to become multi threaded is hard, and doubly hard in languages in C/C++ which don't care if you protect your data or if the thing you created on one thread is still alive when the other thread calls it.

      Rust is (correc

      • I mostly agree with you about safety. But safety, in general, requires computing time, and thus slows down your code. As with any other optimization, safety itself can be optimized. Perhaps Rust does this, but I doubt it does it better than other well-maintained languages.

        You can write safe code in C++. Yes, it takes extra effort, and it does slow down your code a bit. The difference is that other languages build in this safety, even for processes that don't really need it.

        All that said, for code that is wr

        • by DrXym ( 126579 )
          Much of the safety in Rust is at compile time and compiles away to zero runtime cost. e.g. if you have a reference to some object and it goes out of scope then C++ won't care and let you call that dangling reference but Rust will generate a compiler error because it knows your code is in error. Once it passes the check the compiled code is largely analogous to correctly code in C or C++ with similar performance.

          The main runtime expense is if you get elements out of an array / vector by index. But usually

  • by Bruce Perens ( 3872 ) <bruce@perens.com> on Sunday June 30, 2019 @11:46PM (#58853034) Homepage Journal
    You'd have to try hard to get something that ran 69x faster than C in Rust. C is pretty close to the machine. If you want to brag about Rust, better to brag about the features it has which hadn't been thought of when C was invented.
    • by Tailhook ( 98486 )

      You'd have to try hard to get something that ran 69x faster than C in Rust.

      Wouldn't the effort depend on how badly the something in question had been implemented in C?

    • by keltor ( 99721 ) * on Monday July 01, 2019 @12:38AM (#58853158)
      In this case, it's not a C++ vs Rust performance comparison at all, but a new algorithm they implemented: https://brave.com/improved-ad-... [brave.com]
    • Yeah. Even Java wouldn't go that much slower.
    • by Tailhook ( 98486 )

      The actual code is here [github.com], complete with a rather nice diagram of the design. It looks like it took Dr. Andrius Aucinas a little less than four months to write it.

      It really is down to the algorithm they implemented. There doesn't appear to be any aggressive use of concurrency in the rust-adblock module itself. The code is intended to be thread safe; the host (browser/nodejs/whatever) can have multiple concurrent threads in adblock API. There is no unsafe code, so the new work introduces no new memory vi

  • RTFA (Score:5, Informative)

    by definitely ( 1404515 ) on Sunday June 30, 2019 @11:49PM (#58853042)
    They changed to a different ALGORITHM for pattern matching; the language used is an implementation detail.
  • Brave Browser development team apparently has no competent C++ coders.

  • by Oddhack ( 18073 ) on Monday July 01, 2019 @12:18AM (#58853102) Homepage

    The performance increase is due to algorithmic changes, not to Rust vs. C++. This is clear in the actual blog post, which mostly discusses the new filtering / tokenization algorithm. I suspect the Slashdot article is based on a superficial reading of the misleading ZDnet article about the blog post, not about what the Brave folks actually posted.

  • 5.6 millionths? Not one millionth?

  • Thank you! I finally know that a microsecond was the equivalent of a millionth of a second... Just the kind of information I expect from "News for Nerds". Now excuse me while I peruse some of your excellent "From the Web" links (rolls eyes).

  • If that provided a 69x improvement all you can take away from that is that they were SHIT C++ programmers, however like usual it looks like the Slashdot summary is just sensational BS. perhaps it is time we start voting with our clicks and go elsewhere if the editors aren't willing to at least do the basics to ensure what is submitted isn't clickbait garbage
  • by gweihir ( 88907 ) on Monday July 01, 2019 @03:27AM (#58853476)

    They may have had that improvement, but the language switch will not be the reason. They will have done a re-engineering at the same time and would probably have had the same improvement or better if they had re-engineered for a C++ target.

  • Because such a speed improvement has nothing to do with the two languages. The claim is fundamentally dishonest as it implies something that is just not true. Another reason to stay away from Rust, I want nothing to do with a community that makes such claims.

  • All it means is that the new design was better implemented than the old design.. The performance doesn't have anything to do with going from C++ to Rust... Hell, the performance might even be better when the new engines was fully implemented in C++ than Rust...
  • I like alternative web browsers. I like ad blockers. I like good, fast software. But I'm not going to look any closer at this because they used that stupid word "performant".
    • >"I like alternative web browsers. "

      Except that Brave is not really an "alternative" web browser because it is based on Chromium. So it is still beholden to Google and looks like Chrome/Chromium to web sites, continuing to promote Google's control over the web.

  • You write and refine a chunk of v1.0 code to do a thing. You optimize and fix it further and further over a decent chunk of time. You decide to do a 2.0 rewrite (in any similarly capable language) and it's massively faster...and that's a SHOCK? No! A clean implementation after thousands of issue fixes and tweaks makes it possible to implement all the fundamental code architecture changes you fantasized about during maintenance! It has nothing to do with Rust and everything to do with tons of problem-specifi
  • They switched algorithms and languages. The vast improvement is almost certainly due to the former and not the latter.

    If they had just reimplemented the same algorithm in Rust and saw that improvement, then this headline could be worthy (but need an explanation of why). As it is, it's utterly bogus.

  • Sorry, but it feels like (and seems like) yet another example of a click-bite article on /.
    "... After Switching From C++ To Rust ...", yet there's nowhere in the article claiming this, what the linked article says is that they used better algorithms and different approach than Google for ad-blockers, and: "BTW", we used RUST, because it's memory safe and we like it more"

    The linked article itself quality is questionable:
    "... can cut the average request classification time down to 5.6 microseconds, ..." t

  • In almost all but the most rare of cases you only see this sort of improvement when moving from an interpreted to a compiled language, or when implementing a better algorithm. There is no possible way that Rust is generating code that is 69x faster than C++ when the algorithm has not been changed.

No man is an island if he's on at least one mailing list.

Working...