On Wed, May 18, 2016 at 8:32 PM, Benjamin Smedberg <benja...@smedbergs.us> wrote: > Can we require SSE2 for Mozilla builds of Firefox for Linux? Yes, I am > comfortable making that decision today.
Thank you! I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1274196 for this. > Should we also take actions that prevent anyone from supporting non-SSE2 > codepaths? I don't know. There seem to be at least a few cases that this > affects: > > Rust and its support for non-SSE2 arches > > This seems to be both about build-time targeting and runtime dynamic > selection. I don't personally understand the cost/benefit tradeoff here. There are two levels of complication with run-time selection: 1) Since inline asm isn't allowed in stable-channel Rust, executing the cpuid instruction must be done in some other way, which leads either to having to make the crate (that could otherwise be a standalone Rust library) depend on Gecko's existing CPU sniffing infrastructure or to having to link some ad hoc cpuid-execution non-Rust object to the crate that could otherwise be a simple pure-Rust crate. 2) Since LLVM and, by extension, rustc currently require the compiler instruction set targeting options to be the same throughout the compilation unit, if the main crate is compiled without SSE2 to cater for the non-SSE2 case, the SSE2-enabled versions of functions need to be put in a separate crate, which is considerably less nice than what rustc lets you do if you want to supply SSE2 and ALU-only alternatives for a function such that the selection is done at compile time. In particular, if you want to avoid having two copies of SSE2 code, one in the main crate for build-time selection and the other in the SSE2-only helper crate, you have to put the single copy in the helper crate, which means that the preferred case (SSE2 enabled at build time) is made more complex, too. The problem with build-time selection is that the non-SSE2 target isn't the target that the Rust community tests the most actively. (Just like, evidently, Microsoft doesn't actively test the non-SSE target of MSVC.) > I imagine we'd like to remove this complexity from the tree, especially > given that we won't have any testing for it. I agree, though with C++, the complexity of having one function in a different compilation unit is more on the level of the general complexity of C++ whereas with Rust, the difference is more distinctive. On Wed, May 18, 2016 at 1:54 PM, Mike Hommey <m...@glandium.org> wrote: >> 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. If the code doesn't support run-time selection of SSE2 vs. non-SSE2 variants, Mozilla will build the SSE2 variants and a distro that wishes to support non-SSE2 would build the non-SSE2 code (unless the distro offers two packages: with SSE2 and without). > Also note that in practice, there *already* is a performance difference > between Mozilla-shipped Firefox and distro-shipped Firefox :-( > 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. See my reply to bsmedberg above for why I wouldn't want to take patches for run-time selection of SSE2 in Rust code. > Why specifically not welcome patches, instead of, say, making it > tier-3, like e.g. sparc or mips? MIPS vs. x86 is an app-wide compile-time choice that doesn't involve splitting crates. I'm against splitting crates for reasons that don't affect official builds, which is what *run-time* selection of SSE2 would do. Markus Stange wrote: > Wouldn't these code paths still be tested on Android? I expect we have many > code paths that have an SSE2 specialization but not an ARM NEON one, so we > use the non-SSE2 code paths on ARM. The Moz2D software filter code is an > example of such a case. *Compile-time*-selected ALU-only code paths would get tested on Android, yes. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
