-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Unleash performance potential from compiler build process #12060
Labels
Comments
We should revisit this after 1.8 is released and see if LLVM15 resolves it. EDIT: And/or if there is still a perf difference between a locally built compiler versus the pre-bilt one. |
i think this is fixed:
local version still faster, but not 2 times now. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It has been discovered that different builds of the compiler shows huge differences in performance levels. At this point the influencing factors are not exactly clear however. This issue is supposed to coordinate investigations and propose guidelines for best performing builds.
The first mentions of the effect that a locally built compilers can perform much better (50% time) than the generic build was summarized in crystal-lang/distribution-scripts#147 (comment)
The compiler builds produced by 84codes at https://github.com/84codes/crystal-container-images/blob/b4bf7e48bc48ef9276959420fee7aefcf73a881b/alpine/Dockerfile have reportedly shown a 30% performance improvement over the builds from https://github.com/crystal-lang/distribution-scripts/blob/ce8ae2727f540b07d421b97fed71b0e5f262708c/linux/Dockerfile
Upgraded versions of the LLVM library may haven an effect, but they do not seem to explain everything.
MUSL libc vs GNU libc may also be a factor, so does static vs. dynamic linking (reports suggest dynamic GNU > dynamic MUSL > static MUSL).
The text was updated successfully, but these errors were encountered: