Defaulting to AVX for 64-bit architectures?

[R3n_001]

I think x86 existing as SSE2, and x64 being AVX would be fine. Not entirely sure about AVX2 unless there's some big leap in testing. I don't use any non-AVX2 machines regularly except for my X230 though, but none of them run Pale Moon since I found it too slow for my use. I also need WebExtensions more than ever now, so highly doubt I'll move back unless something drastic happens, so my opinion probably doesn't even count.

A few ideas though:
e10s: e10s will probably give a lot more performance than AVX would. I know it made Waterfox Classic usable when I used to main a pre-Quantum browser.

Use SSSE3, or a pre-AVX instruction set but post-SSE2: SSSE3 is the Waterfox approach, also note the third S, that is not a typo. I wouldn't recommend specifically SSSE3 since Phenom doesn't support it, but that's mostly because I have a weird attachment to Phenom chips, and probably not a big deal in the grand scheme of things.

Leave it to the community to maintain other builds: The XP fork already builds for pre-SSE, SSE, SSE2, and SSE2 x64. I asked the dev previously and he was uninterested in an AVX build. (this was before the unofficial AVX builds existed) I would say this is a pretty safe bet, but because of bad blood I'm assuming this wouldn't work too well unless someone else makes a SSE2 build.

[Pentium4User]

I think x86 existing as SSE2, and x64 being AVX would be fine.

The question is how many people will run x86 and need old plugins and need a current version.
IIRC currently no plugin still in development exists, so the remaining users could stay on their old PM version just for the old plugins.

With Win 10 reaching EoL in 2025, the only reason are the plugins because Win 11 doesn't run on x86-only machines.
Although, many x64 CPUs without AVX are still in use and still sold.

[moonbat]

e10s will probably give a lot more performance than AVX would.

And all it needs is to as good as rewrite the entire browser from scratch. Easy peasy

[R3n_001]

With Win 10 reaching EoL in 2025, the only reason are the plugins because Win 11 doesn't run on x86-only machines.

Windows versions going EOS* is not a concern here. Seeing as PM still supports 7.

11 officially is Intel 7000 or Ryzen 2000, both of which are AVX2. You could say just unofficially run 11, but seeing how they've added the requirement for POPCNT (SSE4A for AMD or SSE4.2 for Intel) in a update, that's not a given as a future update could require something like AVX or AVX2 in the kernel or system level. I guess not an issue for PM if it makes AVX2 build, but I'm saying keep the x86 build as a this will just run if the system can run Windows 7-10. (Yes I know 7 doesn't exactly need SSE2, but unless you have some dual P3 machine, it will not run well)

[Nuck-TH]

