Defaulting to AVX for 64-bit architectures?

[andyprough]

The Pale Moon browser has for long enough been the default browser in most builds of 'Puppy' Linux over the last several years.....and Puppy's "mission" has always been to keep elderly hardware useful. We've plumped for Pale Moon because it's lightweight yet still blazingly fast on most older hardware.....and is up-to-date enough to support the modern web.

Are you saying Puppy doesn't have their own builds? I really doubt that, that would really be surprising to me. Isn't Puppy heavily invested in 32-bit systems? The Pale Moon devs haven't even made a 32-bit GNU/Linux build in a long while now. Since Puppy probably does have its own builds, the default GNU/Linux builds pushed out by the Pale Moon devs are irrelevant. I'm wondering why you would be complaining in this manner?

[Moonchild]

Are you saying Puppy doesn't have their own builds?

As far as I know they do, and have for years.

[Mike_Walsh]

Are you saying Puppy doesn't have their own builds? I really doubt that, that would really be surprising to me. Isn't Puppy heavily invested in 32-bit systems? The Pale Moon devs haven't even made a 32-bit GNU/Linux build in a long while now. Since Puppy probably does have its own builds, the default GNU/Linux builds pushed out by the Pale Moon devs are irrelevant. I'm wondering why you would be complaining in this manner?

Actually....no. Is that really so hard to believe?

You're making the inevitable mistake - made by hundreds of folks before you - of assuming that Puppy is built & maintained by a dedicated team of people, in the same way that most 'mainstream' distros are. This couldn't be further from the truth.

Virtually all Puppies/re-masters/Puplets are the work of single individuals. There is often collaboration in the community on certain stuff, but not often with large programs (which are usually modified from that supplied by mainstream repos)....and very definitely not with stuff like browsers. The only Puppy user I know of that has ever attempted compiling Pale Moon was Walter Dnes.....and I recollect that most of you seemed to spend your time taking the p**s out of him..

We find that Steve Pusser's builds of Pale Moon work well for us.....and a guy known on the Puppy forum as 'Fenyo' has supplied many SSE-only builds for those with truly ancient 'clunkers'.

Since many of you appear to consider compiling as "all in a day's work", I'm sorry to have to burst your bubble. To most people, it's anything but...............and is seen as a frightening behemoth of a monster, complete with claws & fangs. Most people would never even consider compiling from source, and tend to take the attitude of "Oh, that's dev's work. I'm just a user..."

It's an acquired skill.....and like any other skill, some pick it up very easily. For others, it's forever beyond them, no matter how much effort they put in.

I doubt you'll hear much more out of me. I, for one, am getting more than a little fed-up with the smug, sarcastic 'smart' answers there appear to be to every query in this forum.....so I'll leave y'all to your exclusive little club.

Ciao!

Mike.

[moonbat]

I, for one, am getting more than a little fed-up with the smug, sarcastic 'smart' answers there appear to be to every query in this forum

Andy wasn't being sarcastic, he was asking why you can't use your own builds as was the impression he had, but you do you.

[Moonchild]

You're making the inevitable mistake - made by hundreds of folks before you - of assuming that Puppy is built & maintained by a dedicated team of people

I've never assumed that. in fact it seemed to me to be a community effort of enthusiasts to provide for everyone's enjoyment.

However, I was under the impression all the same that binaries used on Puppy were built from source specifically for it. And that would literally just need one person (the package maintainer for Pale Moon) to do that, not every Puppy Linux user. But feel free to correct me on that if that's not the case.

so I'll leave y'all to your exclusive little club.

I don't get what's ticked you off so much that you needed the kind of tone used, but eh, it's your choice to leave. You do you, indeed.

[andyprough]

I doubt you'll hear much more out of me. I, for one, am getting more than a little fed-up with the smug, sarcastic 'smart' answers there appear to be to every query in this forum.....so I'll leave y'all to your exclusive little club.

I was not being sarcastic at all. I know some of the people who share packages with the Puppy community. I have compiled many different GNU/Linux packages and shared them with different distro communities myself, especially kernels. I see no potential for injury on the basis of any decision for default GNU/Linux packages by the Pale Moon devs. If you want to argue technically how their decision to do nothing more than compile their own versions of packages that target one feature of modern CPU's is going to harm you, I'd be more than willing to listen. But at the end of the day, you are responsible for your own hardware choices, nothing about the devs' preferences is going to change that. They are not in any way talking about constraining your freedom to build for your own hardware. This is in no way similar to situations like RedHat and friends holding vast numbers of packages hostage if you refuse to go along with systemd, and just locking you out completely from various app ecosystems. You shouldn't conflate all developer decisions with the worst kinds of developer decisions.

Since many of you appear to consider compiling as "all in a day's work", I'm sorry to have to burst your bubble. To most people, it's anything but...............and is seen as a frightening behemoth of a monster, complete with claws & fangs. Most people would never even consider compiling from source, and tend to take the attitude of "Oh, that's dev's work. I'm just a user..."

It's an acquired skill.....and like any other skill, some pick it up very easily. For others, it's forever beyond them, no matter how much effort they put in.

