A Quick Benchmark Of Mozilla Firefox With WebRender Beta vs. Chrome

[ZenoArrow]

Weasel, do you at least accept that Rust makes it easier to design software that makes better use of multicore CPUs? If not, why not?

[name99]

In a real life scenario, the difference is a page loading in 0.1 or 0.2 seconds. Not really something a human being can perceive. It's the same crap as operating systems competing on boot time. Your OS booting in 6 or 7 seconds changes absolutely nothing in your life.

Boy are you reading the wrong web site...

[Weasel]

Weasel, do you at least accept that Rust makes it easier to design software that makes better use of multicore CPUs? If not, why not?

No. Why not? Because that's not an inherent part of the language, it's a CPU thing. Most people are clueless about low level stuff, but that doesn't make something difficult or hard. Low skilled required doesn't mean "easy". Easy means that it's difficult even with proper programming skills (as most real things are).

There's no need to add a language feature to something that should be part of APIs anyway. If you want portability/cross platform just use a portable multi-threading library. Putting it in the language is stupid because then all OSes will have to support it, and OSes can be different. It might shock you, but POSIX is not God, despite what some fanboys think. (yes I *am* aware C added it to the language, doesn't mean I'm for it though)

As for design: you just need to understand how shared resources are accessed at the low level. It's part of the design process, really, nothing to do with language. Designing, e.g. thread-safe APIs has nothing to do with language either.

The thing is, most people can't even fathom releasing resources manually, that's exactly the low skilled trash that almost all language promote. They find it "difficult" because they are UNSKILLED due to using crappy languages that sheltered them from learning proper skills (manual resource management). Manual resource management teaches you to think about it during the design phase as well. You think when resources are acquired and when they are locked so you can design a proper interface.

Note that memory, despite being the most popular from newbies, is just one type of resource and not that special (in fact it's much more trivial than other resources), but garbage collectors spoiled newbies and they'll forever remain newbies because of it.

[ZenoArrow]

No. Why not? Because that's not an inherent part of the language, it's a CPU thing. Most people are clueless about low level stuff, but that doesn't make something difficult or hard. Low skilled required doesn't mean "easy". Easy means that it's difficult even with proper programming skills (as most real things are).

There's no need to add a language feature to something that should be part of APIs anyway. If you want portability/cross platform just use a portable multi-threading library. Putting it in the language is stupid because then all OSes will have to support it, and OSes can be different. It might shock you, but POSIX is not God, despite what some fanboys think. (yes I *am* aware C added it to the language, doesn't mean I'm for it though)

As for design: you just need to understand how shared resources are accessed at the low level. It's part of the design process, really, nothing to do with language. Designing, e.g. thread-safe APIs has nothing to do with language either.

The thing is, most people can't even fathom releasing resources manually, that's exactly the low skilled trash that almost all language promote. They find it "difficult" because they are UNSKILLED due to using crappy languages that sheltered them from learning proper skills (manual resource management). Manual resource management teaches you to think about it during the design phase as well. You think when resources are acquired and when they are locked so you can design a proper interface.

Note that memory, despite being the most popular from newbies, is just one type of resource and not that special (in fact it's much more trivial than other resources), but garbage collectors spoiled newbies and they'll forever remain newbies because of it.

Three points:

1. "Because that's not an inherent part of the language". The way Rust handles memory ownership is a core part of the language. All memory allocations have a single owner, and access by other functions requires either borrowing, cloning or transferring ownership. This design decision can make it easier to reason about the design of applications that span multiple CPU cores, as you have to be explicit about when data can be read and updated, and potential clashes are caught at compile time. Can you do the same with C++? Sure, but the compiler doesn't necessarily assist you in debugging this type of code. You can achieve similar results with static analysis tools though. Note that my argument was only about the "ease" of programming for multiple cores, and it's being able to have the compiler give you additional feedback about your design that makes the difference here.

If you're interested in getting a better sense of Rust's approach to memory management, I can recommend this podcast:

https://corecursive.com/016-moves-and-borrowing-in-rust-with-jim-blandy/

2. Multicore and multithreaded are not quite the same thing. As I'm sure you're already aware, multithreaded applications can run on a single core, and unless you design your code to run on multiple cores it won't necessarily make use of multiple cores (for example, you would have to set the CPU affinity when deciding which core to run a thread on). In general, multicore increases the potential complexity of multithreaded applications (if you want your applications to make fuller use of the available CPU resources).

3. Memory management is not hard. I've programmed in 6502 assembly before, I found it to be one of the easiest languages to get up and running in, though in my opinion its greatest strength is also its greatest weakness (being explicit about everything you do makes it easy to understand, but also tedious to write out). If you think that programmers who are used to higher level languages are somehow corrupted and incapable of learning lower level memory management techniques I'd suggest you're mistaken, for the most part they're just focused on a different set of problems in their day-to-day work.

[jacob]

No, it doesn't. Mozilla devs obviously wrote it in something that would be called incompetent++ rather than C++. I mean, the fact they rewrote it in Rust kind of proves this by itself.

Nobody sane would rewrite real C++ into anything else other than maybe C, especially not something as crap as Rust.

Also this is not a comparison between Firefox and pre-Rust Firefox you know.

IMHO nobody sane would listen to your advice as far as software development goes ;-)

[Grogan]

Say no to the Firefox browser that requires you to use pulseaudio. Chrome works with Alsa. Pulseaudio is buggy and uses a lot of CPU resources. The Poetterisation of GNU/Linux is bad and Firefox do just that.

I can tell you that I did not like the sabotage of them disabling ALSA by default in a minor version bump. I didn't notice it during build (I used my usual .mozconfig file from the previous recent build) and it came up with no audio working. You have to explicitly enable ALSA support. That was a nasty thing to do and I did not appreciate the recompile... fry another egg on my CPU.

I used to have trouble with pulseaudio, but that is no longer the case. I'm over it. I don't even mind SystemD when used nicely... it's mostly the fast food distros that have rubbish behaviour.

[Weasel]

IMHO nobody sane would listen to your advice as far as software development goes ;-)

IMHO nobody sane would listen to your advice as far as software development goes.

My opinion is > your opinion.

[Guest]

Wtf, everyone, stop feeding the troll. He's famous for his anti-Rust stance and thrives on you engaging him with rational arguments.

[Weasel]

Wtf, everyone, stop feeding the troll. He's famous for his anti-Rust stance and thrives on you engaging him with rational arguments.

Spoken like a true Rust fanboy. Nobody sane can defend this language.

And also "rational arguments" can't apply to something that was probably designed in a mental asylum.

[jacob]

Spoken like a true Rust fanboy. Nobody sane can defend this language.

And also "rational arguments" can't apply to something that was probably designed in a mental asylum.

Well I can't argue with that. Most people will never match your detailed knowledge of mental asylums.