What optimization level should I use for Epyrus?

[athenian200]

Since it's clearer now that the decision will, in fact, be left up to me and I won't be able to just shrug and say "MC changed the platform defaults and I was too lazy to override his AVX flag," as an excuse for dropping older hardware... I guess that means I should make a decision here.

However, something kind of embarrassing has actually come to light now that I started thinking about this. The truth is, I had no idea what optimizations I am currently using for Epyrus in the first place until just now, aside from basic -O2 optimizations. It just wasn't something I thought about when I created Epyrus, because I figured it didn't really need optimization very much, being little more than an old-school mail client that could probably run on a toaster...

I believe MSVC itself defaults to SSE2 as a baseline for x86_64 due to that being part of the x86_64 ISA, but I never told the compiler I wanted SSE2 optimizations on the 32-bit version. I think I seem to vaguely recall that -O2 implies SSE2 is okay on 32-bit indirectly? Been a while since I looked at this stuff.

Anyway, let me give you a quick primer on x86_64 architecture levels, and where AVX/AVX2 falls into them...

x86_64.png

https://en.wikipedia.org/wiki/X86-64#Mi ... ure_levels

If you look at the definition for x86-64-v1, you see that's the current architecture level everything supports right now, which tops out at SSE2 and goes all the way back to the Athlon 64, supporting every AMD64/x86_64 machine ever made. Most Linux distros currently target x86-64-v2, which stops just short of supporting AVX, with stuff like SSSE3 and SSE4.2 as the baseline. As far as I know, no UXP application has ever bothered targeting this level, so it was effectively skipped over.

Now, the big controversy going on with AVX is basically about whether it makes sense to venture into the x86-64-v3 space at all, going past the "red line" marked out by Intel and AMD as demarcating the safe x86-64-v2 zone at the SSSE3 level. If I were to take the spec at its face, dipping into AVX at all implies I have to support AVX2 as well, and make Haswell the baseline. However, what the spec doesn't seem designed to acknowledge, is that there are a ton of processors that support more than x86-64-v2, but less than x86-64-v3. This spec is why Intel has so many newer processors that simply don't support AVX at all... they were targeting the v2 ISA, and v2 doesn't call for AVX, so they don't need to support it if they sell it as v2. And it's up to the software to avoid using anything that goes past the red line they defined here if they don't want random underpowered systems complaining. Oh, and v4? Just... pretend it doesn't exist, it's a long story.

So, you see the document above talks about Intel Nehalem (1st gen Core i7), as the baseline for v2. It talks about Intel Haswell (4th gen Core i7) as the baseline for v3. So, given that this is how the spec was written, why is anyone talking about support AVX without AVX2, did anything ever actually use that? Well, actually... yes, and I have the perfect example sitting in front of me right now.

Ivy Bridge was 3rd gen Intel Core architecture, and it supports AVX, OSXSAVE, and F16C... but doesn't have AVX2, BMI1, BMI2, FMA, LZCNT, or MOVBE. In other words, it supports a useful subset of x86-64-v3, but not the whole thing. Many other systems are in that boat, that were manufactured long before this spec was written which said it was invalid to target anything between Nehalem and Haswell.

Why it this relevant? Well, it will become clearer when I start talking about what optimization levels MSVC as a compiler supports...

MSVC does not properly support targeting v2, because the optimization levels are older than the spec I just linked. It only supports SSE2, which is equivalent to v1 and is the default... or, it also supports AVX, which is roughly equivalent to the subset of v3 that Sandy Bridge targets. Targeting AVX2 is roughly on par with targeting v3 here, in terms of performance.

So, even though only v1, v2, and v3 matter officially... MSVC targets an unofficial v2.1 for Sandy Bridge processors that presumably adds AVX and OSXSAVE but doesn't support the rest of v3.

With all that said... I am going to give the community a few options here for deciding how I move forward with this.

Option 1: x86-64-v1

This option sticks with the current level of optimization for Epyrus, and nothing changes. Pretty much SSE2.

Option 2: x86-64-v2

This option would be a lot safer for Linux in particular, since most Linux distros popular among our userbase target this level. However, it wouldn't yield a big performance gain, and would be harder to target on MSVC.

Option 3: x86-64v2 plus AVX

This option would be much easier to target on MSVC, and has a chance of yielding a reasonable increase in performance.

Option 4: x86-64-v3

This is the bleeding edge option, it's what RHEL 10 and Ubuntu are planning to use as their baseline after 2025. Will leave users on older hardware behind, even some of my hardware will not work with this option... but if people want it, that is a sacrifice I am willing to make, I probably needed to upgrade my non-development bedroom PC anyway.

