-
Notifications
You must be signed in to change notification settings - Fork 15
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
Don't multiversion on 32bit #308
Conversation
utilities/build_envs.sh
Outdated
# Add sandybridge level similar to x86_64 above | ||
"sandybridge,-xsaveopt,clone_all" | ||
# Target only sandybridge because we run out of memory when multiversioning | ||
"sandybridge" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uhm... I think technically we must support pentium4.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or it would at least be a bigger decision than I thought.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why must we support it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with Valentin. Unless we're willing to officially deprecate things, we must error on the side of caution. Let's throw away sandbridge
and keep pentium4
for now, until we decide to jump the gun to sandybridge. For the record, sandybridge was released "only" 12 years ago, so it's not outside of the realm of possibility that computers built 10 years ago had pre-sandybridge chipsets.
I have an alternative idea on how to help this; I don't think it's multiversioning that's crashing, I think it's LLVM image generation, which we're multithreading by default. I'll try limiting that to one thread and seeing if it helps.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We already don't multithread, not multiversioning does solve it for me, so it does affect stuff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We already don't multithread
What makes you say that? It looks to me like we set JULIA_IMAGE_THREADS
to JULIA_CPU_THREADS
unconditionally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm sure not multiversioning does help, as it decreases the amount of code we have to link at the end significantly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, but IIRC the Julia code has a 32 bit define for this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was unaware of this, you're correct: https://github.com/JuliaLang/julia/blob/a8ef87369749abc16e334014108f3080b76ab507/src/aotcompile.cpp#L1407-L1410
I've adjusted to only |
We run out of memory when multiversioning on 32 bit. Target only sandybridge which should be a reasonable default anyway.