search

sagemath / sage

Main repository of SageMath
https://www.sagemath.org
Other
1.39k stars 473 forks source link

Rename configure option --enable-fat-binary to --enable-portable-binary #32363

Open culler opened 3 years ago

culler commented 3 years ago

As far as I can tell this configuration flag affects only the gmp and givaro packages. There are two problems that I have run into with it.

  1. It is misnamed. What Apple means by a "fat binary" is a single mach-O file containing multiple binaries for different CPU architectures. That is not what this flag produces. The name was probably derived from the gmp configure flag --enable-fat, which is used when SAGE_FAT_BINARY is yes. That gmp flag causes gmp to include assembly language modules for all possible Intel variants, and to add code that selects which of those modules to use at run time.

  2. It does the wrong thing for givaro. Currently in the givaro package it disables all intel extensions (the opposite of making it "fat") by setting the configure flags: -mno-sse, -mno-sse2, -mno-avx, -mno-avx2, and -mno-bmi2. But sse and sse2 should not be disabled, at least not on macOS. All of the relevent Intel chips used by Apple support those instruction sets. (And conda does not disable them, by the way.) Sage will not build on Apple systems with older Intel chips for other reasons.

A better name might be ENABLE_INTEL_COMPATIBILITY.

CC: @kliem @jhpalmieri

Component: build: configure

Issue created by migration from https://trac.sagemath.org/ticket/32363

mkoeppe commented 3 years ago
comment:1

Yes, it's misnamed.

mkoeppe commented 3 years ago
comment:2

As (I think) this is not specific to intel architectures, we could rename the configure option --enable-fat-binary (introduced in #30375) to something like --enable-portable-binary.

numpy >= 1.20 has a more fine-grained flag for its use of processor intrinsics, something that we may want to emulate; see #32021

culler commented 3 years ago
comment:3

Possibly the sense should also be inverted, meaning that maximum portability would be the default while optimizing for a specific CPU type would require additional configuration flags. Perhaps a flag like --optimize-for-native-cpu would make sense for people who are building sage themselves for their personal use.

mkoeppe commented 3 years ago
comment:4

Replying to @culler:

Possibly the sense should also be inverted, meaning that maximum portability would be the default while optimizing for a specific CPU type would require additional configuration flags.

-1 on this. Building a portable binary is clearly a more specialized use case than building an optimized binary.

kliem commented 3 years ago
comment:5

-1

Non-portable build appears to be the standard use case, when compiling something yourself from source.

kliem commented 3 years ago
comment:6

I agree that the name --enable-fat-binary is confusing and incorrect.