[Moonchild]

I believe MSVC itself defaults to SSE2 as a baseline for x86_64 due to that being part of the x86_64 ISA, but I never told the compiler I wanted SSE2 optimizations on the 32-bit version. I think I seem to vaguely recall that -O2 implies SSE2 is okay on 32-bit indirectly? Been a while since I looked at this stuff.

MSVC implies SSE2 for x86_64 because it's part of every x86_64 instruction set.
It also defaults to SSE2 for x86 since I believe VS2015; still allows overriding with IA32 if necessary (which I assume is i686 level) but if not explicitly specified it'll use SSE2.

[Southern_Computer_Geek]

Considering Epyrus is an email client, do you think any further optimization would be beneficial enough to be worth potential incompatibility with some users' existing machines? Of course it's up to you; I just believe this is worth thinking about.

[athenian200]

Considering Epyrus is an email client, do you think any further optimization would be beneficial enough to be worth potential incompatibility with some users' existing machines? Of course it's up to you; I just believe this is worth thinking about.

Well, the 32-bit version of Epyrus will continue to work fine on Windows. I believe the average Epyrus user can get away with a 32-bit fallback, because e-mail clients have the benefit of not having to load bloated websites full of badly-written JavaScript and WebComponents that leak memory like a sieve. MC suggested that for Pale Moon, and it's a great solution for RAM-starved older systems that should really be running the 32-bit version anyway, like if they have less than 8GB... and it's also perfect for Epyrus since it doesn't use much RAM.

I have personally never seen Epyrus consume more than 1GB of RAM, so the 32-bit version is still actually extremely viable as an option.

Really, the main sticking point is Linux, because their policy has been to follow Intel's spec and avoid AVX like the plague until everything is ready for v3 to be the standard. That's the reason why I've been tempted to just go AVX with the 64-bit version on Windows, provide the 32-bit version as a fallback, but possibly do x86-64-v2 for my Linux build, simply because Linux distros tend to be a lot stricter about sticking to Intel's v1/v2/v3 paradigm and frown on software going outside of that and targeting specific CPUs or vendors. That said, there's no reason to stick to v1 for Linux simply because most popular distros already target v2.

I am tempted to just try doing a 32-bit Linux build for parity with Windows (Pale Moon killed off 32-bit Linux officially, but since I'm independent I technically don't have to go along with that), and then tell people that if their distro doesn't support multilib and they're on ancient 64-bit hardware, they're on their own... they can either use Windows, use a distro with decent multilib support, or upgrade their computer.

The thing about Linux users is, if you give them an inch, they will take a mile. You give them a GTK2 version and a 32-bit version? They'll ask where the Wayland version is, ask why you don't support Qt, ask where the Bionic or uClibc version is because they don't like glibc, where the AVX2 version is, where the SSE version for their old Pentium III is, etc... it would be easy to do 20 different builds just for Linux alone.

[Basilisk-Dev]

I almost never notice any slowdown when using Epyrus whereas I do notice slowdown in Pale Moon and Basilisk, especially in non-optimized builds of those two browsers.

Due to that, I wonder if it'd even be worth the time to do the optimizations in the first place. I feel like the benefit of the optimizations is less here than it is for Pale Moon and Basilisk. You'd be blocking potential users with what, at least from my perspective, is little benefit.

[athenian200]

I almost never notice any slowdown when using Epyrus whereas I do notice slowdown in Pale Moon and Basilisk, especially in non-optimized builds of those two browsers.

Due to that, I wonder if it'd even be worth the time to do the optimizations in the first place. I feel like the benefit of the optimizations is less here than it is for Pale Moon and Basilisk. You'd be blocking potential users with what, at least from my perspective, is little benefit.

That's a very good point.

Yeah, at the very least, I'm questioning whether going full AVX is worth it, given that Intel often targeted the v2 ISA up until fairly recently with some of their netbooks. The v2 ISA is basically the new 32-bit... which basically means it should be safe to drop v1 and go for v2, but I am definitely not sure if I can get away with AVX, and think AVX will more negatively impact Linux users because Linux distros, from what I gather, are really not setup for AVX and want people to hold off on that until v3 is baseline.

So there's still a very real possibility I will try to figure out how to do v2 for the old Intel laptops, but stop short of AVX, depending on how the poll goes. I don't think I have many Epyrus users on v1 hardware, but I'll see...

[athenian200]

So here's the basic problem, explained in a little table...

compilertable.png

Like, it's a slight exaggeration when I say it's "not possible," but you have to do things in really weird, undocumented ways to get them to work...

