Possible to only use musl binaries if glibc isn't available?

[sunshowers]

Hi Taiki --

Thanks for continuing to maintain this action :)

Noticed that f343021 switched nextest to using the musl binaries. Unfortunately, the musl build is currently quite a bit slower than the glibc build due to rust-lang/rust#99740. On the clap repo I observed a 2x slowdown going from glibc to musl. (There might be other perf regressions too esp around threading, haven't checked).

Would it be possible to only install the musl binary if glibc isn't available? I'm not sure how hard that would be.

[NobodyXu]

It definitely is possible by checking output of rustc -vV (cargo-binstall already does this).

Refarding the slowdown, it is likely the memory allocator of musl being too slow.
I read somewhere that if the binary is built with musl libc with mimalloc, then it is even faster than glibc with mimalloc.

[sunshowers]

In this case the slowdown is definitely due to that Rust bug I linked above. It's quite possible that musl is faster once that is fixed in Rust upstream -- we'll have to wait though.

[NobodyXu]

@sunshowers Thanks, I missed that link.

In the meantime, you can try cargo-binstall since cargo-nextest already has support for it

[sunshowers]

Oh I'm the primary maintainer of nextest! It's just that most CI users use this action to install it and I'd like to make sure they're using the fastest version of it.

[taiki-e]

The reason for using musl by default is not only for compatibility with musl linux hosts, but also for compatibility with linux which uses the old glibc (For example, the mdbook linux-gnu binary is built on ubuntu 20.04 and is incompatible with ubuntu 18.04).

That said, as long as the prebuilt binary of nextest is compatible with ubuntu 18.04, I'm fine with doing this.

[sunshowers]

Yeah, we build nextest against Ubuntu 18.04 because of that glibc compat issue: https://github.com/nextest-rs/nextest/blob/d32a41310f400ed656a5d1fd96de8a819176fc09/.github/workflows/release.yml#L102-L103

[sunshowers]

Thanks so much!

[taiki-e]

Fixed in 1.8.0.

[taiki-e]

That said, as long as the prebuilt binary of nextest is compatible with ubuntu 18.04, I'm fine with doing this.

follow-up: I have implemented logic to detect the host glibc version (069858b), so we can support this regardless of the tool's glibc requirements. (although the various values are hard-coded in main.sh until generic logic to handle issues around glibc requirements is implemented)