I'll just note that I find this a particularly silly argument when seen against the backdrop of the Pale Moon devs literally giving you the step by step commands to copy and paste into your terminal to build and use Pale Moon on GNU/Linux. And being more than willing to help anyone with build instructions for unusual use cases in this forum. I myself have gotten many build questions answered here when I was compiling Pale Moon for unusual distros like Hyperbola.

[null_ID]

However, I was under the impression all the same that binaries used on Puppy were built from source specifically for it.

Wrong. The official .tar.xz download from your site has always worked out of the box. Puppy Linux has always satisfied Pale Moon's requirements. Just unpack to a folder of choice and you're good to go. It's how I've been using this browser for years. The Steve Pusser-builds approved by you also work as is.

Isn't Puppy heavily invested in 32-bit systems?

This is incorrect. Not JUST 32-bit, Puppy caters to most any system. I remember seeing 64-bit support going as far back as 12 years ago. But Puppy's flexibility allows extensive support for legacy systems as well. Their dev tools, the Woof-CE build system allows you to spin up a Puppy system for ANY scenario, for any system or environment. Sky's the limit, it's just a matter of the individual developer's will to keep maintaining their unique builds. Puppy supports both old and new alike, and many specialized versions for specific tasks exist.

[andyprough]

This is incorrect. Not JUST 32-bit, Puppy caters to most any system. I remember seeing 64-bit support going as far back as 12 years ago.

I am aware, I did not say "just 32-bit". And the vast majority of your 64-bit users are going to benefit from the move to faster AVX builds.

[marigold]

My CPU does support AVX but not AVX2.

However, I think the pros of AVX / AVX2 do not outweigh the cons - which is that PaleMoon will end up losing a lot of its userbase on old hardware. Without a growing userbase, most opensource projects tend to die after its lead benevolent dictator / maintainer loses interest in the project. The general consensus among the popular browser makers too is that these minor performance gains are not worth alienating a large number of users on older platforms (see Whats stopping all the other browsers to be compiled in AVX2 and optimizations like Thorium ?).

This answer also suggests that the CPU may draw more power with AVX / AVX2, which would make PM unattractive for laptops, as battery drain would be more.

Moreover, Intel also cautions that improperly using AVX / AVX2 can actually decrease performance:

Although AVX is powerful, it is not a silver bullet for differentiating performance under all circumstances. For some functions in specific workloads, enabling AVX may bring performance regression instead. Hence we need to be careful in choosing and applying AVX. Based on our experience, possible reasons for AVX performance penalties include:

1. AVX to SSE transition overhead. Processor need to save/restore YMM registers when transiting between 256-bit AVX and SSE instruction, which causes performance penalty.

2. Data alignment. 256-bit AVX requires data aligns to 32 byte in memory, otherwise penalty would happen when misaligned memory access takes place.

3. Data length. Although AVX can process more data at the same time than SSE, it also needs more cycles to fill and d the pipeline. If there is no sufficient data to be processed, AVX cannot show more performance benefits than current SSE implementation.

If you do want to go ahead with it, my suggestion would be to offer 3 separate builds - an "unoptimised" 32-bit and 64-bit build and an "AVX optimised" 64-bit build. But yes, that will increases the work for the maintainers. Or abandon the plan - I honestly don't believe losing a lot of your user base is worth it. Take a hint from Mozilla, Google and Brave who have a much larger userbase and still think twice about resorting to such hardware optimisations

[athenian200]

If you do want to go ahead with it, my suggestion would be to offer 3 separate builds - an "unoptimised" 32-bit and 64-bit build and an "AVX optimised" 64-bit build. But yes, that will increases the work for the maintainers. Or abandon the plan - I honestly don't believe losing a lot of your user base is worth it. Take a hint from Mozilla, Google and Brave who have a much larger userbase and still think twice about resorting to such hardware optimisations

Doing more official builds is not a realistic option.

We're not trying to target the lowest common denominator the way Chromium or Firefox are, and I don't think that's a worthwhile goal for the project. The point is that we're not setting out to create a mainstream browser in the first place, and arguably this is a good way of resetting expectations about precisely what it is that we want setting our browser outside the mainstream.

We never intended to be "the browser for extremely old/underpowered hardware," but that seems to be the niche a lot of people expect us to fill just because we hard-forked from Firefox 52, and that codebase was capable of supporting older stuff.

Think about it, if our goal were to try and take advantage of the capabilities of aging dual-core processors the way Mozilla and Google did to get better performance on older machines, we'd probably be doing e10s or some nonsense which is implemented in a really insecure way. We've never been in favor of that. I am not sure, but I remember hearing that part of why Mozilla did e10s in the first place is because each process on Windows gets its own address space... so it allowed them to extend the life of 32-bit version of the browser on a 64-bit OS, by allowing each process to get its own 4GB independently.

The fact is, Google and Mozilla (and their more modern forks) have exactly what you want if you are trying to target the lowest common denominator here. Extending the life of older hardware is actually more of a mainstream goal than something we really wanted to pursue here.

Pale Moon is more about preserving its own actively maintained subset of the XUL ecosystem, as well as being somewhat more secure than modern browsers by eschewing e10s, and taking advantage of optimizations to run better on reasonably modern hardware. It has always primarily targeted desktop systems rather than mobile devices or even laptops.

I think the problem may just come down to the fact that what we want to make and what a lot of our users apparently want us to work on are two very different things. I feel like if we gave into that side of that userbase, we'd be stuck targeting older stuff indefinitely and thus be prevented from taking advantage of newer compilers, libraries, etc. Those people basically want to corner us into a dead-end and maintain something that won't be able to exist in 5 years.

[R3n_001]

I just tested SSE3, SSE4, AVX, and AVX2 with 115 ESR to determine what I build for my fork. I found that SSE4 is actually the winner with 18 more points in MotionMark 1.2 over AVX2 which was actually the worse performer. Everything else was practically equal. It's consistently 76 for JetStream and 5.3 for Speedometer across all. SSE3 got 350 in MM, SSE4 353, AVX 340, and AVX2 335.

I guess I'll try stock PM, AVX, and AVX2 and see how it goes.

Also if there's a better test for me to try, let me know.

Edit: Tested regular Pale Moon, AVX, and AVX2. Had to downgrade to JetStream 1.1 and got 98 points for SSE2 and AVX, 100 for AVX2. MM 1.2 got 119 points for SSE2 and AVX2, 123 for AVX. Had to downgrade to Speedometer 2.1 and got 21.2 for SSE2, and 21.1 for AVX and AVX2. Basically no difference.

[Nuck-TH]

Syntetic benchmarks are very rarely indicate UX quality, especially here, them being made for Chrome to show its "progress" and superriority over Firefox.
Also AVX(2) will more affect crunching of large amounts of data and media(through codecs afaik choose code path at runtime anyway), and less UI/interactive things.
As with any automatic optimization - it is YMMV any way.

[R3n_001]

What was me seeing which two variants I should build has turned into me benchmarking multiple browsers, including Chromium, to see if there's any major difference. So far not really. I did get into a discussion and they said to check temps and power usage and I'll try that tomorrow.

Also if you have any tests or repeatable ways to show the AVX2 build being faster than SSE2, then I'd like to know

[andyprough]

Also if you have any tests or repeatable ways to show the AVX2 build being faster than SSE2, then I'd like to know

If you find a way to test Pale Moon's video decoding, AVX2 has been shown to give a huge boost in that area. Here's one example: https://www.phoronix.com/news/AVX2-dav1d-0.9-Benchmarks

Like @Nuck-TH, I doubt that typical synthetic browser benchmark tests that target chromium engines are going to tell you terribly much about Pale Moon performance.

[Moonchild]

I just tested SSE3, SSE4, AVX, and AVX2 with 115 ESR to determine what I build for my fork. I found that SSE4 is actually the winner with 18 more points in MotionMark 1.2 over AVX2 which was actually the worse performer.

You can't use those benchmarks for this because the js engine already specifically path-optimizes for different architectures (including AVX), and Skia does so too for canvas, so there won't be a difference in results if run on the same hardware aside from what is gained in the margins of surrounding code.

[back2themoon]

What about stability? Is it a concern or are there no issues?

I have used the AVX build in the past, in an old laptop (6th gen Intel mobile CPU, supporting AVX/AVX2).

It was working fine mostly but I was getting a few seemingly random crashes, almost certainly related to the AVX build.

Switching back to the standard release, solved them. Perhaps newer CPU's are less prone to stability issues?

[Moonchild]

What about stability? Is it a concern or are there no issues?

Stability isn't an issue. All compilers in use have mature support for AVX. (In fact, it may even improve a little as using AVX is markedly less complex than the many flavours of SSE.)

[athenian200]

What about stability? Is it a concern or are there no issues?

I don't think we'd be moving forward with this if it were. I mean, obviously we want the browser to run faster, but we also don't want it to crash all the time. I assume we've done testing to make sure this works fine with AVX?

I would think a Kaby Lake/Skylake CPU would work fine with this, my much older Ivy Bridge machine does.

I'm curious if something could be wrong with the voltage regulation on your CPU that gets exposed when you use AVX? Like I am wondering if those issues could be reproduced on any Kaby Lake CPU or if something is going on with your hardware specifically that makes it less reliable... it was strange that Microsoft required Coffee Lake instead of Kaby Lake officially for Windows 11, because there aren't really any new instruction sets, normally they would let slightly older hardware work with a new Windows release, I'm wondering if 6th gen was botched in some way and there's a reason they're trying to get rid of it. They obviously wouldn't admit this if it were going on, but...

[Moonchild]

I'm curious if something could be wrong with the voltage regulation on your CPU that gets exposed when you use AVX?

AVX does tend to use a little bit more power for the increased performance, but that shouldn't be an issue. Since we're talking about older builds though, I'm wondering which builds those were, and who published them? Were they Nuck-TH builds or not?

[back2themoon]

I still use this laptop and they were Nuck-TH builds, yes. The first ones probably, since I tried it out shortly after those were made available in the forum.