PM / Basilisk — Multi-core/multithreading?

[VLMin]

Greetings! Since the introduction of Firefox 57 (Quantum), I have been curious about the future of PM with respect to large (not just incremental) speed improvements. Speed, and certain crashes when so-called "free memory" runs very low, is the primary issue I have with PM.

I don't know whether, using the XUL foundation, it is possible to move part or all of the application to multithreading, or whether it is even a good idea. Would someone from the dev team be willing to comment on this, and upon the matter of PM browser speed in general?

Thank you.

[Pallid Planetoid]

For me Pale Moon holds up well for speed.

Using http://speed-battle.com/ Pale Moon comes out relatively better than any of my other browsers (you have to run a number of tests [in my case six] and then discard the outliers i.e. see the high end for Pale Moon below to start which I discarded this high-end test as I did with the low-end test for each browser out of a total of six tests leaving four to average).

Pale Moon high end (discarded for example):

Which I throw along with the low end test. This is exemplary how extreme high and low ends can be.

Tests are presumably impacted by system and browser setup variables (I didn't bother to test each browser in safe-mode which would have been apples to apples) among other things but it gives a rough idea.

Below are representative of the four middle tests I end up (which is close to what I've posted below for each browser) after discarding the two extreme outliers.

Comparison tests.

Pale Moon:

Firefox:

Opera:

Chrome:

IE11:

I was surprised Opera was this low (it seems faster using it).

Just for kicks here is Basilisk (clean install with bookmarks etc migrated over from IE11) the results demonstrate how a relatively clean install performs significantly better (which of course is not the case with all the other browser tests).

Basilisk HIGH-END:

Basilisk LOW-END:

Basilisk results discarding these two outliers and averaging the other four tests of six results is an overall score of 602.

[Moonchild]

Multithreading is already extensively used, in both Pale Moon and Basilisk.
We plan to leverage parallelism more in the future, too, using OpenMP.

[VLMin]

Thank you both, interesting and helpful, especially those test results.

Moonchild, I am also curious whether the multithreading differs substantively between the 32- and 64-bit versions of the code. Thus far, I have stayed with the 32-bit version, primarily because some of the add-ons I enjoy aren't set up for 64-bit code. But I do have an eye on switching at some point in the future, if the performance improvement seems substantial. I imagine at least some others share a similar perspective.

[Moonchild]

Architecture and parallelism have very little to do with each other. 32-bit and 64-bit will behave the same when given the same parallel/non-parallel code.

[VLMin]

I see, thank you. Then we can anticipate that the 64-bit code will run at least somewhat faster than the 32-bit, in the usual sense, and that at least some extensions will work only with the 32-bit code. Correct?

Is there a list of extensions, at least PM-listed extensions, that are known to work with the 64-bit code?

PS: And will the 64-bit version refuse to install any 32-bit-only extension?

[Giraffe]

Now, this is very shallow: Pale Moon never goes above 25% CPU on a 4-core Broadwell chip; using Basilisk I noticed that the CPU will go up to 100% and is usually >50% when loading sites.
Basilisk is much faster at opening a group of sites (it also seems to use less RAM than PM and release it as tabs are closed).
Fx 57 and Bk (sorry - needed an abbreviation) are very close in speed but Fx uses twice as much RAM) are very close in JetStream tests - I've now uninstalled Fx as there seems to be no point in having it!

[adesh]

PS: And will the 64-bit version refuse to install any 32-bit-only extension?

For extensions (e.g. UBO, ABP, NoScript, TMP etc.), it does not matter. With respect to add-ons, architecture matters only for plugins, e.g Flash, Java, Silverlight etc.

[Vitasta]

@Pale Moon Rising

I do not understand: Why do you have such bad performances results on http://speed-battle.com/ ?
Score 294 for Firefox 47?
According to this http://speed-battle.com/statistics_e.php Firefox 47 has a score of 625.

Do I miss anything? Just confused.

[VLMin]

For extensions (e.g. UBO, ABP, NoScript, TMP etc.), it does not matter. With respect to add-ons, architecture matters only for plugins, e.g Flash, Java, Silverlight etc.

Thank you, adesh. Those 3 terms ... the generic "add-on" and the more specific "extension" and "plugin" ... have always been a touch fuzzy to me. I know that add-on comprises at least the other two, and possibly more. And I don't know quite where extension ends and plugin begins, so to speak.

[Pallid Planetoid]

@Pale Moon Rising

I do not understand: Why do you have such bad performances results on http://speed-battle.com/ ?
Score 294 for Firefox 47?
According to this http://speed-battle.com/statistics_e.php Firefox 47 has a score of 625.
Browser Performances.PNG

Do I miss anything? Just confused.

I'm assuming those test are probably a fresh install without any add-ons. Take a look at the Basilisk results which was at the time a fresh install without or limited add-ons at the time. I think I have over 30 add-ons in FF and it was install ages ago (10+ years ago as I installed one of the first releases at the time) and never re-installed --- that's going to slow things down a bit. And of course those scores will be reflect by other factors as well, (system, network, connection speed etc etc I presume). It is really meant to be used to compare apples to apples, that is all other outside factors equal so what that means is to test different browsers on the same users environment to see how the compare this way and certainly NOT to be used as a global comparison using different environments. I'm not sure how valuable those scores are that you mention since many other factors have to be taken into account (which is why I'm assuming that those results are minimally involving fresh install test results).