For example, if I want to optimize for AVX with GCC, I might have to do something like -march=sandybridge or -march=bdver1 which would target a specific CPU and include some instructions I don't want. And if I want to optimize for v2 with MSVC, I might have to use something like /d2archSSE42, which is a weird undocumented flag and may not work reliably.

That is to say, it's just not as clear what the right way to target v2 with MSVC is, nor is it clear what the right way to tell GCC to target v2 but add AVX on top would be. It's possible I could list out every instruction set I want it to use individually, which would be a bit tedious initially but once I got the mozconfig ready it wouldn't be a big deal.

[Moonchild]

afaik, v2+AVX can be achieved on gcc by indicating -march=x86-64-v2 -mavx.
-mavx will have gcc "depress SSEx instructions when -mavx is used. Instead, it generates new AVX instructions or AVX equivalence for all SSEx instructions when needed." so that will achieve the wanted result. -mavx acts a little different than most other -m flags because it will replace equivalent SSE instructions.

[Basilisk-Dev]

afaik, v2+AVX can be achieved on gcc by indicating -march=x86-64-v2 -mavx.

I just did two test builds of Basilisk, one with just x86-64-v2 and one with x86-64-v2 and AVX using the compiler flags you posted. Using your provided flags seems to produce the desired result.

I tested the AVX+x86-64-v2 build on an old pre-AVX 64-bit capable ThinkPad I have sitting around, the build didn't run. The AVX+x86-64-v2 build did run on my newer hardware and it seemed more performant than just an x86-64-v2 build.

[back2themoon]

Voted x86-64-v2, but changed my mind for x86-64-v1. Seems it cannot be edited.

[athenian200]

Voted x86-64-v2, but changed my mind for x86-64-v1. Seems it cannot be edited.

I didn't think to make it editable, sorry.

Anyway, with that as a mental note, I am thinking the highest level I can justify is likely v2, and even that is a bit controversial. AVX is basically out of the running for Epyrus based on community reaction so far. Almost no one is for AVX2, and v2 is in the middle of the three-way tie here.

[distantpluto]

Option 1: x86-64-v1. As has been said, why rock the boat for no benefit? It's an email client

I'm ignorant of this stuff really, I just do BASH scripting these days but the default build flags on Arch Linux use "-march=x86-64"

The only time I change this is for building Pale Moon and I use '-march=znver3' for my 5950x. Saying that I can't say I can notice any difference!

[Moonchild]

As has been said, why rock the boat for no benefit?

Maybe I should compile an AVX one myself and see with my heavy use if there really is "no benefit" for Epyrus with my pretty heavy use of it. (Unless athenian is willing to toss me a build so I don't have to figure out the build env first )

[Bilbo47]

Maybe I should compile one myself ... (Unless athenian is willing to toss me a build so I don't have to figure out the build env )

Wait no, everyone should know how to build their open-source wares. Silliness aside, it's called 'bus insurance' to spread the crucial knowledge around.

[athenian200]

Maybe I should compile an AVX one myself and see with my heavy use if there really is "no benefit" for Epyrus with my pretty heavy use of it. (Unless athenian is willing to toss me a build so I don't have to figure out the build env first )

Well, I can easily do an AVX build for testing (in fact I'm firing one up as we speak), but if you're interested at all in building Epyrus, I think you'll be surprised by how familiar the build process is...

http://www.epyrus.org/build.html

It's intentionally as similar to the Pale Moon build process as possible, and uses essentially a Pale Moon build setup that's only modified in terms of requiring MAPI headers and an extra flag to enable the calendar. It doesn't do things "the BinOC way," you know what I mean? Where you had to have a weird-looking "super mozconfig" and all that? None of that is a thing here, you can just use a plain old .mozconfig not that different from what Pale Moon uses.

The biggest sticking point is the MAPI headers really... Microsoft tends to move those around, and finding a copy is always a pain, it's always inconsistent whether the Windows SDK includes it or not, etc. Other than that, once you have those headers, it's really easy.

[athenian200]

I have an AVX build of the current Epyrus version up here, if anyone wants to try it...

https://www.addons.epyrus.org/download/ ... n64-avx.7z

[Bilbo47]

AVX build of current Epyrus

Wow I like that! Seems more snappy - MUCH much faster than BetterBird with its useless animations. Can tell even more the difference between slow and fast mail servers.

[Moonchild]

I have an AVX build of the current Epyrus version up here, if anyone wants to try it...

Definitely more responsive. Switching mailboxes is almost instant; enigmail decryption also seems to be noticeably faster.
So the "for no benefit" has clearly been disproven.

[RuudNL]

I'd vote for AVX2, if I knew how to

[Moonchild]

I'd vote for AVX2, if I knew how to

Voting has closed for this, I think.