On Wed, May 18, 2016 at 11:10:30AM +0300, Henri Sivonen wrote: > On Mon, May 16, 2016 at 8:53 PM, Benjamin Smedberg > <benja...@smedbergs.us> wrote: > > On Mon, May 16, 2016 at 8:47 AM, Henri Sivonen <hsivo...@hsivonen.fi> wrote: > >> For clarification: Does this decision apply to 32-bit x86 Linux as > >> well? (It would be sad to have to supply and maintain non-SSE2 x86 > >> code paths just for Linux.) > > > > Nobody asked about that, so it's wasn't specifically included. > ... > > so the real question here is whether we want > > to support distros that don't require SSE2? > > So we now require SSE2 on > * All x86_64 (since SSE2 is part of the x86_64 baseline) > * 32-bit x86 Mac, which means just the plugin-container now that we > no longer support 10.6, which was the last OS X version that ran on > 32-bit hardware. > * 32-bit x86 Windows. > > It seems that we are almost ready to require SSE2 for Mozilla-built > Firefox for 32-bit x86 Linux. > > What do we need to do to reach a decision on that? > > That leaves Linux distro-shipped Firefox and *BSD ports. > > The combination of the lack of function-level instruction set options > in LLVM and the inconvenience of per-function compilation units in > Rust probably would naturally make *run-time* selection of SSE2 vs. > non-SSE2 a "patches not even welcome" kind of thing. (At least until > LLVM and then rustc get per-function instruction set options.) > > What do we need to do to reach a decision that it's indeed OK to treat > *run-time* selection of SSE2 vs. non-SSE2 especially in Rust code as a > "patches not even welcome" kind of thing, considering that this may > lead to Linux distros shipping an 32-bit x86 "Firefox" with degraded > performance relative to Mozilla-shipped 32-bit x86 Firefox?
This paragraph doesn't make sense to me. That is, I don't see the relationship between "patches not even welcome" and degraded performance relative to Mozilla-shipped 32-bit x86 Firefox. Also note that in practice, there *already* is a performance difference between Mozilla-shipped Firefox and distro-shipped Firefox: most distros-shipped packages don't build with PGO. That might even count for more performance differences than building with/without SSE2 would make. (That would actually be an interesting thing to check with Talos) Now, with my Debian hat on, I can tell you with 100% certainty that angry Debian users *will* come with patches and will return even angrier if patches are not even welcome. That said, Talos could tell something different, but I'm not convinced building with SSE2 would make a huge difference. Things where it does make huge differences are already using run-time selected SSE2 code. And even if it does make huge differences, I'm tempted to say "so what"? So, if people want to build the same way as currently, even if Mozilla and most distros end up defaulting to SSE2, why prevent them from doing so? Why specifically not welcome patches, instead of, say, making it tier-3, like e.g. sparc or mips? Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