Addendum: Okay I looked at what you are referring to and I'm assuming this is an average of all users who have used this test on-line possibly (so perhaps I'm wrong about the fresh install) but many outside factors still have to be taken into account as I mentioned and because this is presumably an average that takes into account many different random environments those results may not be an accurate depiction of what any one person might get as it relates to each persons unique conditions. Again, I see the test more to compare different browsers with all other factors equal to see how they stack up in the same environment which is what my results are.

[prenex]

Actually as a single-core machine user I prefer pale moon over anything else right because it "works" even with no multiple cores. When I say it works, I mean there is really full-featured browser with enjoyable browsing speed even while I have 5-8 tabs open with heavy pages on a 10 year old machine with a stripped-down-enough system.

Everything that is webkit is worse for example. They tend to even open processes for tabs and do things that are actually quite heavy in resources and only get any better results because of the parralelism. Using threads is really a key for those who want to stick with old machines because of the much lower overhead. Also I like it very much that pale moon does not need many hudreds of gigabyte memory and still show a lot. Actually despite having this older machine I can both browse and develop (light) or actually even browse and play (quite heavy but it works!!!)

I just hope things will remove fast somehow. I think actually using the processes instead of threads is wasting resources even on stronger machines, just because of the cores used well it is not as much noticable. Also pale moon clearly wins the speed rush with firefox too and when I use it at work from a reasonable machine I still beats chromium in my opinion: I need to run VMs and giving them a lot of memory so for me the lower footprints are still key... start chrome-like things and there comes my dear fearful "swapout" happening all the way.....

[JoeyG]

I know this thread is old, but I just came across it. I also just tried the "speed battle" website for the first time.

This is my result.


Sorry for the stupid questions, but ...
(1) Why is my score so good? (I actually tried it several times. My best score was 14,387)
(2) Why is my score for Basilisk 3x better than when using the latest version of Chrome (v. 66.0.3359.170)?

Thanks.

[satrow]

Sorry for the stupid question, but why is my score so good?

Thanks.

Not a stupid question, benchmark scores depend on how good the hardware is, the comparison is of an average from all the v. 52 FF benchmarks.

Basilisk top, Pale Moon below, both x64 and from my normal profiles ~ 1.3-1.4GB memory in use:

167.18 1170.29 70.62 1408.09
172.46 1092.27 73.14 1337.87

Really, you should only compare with identical hardware/OS, clean profiles, all set up in exactly the same way, for the best comparison.

[JoeyG]

Really, you should only compare with identical hardware/OS, clean profiles, all set up in exactly the same way, for the best comparison.

OK, thanks.

Hmmm, am I right to interpret my results as indicating that my computer is "better" (i.e. my cpu and ram are faster, etc.) than those of most of the other people who did the test?

And is internet connection speed somehow involved?

Thanks again.

[satrow]

Yes, that ties in with my interpretation of this test, similar for other browser benchmark sites, though some are better real-world performance indicators than others, none are great.

[JoeyG]

Yes, that ties in with my interpretation of this test, ...

Again, thank you for your replies.

[vannilla]

As far as I know, XUL itself can't be multithreaded from the add-on point of view, only from Pale Moon core, and in a limited way.
That is, an add-on developer can't explicitly execute a task in a different thread when dealing with XUL.
Being able to do that helps both an add-on developer and the core browser, as it allows to decouple lengthy operations from UI updates, giving a more responsive interface.
This was one of the reasons given by Mozilla when they removed XUL from Firefox.
However, this limitation exists only when operating on the user-interface, which is true pretty much for 90% of the toolkits out there (like gtk+ or qt).
There are ways to take operations out of the "UI thread", like how Android does it (Android applications are essentially single-threaded), but to add explicit multithread support in XUL would probably mean to revisit the whole architecture, which most likely require a dedicated team (i.e. much more workforce than the current dev team).

[Moonchild]

I think you're mixing up 2 layers of execution here.
Multithreaded execution is a much lower level than what extension run on -- if Mozilla is claiming that that is the reason for deprecating XUL then that sounds like yet another bogus reason.

Here's why it's bogus:

• XUL is a UI markup language. It has nothing to do with how things are executed.
• The parser itself may not have a high degree of parallelism, and be mostly single-threaded, but that has nothing to do with anything beyond building up the UI elements from the definition file. The rest is done with scripting in extensions. It will be as multithreaded and parallel as any other XML-type parser in the browser (including HTML).
• Scripting in extensions is JavaScript. JS by its very nature is event-driven.
• If you want to decouple operations from the UI in extensions using JS, then you use asynchronous methods like observers/callbacks, promises or some of the more fancy ES6 constructions to do so. THAT level of multi-threading (execution threads) and asynchronicity has absolutely nothing to do with the lower level muti-threading (processing threads).

[vannilla]

I should probably look more into it.
Anyway, I was recalling incorrectly about Mozilla: it wasn't about multithread but multiprocess (Electrolysis). Apologies for that.