Adding a linter for Fluent files

2021-02-09 Thread Daniel Minor
In Bug 1416149, hopefully landing soon, I'm adding a linter for Fluent
files. It checks for invalid strings, as is currently done by the
browser_misused_characters_in_strings.js test, and adds a new check to
enforce lowercase characters and hyphens in Fluent identifiers.

Since this is a newly written linter rather than an existing tool, it might
be a little rough around the edges. Please file a bug blocking Bug 1691747
if you encounter any problems. Suggestions for improvement are always
welcome as well :)

Dan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Gecko performance with newer x86_64 levels

2021-02-09 Thread Gian-Carlo Pascutto
On 3/02/2021 10:51, Henri Sivonen wrote:
> I came across 
> https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level/
> . Previously, when microbenchmarking Rust code that used count_ones()
> in an inner loop (can't recall what code this was), I noticed 4x
> runtime speed when compiling for target_cpu=nehalem and running on a
> much later CPU.

That's an extreme edge case though. count_ones() literally maps to POPCNT.

> I'm wondering:
> 
> Have we done benchmark comparisons with libxul compiled for the
> newly-defined x86_64 levels?

No. Should be easy to do, but I don't expect much to come off of it. The
main change (that is broadly applicable, unlike POPCNT) in recent years
would be AVX. Do we have much floating point code in critical paths? I
was wondering about the JS' engine usage of double for value storage -
but it's what comes out of the JIT that matters, right?

Media codecs don't count - they should detect at runtime. Same applies
to crypto code, that - I really hope - would be using runtime detection
for their SIMD implementations or even hardware AES/SHA routines.

> For macOS and Android, do we actively track the baseline CPU age that
> Firefox-compatible OS versions run on and adjust the compiler options
> accordingly when we drop compatibility for older OS versions?

Android only recently added 64-bit builds, and 32-bit would be limited
to ARMv7-A. There used to be people on non-NEON devices, but those are
probably gone by now. Google says "For NDK r21 and newer Neon is enabled
by default for all API levels." - note that should be the NDK used for
64-bit builds.

So it's possible Android could now assume NEON even on 32-bit, if it
isn't already. Most of the code that cares (i.e. media) will already be
doing runtime detection though.

For macOS Apple Silicon is a hard break. For macOS on x86, I guess AVX
is also breaking point. There was an open question if any non-AVX
hardware is still supported on Big Sur because Rosetta doesn't support
AVX code, but given that we support (much) older macOS releases I don't
think we can assume AVX presence regardless. We support back to macOS
10.12, which runs on "MacBook Late 2009", which was a Core 2 Duo. Guess
we could assume SSSE3 but nothing more.

-- 
GCP
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform