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

Don't multiversion on 32bit #308

Merged
merged 3 commits into from
Jun 20, 2023
Merged

Conversation

gbaraldi
Copy link
Member

We run out of memory when multiversioning on 32 bit. Target only sandybridge which should be a reasonable default anyway.

# Add sandybridge level similar to x86_64 above
"sandybridge,-xsaveopt,clone_all"
# Target only sandybridge because we run out of memory when multiversioning
"sandybridge"
Copy link
Member

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.

Copy link
Member

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.

Copy link
Member Author

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?

Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@staticfloat
Copy link
Member

I've adjusted to only pentium4, with a descriptive comment.

@staticfloat staticfloat added the automerge Kodiak will auto-merge this PR once all CI is green. (This label was previously called "merge me".) label Jun 20, 2023
@staticfloat staticfloat merged commit 3e412d4 into JuliaCI:main Jun 20, 2023
@DilumAluthge DilumAluthge removed the automerge Kodiak will auto-merge this PR once all CI is green. (This label was previously called "merge me".) label Mar 10, 2024
stemann added a commit to stemann/PackageCompiler.jl that referenced this pull request Jun 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants