Add loongarch64-unknown-linux-gnu as a target

[heiher]

No description provided.

[Kobzol]

Hi, could you please describe the motivation for this PR? I'm fine with perf usage changes to allow running rustc-perf on this architecture, if needed. But adding a new target to the Target enum and changing the website shouldn't be necessary, that's only useful for production usage.

[heiher]

Hi, could you please describe the motivation for this PR? I'm fine with perf usage changes to allow running rustc-perf on this architecture, if needed. But adding a new target to the Target enum and changing the website shouldn't be necessary, that's only useful for production usage.

Thank you for the review. We are focusing on two main goals: extending the collector's support to LoongArch for performance samping, and building a community-facing site to visualize rustc/loongarch perf results. These site-side changes are necessary to provide the data display required for non-x86 targets.

[Kobzol]

These site-side changes are necessary to provide the data display required for non-x86 targets.

Hmm, I mean, sure, technically yes, but where will we get that data? Currently, we do not have any plans to run Loongaarch benchmarks on CI. It took us more than a year to prepare the system for any non-x86 websites at all, and currently we're in the process of adding Aarch64 benchmarks, but that will take some time, and involves non-trivial infra maintenance involved.

Or do you want to deploy the website and run the benchmarks yourself?

Adding the target to the graph page and other endpoints is something we'd like to do eventually too, so I'm happy to review that (ideally as a separate PR).

[heiher]

Hmm, I mean, sure, technically yes, but where will we get that data? Currently, we do not have any plans to run Loongaarch benchmarks on CI. It took us more than a year to prepare the system for any non-x86 websites at all, and currently we're in the process of adding Aarch64 benchmarks, but that will take some time, and involves non-trivial infra maintenance involved.

Or do you want to deploy the website and run the benchmarks yourself?

Yes, that's correct. We plan to self-host a Rustc performance tracking site specifically for LoongArch. We will be running upstream nightly builds on our own CI infrastructure to collect the data.

Adding the target to the graph page and other endpoints is something we'd like to do eventually too, so I'm happy to review that (ideally as a separate PR).

​While we could maintain a fork to include these changes, staying aligned with upstream is much easier to maintain. Furthermore, these changes should benefit all non-tier 1 targets, which I believe aligns well with the project's goals. I would be happy to split this out into a separate PR. Thanks!

[Kobzol]

I see. Well, I guess that adding another Target enum is not an issue. However, I don't want to add UI (checkboxes, links, etc.) for targets that we do not run on our CI, that would be confusing. Maybe the set of UI supported targets could be configurable at build time, if it's doable without a lot of complexity.

Adding support for supporting targets on the backend and showing their data through specially crafted links should be fine though.

Adding the target to the graphs page and the 30 day graph detail section in the compare page would be a good start for a separate PR.

[heiher]

I don't want to add UI (checkboxes, links, etc.) for targets that we do not run on our CI, that would be confusing.

The UI part has been dropped. Thanks!

[Kobzol]

I'm fine with the perf counter change, but I don't want to merge this until a proper release of perf-event is made.

[heiher]

I'm fine with the perf counter change, but I don't want to merge this until a proper release of perf-event is made.

The latest release of the perf-event crate was three years ago, and the project appears to have a prolonged maintenance cycle, with a pending release request from six months ago yet to be addressed.

To ensure our development remains unblocked, would it be acceptable to temporarily point to the git version and switch back once a new formal release is available on crates.io? Thanks!

[Kobzol]

I'll try contacting Jim to ask if there's something to be done there. If that doesn't work, I'd rather switch to a fork of perf-event, e.g. perf-event2.

[Kobzol]

Apart from the perf-event changes, #2384, #2385 improve our support for custom targets. Later we will modify the frontend to avoid hardcoding any targets and load them dynamically from the DB. Then most of this PR shouldn't be needed anymore.