1485557 - Investigate why using Rust for XPCOM string encoding conversions regressed perf on 32-bit x86 Linux

Status: RESOLVED WORKSFORME

(Firefox Build System :: General, defect)

Description

[Henri Sivonen (:hsivonen)]

See bug 1402247 comment 207 and bug 1402247 comment 208.

Switching XPCOM string encoding conversions from C++ (plus SIMD intrinsics) to Rust (plus portable SIMD and SIMD intrinsics) was a clear perf win on x86_64 (Linux, Mac and Windows) and on 32-bit Windows but a clear perf regression on 32-bit x86 Linux.

This is very suspicious considering that 1) SSE2 should be fast also when executing 32-bit code on a 64-bit CPU (AFAIK, we run gtest on a 64-bit CPU on AWS) and 2) rustc should compile code the same on Windows & Linux and 32-bit Windows got better.

A quick build system code inspection suggests we build 32-bit x86 Linux with --enable-rust-simd as intended.

 1) Do we have some kind of build system bug that we don't actually enable SIMD for encoding_rs in the 32-bit x86 Linux case even though it looks like we are compiling with --enable-rust-simd?

 2) Does LLVM have a significant problem on 32-bit x86 and we see it relative to GCC (Linux) but obviously not relative to clang (Windows)? (We still build with GCC on Linux in automation, right?)

Comment 1

[Mike Hommey [:glandium]]

> (We still build with GCC on Linux in automation, right?)

Depends what builds, and when. Non PGO builds have been on clang since bug 1480631.

Comment 2

[Henri Sivonen (:hsivonen)]

(In reply to Mike Hommey [:glandium] from comment #1)
> > (We still build with GCC on Linux in automation, right?)
> 
> Depends what builds, and when. Non PGO builds have been on clang since bug
> 1480631.

So we switched Linux to clang 7 days ago.

https://treeherder.mozilla.org/perf.html#/compare?originalProject=mozilla-central&newProject=mozilla-central&newRevision=6cc53c0f6efec1c590a5b3a6c0019a26e11e6843&framework=6&filter=UTF&selectedTimeRange=7776000

compares the situation 2 days ago to aggregate data from 90 days prior. The linux32 entries don't say "pgo".

The first part of the series to switch string encoding conversions over to RUst landed 9 days ago, so we don't have data of builds with clang without any patches from the series that switched the string encoding conversions over to Rust.

Comment 3

[Mike Hommey [:glandium]]

Was it backed out? Because looking at the graph gives another picture: https://treeherder.mozilla.org/perf.html#/graphs?series=mozilla-central,1548897,1,6&highlightedRevisions=6cc53c0f6efe (note how the highlighted revision, which is the one on the right on your comparison, is alone with a high value)

Comment 4

[Mike Hommey [:glandium]]

inbound shows something similar, with a few peaks here and there.
https://treeherder.mozilla.org/perf.html#/graphs?series=mozilla-inbound,1548961,1,6

Comment 5

[Henri Sivonen (:hsivonen)]

It wasn't backed out. It's possible that I looked at an unlucky linux32 run.

Comment 6

[Mike Hommey [:glandium]]

It seems you have. I retriggered the gtest run on that one a few times, my guess is they will have more normal results.

Comment 7

[Henri Sivonen (:hsivonen)]

Those graphs are for IsUTF8(), which didn't change.

Comment 8

[Henri Sivonen (:hsivonen)]

But yeah, it still looks like I got an unlucky run:
https://treeherder.mozilla.org/perf.html#/graphs?highlightedRevisions=6cc53c0f6efe&series=%5B%22mozilla-central%22,%22818c1c464322b5e50bbf2ce4b4d36f2238734ce7%22,1,6%5D&timerange=7776000

Comment 9

[Mike Hommey [:glandium]]

They are for PerfIsUTF8Example3, which is the first that appears in your link from comment 2.

Comment 10

[Henri Sivonen (:hsivonen)]

https://treeherder.mozilla.org/perf.html#/compare?originalProject=mozilla-central&newProject=mozilla-central&newRevision=338526a05458&framework=6&filter=UTF&selectedTimeRange=7776000 looks OK.

Thanks.

(In reply to Mike Hommey [:glandium] from comment #9)
> They are for PerfIsUTF8Example3, which is the first that appears in your
> link from comment 2.

I don't have a filter that would trim the list precisely to exclude the IsUTF8() benchmarks.