On Wed, Feb 3, 2016 at 4:58 PM, Chris H-C <chut...@mozilla.com> wrote: > So I reran the analysis, this time breaking down by OS the users who we > can't say for certain have SSE2: > https://gist.github.com/chutten/e4ccd0d5a46b782bae53 > > This was on a 25% sample of users reporting in from release Firefox on Jan > 21. > > The tl;dr is that it's mostly WinXP. So much so that it's almost correct to > say that it's _only_ WinXP.
Thank you. It looks like this will be yet another way for XP to be a time sink. :-( (I'm all for user retention, but when it comes to doing XP-specific engineering, one has to wonder if more forward-looking efforts would be a better use of limited resources.) On Wed, Feb 3, 2016 at 7:41 PM, Ralph Giles <gi...@mozilla.com> wrote: > On Wed, Feb 3, 2016 at 5:23 AM, Henri Sivonen <hsivo...@hsivonen.fi> wrote: > >> My understanding is that the new >> MP4 demuxer that's written in Rust is currently only being built in >> the x86_64 case, so, AFAICT (I'd love to be wrong!), Rust code in >> 32-bit Firefox isn't a solved problem yet. > > We're actually building it for 32-bit MacOS X too, but all x86 macs have SSE2. Is there a plan for adding Android builds and 32-bit Windows and Linux builds? >> As for the consequences of requiring SSE2 unconditionally, I'm >> personally more worried about a conflict with Linux distros that don't >> already require SSE2 > > Do you know if rust's unwind will catch illegal instructions? I don't. > The mp4 > demuxer code currently runs in an isolation thead so panics don't > affect the firefox process. So I'm wondering if we could enable this > for linux32 with telemetry to get a measurement outside crash reports. To be clear, I'm less worried about Linux users having non-SSE2 hardware (chutten's numbers suggest we don't need to worry about that) than I am about violating Linux distros' policies (that may be out of date relative to hardware reality). That is, a policy violation might result in drama even if the violation didn't affect a notable user population in practice. On Wed, Feb 3, 2016 at 9:23 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote: > Can't we build one file with target-features=-sse2 and one with > target-features=+sse2? If the two Rust crates see each other through the C ABI, yes (with s/file/crate/, since the compilation unit in Rust is a crate and not a file). AFAICT, using Rust linkage, no, due to the limitations of the Rust integration into the Firefox build system. (That's a problem for other reasons, too. I'll start a new thread about cross-crate Rust linkage in Gecko.) On Thu, Feb 4, 2016 at 12:17 AM, Mike Hommey <m...@glandium.org> wrote: > GCC has a target __attribute__ that allows to selectively enable e.g. > SSE per function (which, btw, we could use for C++ instead of using > separate sources built with different flags, although I don't know if > clang or MSVC support the same thing or similar). > Rust could (should) grow something similar. According to https://users.rust-lang.org/t/is-there-a-way-to-set-per-function-compiler-options/4524/5 , rustc is blocked on LLVM developing the back end functionality. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