Even through i voted to keep things as is, only then i remembered that SSE builds were phased out about the same time after last non-SSE2 cpu as now from last non-AVX one.
I would be fine either way - doing current 6 builds take absolute minimum effort and machine time(~17 min/build) is not my concern(it doesn't lock me out from using PC) and i can always postpone it for a day or two if really necessary.
My main concern that changing default channel will break things for some people(and probably raise confusion if it is impossible to implicitly switch my current AVX channel to official one). I think explicit warning should be made in applications well in advance so setups on non-AVX cpus won't suddenly break.

[athenian200]

I think x86 existing as SSE2, and x64 being AVX would be fine. Not entirely sure about AVX2 unless there's some big leap in testing. I don't use any non-AVX2 machines regularly except for my X230 though, but none of them run Pale Moon since I found it too slow for my use. I also need WebExtensions more than ever now, so highly doubt I'll move back unless something drastic happens, so my opinion probably doesn't even count.

A few ideas though:
e10s: e10s will probably give a lot more performance than AVX would. I know it made Waterfox Classic usable when I used to main a pre-Quantum browser.

Well, if you rely on WebExtensions and you're fine with e10s, you don't really need Pale Moon anyway... you could run pretty much any mainstream browser, or a fork like LibreWolf or something if you want some of the telemetry ripped out. I honestly don't know why anyone who doesn't need XUL or distrust e10s would ever run Pale Moon anyway... it's primarily for people who are uncomfortable with e10s and rely heavily on XUL extensions. I mean, yeah, it's probably true that e10s would speed things up, but it would also make Pale Moon into a totally different project.

Though honestly, I can't remember right now why we chose not to support WebExtensions at all. I seem to remember we were considering keeping them at least for Basilisk, but then something changed last-minute and we got rid of them? My memory is a bit hazy on that point. I think Firefox 52ESR actually did support them, and I don't think they require e10s at all... I think it was originally to try and spur development of XUL extensions, but I feel like that hasn't worked out how we hoped.

Use SSSE3, or a pre-AVX instruction set but post-SSE2: SSSE3 is the Waterfox approach, also note the third S, that is not a typo. I wouldn't recommend specifically SSSE3 since Phenom doesn't support it, but that's mostly because I have a weird attachment to Phenom chips, and probably not a big deal in the grand scheme of things.

We can't really do that because Visual Studio only has separate build flags for SSE2, or AVX which implies support for SSE4.2. We can't actually target a version of SSE higher than 2 without also targeting AVX, at least not on Windows. I think Waterfox uses Clang or something, so they don't have that issue.

Leave it to the community to maintain other builds: The XP fork already builds for pre-SSE, SSE, SSE2, and SSE2 x64. I asked the dev previously and he was uninterested in an AVX build. (this was before the unofficial AVX builds existed) I would say this is a pretty safe bet, but because of bad blood I'm assuming this wouldn't work too well unless someone else makes a SSE2 build.

Ugh, the XP fork. :/ I wish you hadn't brought that up, but since you did, I realize why we can't leave this to the community... we can't afford another Windows XP situation. If we can't eat the cost of maintaining two channels, our only real option is to leave the official builds as SSE2 indefinitely, or at least as long as we keep supporting Windows 7 and 32-bit. That is, this change probably isn't worth making until we are ready to move forward in a big way, like dropping an entire Windows edition or giving up on 32-bit versions that's going to piss people off anyway, and I don't think we have the stomach for that if we are still supporting Windows 7 and 32-bit versions of the browser.

Honestly, we only dropped Windows XP because NT5 was a pain in the butt to support, not because we care about dropping operating systems right on Microsoft's official EOL.

[Nuck-TH]

Though honestly, I can't remember right now why we chose not to support WebExtensions at all. I seem to remember we were considering keeping them at least for Basilisk, but then something changed last-minute and we got rid of them? My memory is a bit hazy on that point. I think Firefox 52ESR actually did support them, and I don't think they require e10s at all... I think it was originally to try and spur development of XUL extensions, but I feel like that hasn't worked out how we hoped.

Off-topic:
IIRC and if understand well enough - implementation in ESR52 and some versions forward is really basic, so pretty much only userscript-level extensions could work. And it was tied to australis, so no easy support in classic UI. Because of that there were complains of extensions not working, because they were targeting newer FF versions.
All in all, it just was not worth the trouble.

Also, adding to granular cpu instruction set selection above, i don't think that it would be productive to build with such granularity, and it was mentioned that SSE3, 4 and whatever before AVX won't make as much impact.
It also worth noting that the way i configure linux AVX builds is not fully correct - proper way would be using flag that enables whole CPU feature level in same fashion as MSVC one does. -mAVX enables only AVX afaik.

[R3n_001]

Even through i voted to keep things as is, only then i remembered that SSE builds were phased out about the same time after last non-SSE2 cpu as now from last non-AVX one.

I guess but non-AVX CPUs are still feasible for general use today, when something like the common P3 was a bit too slow to use. The average C2Q could still work as a general browsing or use machine. I do think x86 being SSE2 and x64 being AVX would be a good compromise though.

Well, if you rely on WebExtensions and you're fine with e10s, you don't really need Pale Moon anyway... you could run pretty much any mainstream browser, or a fork like LibreWolf or something if you want some of the telemetry ripped out. I honestly don't know why anyone who doesn't need XUL or distrust e10s would ever run Pale Moon anyway... it's primarily for people who are uncomfortable with e10s and rely heavily on XUL extensions. I mean, yeah, it's probably true that e10s would speed things up, but it would also make Pale Moon into a totally different project.

I think it would be cool to have a still developed super customizable pre-57 Firefox fork. Waterfox Classic was pretty much that for me, but it was missing a lot of the PM themes I loved. I used a few classical extensions, but I figured out how to replace them with WebExtensions, and I guess modern browsers are good enough. Would still be nice to have a goofy light and compatible browser though.

We can't really do that because Visual Studio only has separate build flags for SSE2, or AVX which implies support for SSE4.2. We can't actually target a version of SSE higher than 2 without also targeting AVX, at least not on Windows. I think Waterfox uses Clang or something, so they don't have that issue.

I have seen SSE3 and SSE4 builds done with MSVC, Firefox fork known as Mercury. No idea if the mozconfigs can be applied to PM though. I've heard MSVC is better for performance, but I haven't tried to test it. Wonder what it would take to build PM with clang to test.

Ugh, the XP fork. :/ I wish you hadn't brought that up, but since you did, I realize why we can't leave this to the community... we can't afford another Windows XP situation.

The AVX builds seem to have gone well, the same but SSE2 should be fine I think.

Off-topic:
IIRC and if understand well enough - implementation in ESR52 and some versions forward is really basic, so pretty much only userscript-level extensions could work. And it was tied to australis, so no easy support in classic UI. Because of that there were complains of extensions not working, because they were targeting newer FF versions.
All in all, it just was not worth the trouble.

I know Waterfox Classic was able to add webRequest and that was the basic thing I needed. Maybe a basic compatibility shim for the PM UI could work idk. Although someone just making Mini Pixiv in XUL or Bootstrap would probably be easier and I think that's it. The only other thing I would need is an adblocker with working YouTube ad blocking. No idea if the old uBlock Origin fork would work, I know you need a modern (WebExtension) uBlock Origin version for it to work. I would need to install Pale Moon and deep dive into old extensions to see if there's anything else I use that can't be userscripted or has an alternative available.

[satrow]

Possibly of general interest, a cross section of Steam gamers and their current (I did it yesterday from my Ivy Xeon) CPU hardware features https://store.steampowered.com/hwsurvey/ I think ~32% were from CN, so maybe a higher rate of 9x-XP era hardware than 'average'.

SteamHardwareSurveyFeb2024.png

[Nuck-TH]

I think it would be cool to have a still developed super customizable pre-57 Firefox fork. Waterfox Classic was pretty much that for me, but it was missing a lot of the PM themes I loved. I used a few classical extensions, but I figured out how to replace them with WebExtensions, and I guess modern browsers are good enough. Would still be nice to have a goofy light and compatible browser though.

Off-topic:
Before current UXP there was effort to build it on ESR56 that went to nowhere because then started massive refactorings in FF code gave too much trouble to dance around them.
e10s as well is not the best way to do things - it gives endless abyss of security issues that doesn't seem to drying up anytime soon. Would be insanely hard to keep it patched up while being desynced from mainline FF.
Proper multithreading should yield similar results without drawbacks of e10s, but reingeneering will need lots of research and effort, which is big issue.

[Moonchild]

Ugh, the XP fork. :/ I wish you hadn't brought that up, but since you did, I realize why we can't leave this to the community... we can't afford another Windows XP situation. If we can't eat the cost of maintaining two channels, our only real option is to leave the official builds as SSE2 indefinitely, or at least as long as we keep supporting Windows 7 and 32-bit. That is, this change probably isn't worth making until we are ready to move forward in a big way, like dropping an entire Windows edition or giving up on 32-bit versions that's going to piss people off anyway, and I don't think we have the stomach for that if we are still supporting Windows 7 and 32-bit versions of the browser.

I'm thinking the opposite is true in this case, since we'd not be setting this minimum requirement across the board here. It would only be for the 64-bit versions. I don't see an issue with asking people on particularly old hardware to use 32-bit instead. We are already eating the cost of maintaining two channels here, 32 and 64-bit.
We can tackle deprecation of 32-bit and pre-AVX hardware later on, in that case.

I can't remember right now why we chose not to support WebExtensions at all.

Basically it'd be a maintenance burden we could not bear. The ESR52 implementation was a whole lot of hackery to shove HTML elements into XUL UIs through the WE framework. It was never good or particularly safe. We'd also have to continuously follow mozilla whenever they would add another WE-specific bridging API for WEs to reach into the browser for UI manipulation (even something as simple and content-focused as ad blockers require a specific API for UI interfacing). With WEs literally being inferior in the capabilities they have to work with web content and the browser core, there was literally no reason to maintain both technologies and loading us down with more work we could not reasonably do in the time and with the resources given. WE's were designed to eventually be isolated through e10s from the get-go. Even so there are still a lot of very risky things about how WEs integrate in Firefox. Chrome doesn't really have that problem because their UI is not building on web-adjacent technologies like we do.

Maybe a basic compatibility shim for the PM UI could work idk.

No, it would be hacky and insecure.

non-AVX CPUs are still feasible for general use today

Barely.

I do think x86 being SSE2 and x64 being AVX would be a good compromise though.

If you are on 10+ year old hardware, you're likely limited on the RAM you can drive anyway, so 32-bit applications would be much more likely to be a match.
AVX is not an option on 32-bit builds anyway since it requires 64-bit architecture and instructions.

[Moonchild]

Possibly of general interest, a cross section of Steam gamers and their current (I did it yesterday from my Ivy Xeon) CPU hardware features https://store.steampowered.com/hwsurvey/ I think ~32% were from CN, so maybe a higher rate of 9x-XP era hardware than 'average'.

SteamHardwareSurveyFeb2024.png

Yeah pretty much what I gathered. Over 95% (97) is on AVX-capable hardware.

[Pentium4User]

Possibly of general interest, a cross section of Steam gamers and their current (I did it yesterday from my Ivy Xeon) CPU hardware features https://store.steampowered.com/hwsurvey/ I think ~32% were from CN, so maybe a higher rate of 9x-XP era hardware than 'average'.

SteamHardwareSurveyFeb2024.png

Yeah pretty much what I gathered. Over 95% (97) is on AVX-capable hardware.

Steam means that are almost gamers. Current games won't run well even on current Pentium/Celeron or older Core (i).
That is most likely the reason for that.
I think we should create a poll where all users of PM are notified, so we know the real amount of machines that lack AVX.

[R3n_001]

Off-topic:
Proper multithreading should yield similar results without drawbacks of e10s, but reingeneering will need lots of research and effort, which is big issue.

Not entirely sure if modern Firefox is properly multithreaded, but setting one content process, about as close to disabling e10s as can be gotten, lasts a few days before it starts to really slow down. I tested with a browser I basically only use on YouTube. Maybe YouTube insane JS file has big memory leaks idk.

Barely.

I haven't like tried to main it, but I know some of the later machines like my X5680 and 1090T computers are still pretty fast for general use. I guess it would be fun to see how X5680 would fare as main PC, but I would need to get more RAM for it and get some NVMe adapter cards. Or maybe I wouldn't need RAM since I could just dedicate current main as build machine. Maybe run ESXI or QEMU or something that lets me use VMs with all my cores.

[Lucio Chiappetti]

I think we should create a poll where all users of PM are notified, so we know the real amount of machines that lack AVX.

Does such a thing as a list of all users exist ? I don't think so as no "registration" is required to install PM!

[athenian200]

I'm thinking the opposite is true in this case, since we'd not be setting this minimum requirement across the board here. It would only be for the 64-bit versions. I don't see an issue with asking people on particularly old hardware to use 32-bit instead. We are already eating the cost of maintaining two channels here, 32 and 64-bit.
We can tackle deprecation of 32-bit and pre-AVX hardware later on, in that case.

The main problem I see is that 32-bit is limited to 4GB of RAM, modern web pages barely work with 4GB of RAM, and we have memory leaks on top of it. I don't think anyone can realistically browse the web in 2024 on a machine with less than 8GB of RAM. The days of web browsing being a lightweight thing that's easy on RAM are over. I think a good argument could be made that Pale Moon should be 64-bit only because it is single-process and therefore needs the additional address space in a way other browsers don't.

Basically it'd be a maintenance burden we could not bear. The ESR52 implementation was a whole lot of hackery to shove HTML elements into XUL UIs through the WE framework. It was never good or particularly safe. We'd also have to continuously follow mozilla whenever they would add another WE-specific bridging API for WEs to reach into the browser for UI manipulation (even something as simple and content-focused as ad blockers require a specific API for UI interfacing). With WEs literally being inferior in the capabilities they have to work with web content and the browser core, there was literally no reason to maintain both technologies and loading us down with more work we could not reasonably do in the time and with the resources given. WE's were designed to eventually be isolated through e10s from the get-go. Even so there are still a lot of very risky things about how WEs integrate in Firefox. Chrome doesn't really have that problem because their UI is not building on web-adjacent technologies like we do.

That makes a lot of sense. I forgot about WE injecting HTML elements directly into the UI... that's why we can't mix the technologies. It's also why modern Firefox and Chrome look so awful, the whole interface has to just be a giant HTML5 page with no native UI styling at all, in order to accommodate WebExtensions. The truth is, even when I use a modern browser like Edge, I don't use WebExtensions, I just use the browser the way it comes in order to access modern websites and don't even think about extensions, so I have limited exposure to them and forget how they work.

If you are on 10+ year old hardware, you're likely limited on the RAM you can drive anyway, so 32-bit applications would be much more likely to be a match.
AVX is not an option on 32-bit builds anyway since it requires 64-bit architecture and instructions.

Well, that sounds like something worth investigating... I think anyone on a RAM-starved system with less than 8GB should probably be running the 32-bit version of Pale Moon anyway, but I think anyone with more than 8GB would be hating life if suddenly limited to a 4GB address space. So the question is... how much RAM exactly do these pre-AVX systems have? If they have 4GB or less, you are absolutely right... but if a lot of them have 16GB, we might need to reconsider.

[Pentium4User]

I think we should create a poll where all users of PM are notified, so we know the real amount of machines that lack AVX.

Does such a thing as a list of all users exist ? I don't think so as no "registration" is required to install PM!

That's why I suggested a poll that is being announced when installing the next PM version, like the release notes page that shows up.

how much RAM exactly do these pre-AVX systems have? If they have 4GB or less, you are absolutely right... but if a lot of them have 16GB, we might need to reconsider.

Mine has 16 GiB.

[Moonchild]

The main problem I see is that 32-bit is limited to 4GB of RAM, modern web pages barely work with 4GB of RAM, and we have memory leaks on top of it.

I'm well-aware of that. At the same time, I hardly ever see my Pale Moon browser use more than 2 GB of RAM, even with heavy use. Then again I do use suspender to suspend idle tabs...
I'm assuming then that a good portion of users would need more than 4GB for the application, going by your assumptions.

So, this would mean, overall:

• If we want to satisfy plugin users, we'd need to maintain 32-bit.
• If we want to satisfy people on old (or otherwise severely crippled) hardware that do make heavy use of Pale Moon, we'd need to maintain 64-bit SSE2.
• If we want to satisfy people's needs for a performant browser, especially in heavy use scenarios, we'd need to move to using AVX.

The reality is that we cannot maintain every possible use case under the sun and go by lowest common denominator. We also don't have the resources or manpower to implement multiple code paths for every component in the browser. We don't gather telemetry so we don't know hard numbers. We also can't expect the average user to know whether they have an AVX capable CPU, so a broader survey would not necessarily provide reasonable numbers for us to use.

Potential solutions include:

1. Discontinue 64-bit SSE2, directing people on it to 32-bit. This would cause the above limitations and likely needs more restarts to deal with memory pressure.
2. Add an AVX channel as a extra release channel, and somehow migrate all people on AVX capable systems to it, leaving others on SSE2 (potentially needs an AVX check in the internal updater and some risky code that needs to be thoroughly checked for function on a wide range of hardware). This adds a much bigger release burden on us for all platforms (2 extra builds on Linux, 1 on Windows, possibly more for Mac an BSD, also) and this would cause confusion among users not knowing "what version they need". I'm really, really not in favour of this.
3. Discontinue 32-bit "too bad, so sad" and replace it with maintaining two 64-bit channels. This causes the same extra burden on upgrading and Linux/altarch builds and I feel like this 64-bit version would end up being like a shoved-under child. Similar confusion to the three-channel setup for end users. Consider not supporting NPAPI in mainline while we're at it, since there aren't really any practical use-cases for 64-bit plugins.
4. Discontinue 32-bit and 64-bit SSE2, leaving us with just AVX. Let people choose contributed builds for 32-bit, SSE2 or other preferred configurations if they need it, and let contributors use the leniency in our redist license to build with official branding in those cases. More of a wild-west option but relieves release engineering pressure from us. I'm fairly confident our community can make this work, though.
5. Do nothing and have it be detrimental to 95%+ of users in terms of optimization. Almost everybody loses.

I honestly can't say I particularly love any of these options. It will have to be a compromise no matter what.

[Eduardolucas1]

1. Discontinue 64-bit SSE2, directing people on it to 32-bit. This would cause the above limitations and likely needs more restarts to deal with memory pressure.

i would like to respectfully and graciously provide to the analysis that there are 64-bit only OSes which distribute pale moon as a as it is 64-bit SSE2 package where using a 32-bit build would not be possible without recompiling, and where there are no people to provide, which would leave users without AVX without options, as these OSes are incompatible with linux or BSD ABIs and kernel calls and linux builds provided by the community would not be a solution. This may be a nuisance.

[andyprough]

4. Discontinue 32-bit and 64-bit SSE2, leaving us with just AVX. Let people choose contributed builds for 32-bit, SSE2 or other preferred configurations if they need it, and let contributors use the leniency in our redist license to build with official branding in those cases. More of a wild-west option but relieves release engineering pressure from us. I'm fairly confident our community can make this work, though.

Us GNU/Linux users have already been on this basic scheme for awhile -
- 32-bit builds come from our own compilation or 3rd party
- Main build is SSE2 (just switch to AVX)
- AVX build is 3rd party (just switch to SSE2)

I haven't heard any big complaints, we make it work just fine. Note - I'd still like to have access to the AVX2 builds somehow or other - if it remains 3rd party via @Nuck-TH that's no problem from my view (hope @Nuck-TH would be OK with it).

2nd note - I've built and contributed a lot of kernels to distros in the past, and have built Pale Moon many times. I'd be willing to help out if needed.