Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explore MUSL to avoid GLIBC requirement #138

Open
sunchao opened this issue Feb 29, 2024 · 6 comments
Open

Explore MUSL to avoid GLIBC requirement #138

sunchao opened this issue Feb 29, 2024 · 6 comments
Labels
build Build environment enhancement New feature or request

Comments

@sunchao
Copy link
Member

sunchao commented Feb 29, 2024

What is the problem the feature request solves?

Currently we require dynamically linked glibc on the host machine which isn't desirable since it requires certain version of glibc, otherwise the native Comet lib won't be able to load. In particular, the glibc version used to compile and build Comet must be compatible (i.e., older) than the version used to execute Comet.

Another option is to explore x86_64-unknown-linux-musl compile target, which statically links against the MUSL libc and can effectively remove the above constraints. However, there are some reports that MUSL can cause performance degradation, see here and here. We may need to do some benchmark to evaluate.

Describe the potential solution

Evaluate MUSL and check if it can be a potential candidate to co-exist (or replace) with the current GLIBC approach.

Additional context

No response

@sunchao sunchao added enhancement New feature or request build Build environment labels Feb 29, 2024
@advancedxy
Copy link
Contributor

In particular, the glibc version used to compile and build Comet must be compatible (i.e., older) than the version used to execute Comet.

In the native world, it usually implies to build and release the dynamic lib on a decent old enough Linux distro. In that way, the built lib could be executed on newer Linux hosts. That' pretty much the simplest way to archive compatibility. And maybe we can reuse rustc's docker image to target lower glibc: https://github.com/rust-lang/rust/blob/master/src/ci/docker/host-x86_64/dist-x86_64-linux/Dockerfile

@snmvaughan
Copy link
Contributor

I tend to agree with using a lower target glibc for compatibility.

If we want to consider MUSL we should also plan on benchmarking different combinations of target (glibc vs musl) and alloc (jemalloc vs system alloc) using a benchmark like TPC-DS.

@sunchao
Copy link
Member Author

sunchao commented Mar 1, 2024

Yes, this ticket belongs to the "good to have" category IMO. One disadvantage of having to stick to the lowest common denominator for GLIBC is that certain crates may not able to compile. For instance, we ran into issues with mimalloc when building on GLIBC 2.17 IIRC.

@andygrove
Copy link
Member

This recent blog post is worth a read. It talks about some performance issues with musl's default allocator and how switching to jemalloc helps.

https://blog.sdf.com/p/fast-development-in-rust-part-one

@viirya
Copy link
Member

viirya commented Mar 23, 2024

I remember we used jemalloc at the beginning, but we encountered some libraries issues from it and switched it back.

@advancedxy
Copy link
Contributor

hhhm, I recently know there's a project called https://github.com/rust-cross/cargo-zigbuild which is able to cross compile rust project to different target including various glibc versions by using zig as a linker. I think we can explore this option to cross compile to low version glibc.

Ref: https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html see the glibc part.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build Build environment enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants