Skip to content

arch-native defaults to True which is dangerous #308

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

Closed
TerrorJack opened this issue Jun 8, 2024 · 3 comments
Closed

arch-native defaults to True which is dangerous #308

TerrorJack opened this issue Jun 8, 2024 · 3 comments

Comments

@TerrorJack
Copy link

It's appreciated that the caveat of arch-native (creating non-portable binary due to -march=native) is documented and visible on the hackage page. But IMHO this is still dangerous, because downstream project authors may not audit all their dependency upgrades, and this looks incredibly likely to sneak into downstream build plans and making downstream CI pipelines produce binaries that crash at runtime on machines with CPUs older than GH action runners.

@phadej
Copy link
Contributor

phadej commented Jun 8, 2024

But if arch-native is not enabled by default, no-one would notice it. and that leaves quite significant performance boost on the table.

It's a trade-off, and in perfect world the whole tooling (Cabal, GHC etc) would support -march (with native as a choice, and I'd argue it should be default; Haskell is more often build for local stuff - the distribution use-case is more involved, and people usually know what they are doing). Then packages won't need to use package flags for that at all.

There are also plenty of packages on Hackage which have flags like sse4, and I honestly never look them nor enable them.

And GHC todays leaves a probably noticeable performacne on the table, e.g. if you have a code which uses popCount in a tight loop, you really need to have -msse4 somewhere. Most people just assume popCount efficient, but by default it isn't.

@phadej phadej closed this as completed Jun 8, 2024
@phadej
Copy link
Contributor

phadej commented Jun 8, 2024

I'll add, that cabal-install doesn't even support building for distribution of the box. You need to know a bit of what it does to make a distributable binary. (And e.g. audit your dependencies that they don't use data-files, etc). I'm not mentioning static linkage, etc.

And figuring out you need to turn a package flag is a lot less work then e.g. fixing issues like ndmitchell/hlint#1533, which is arguably the same problem: the binary for distribution is not built to be as widely usable as it could.

@matil019
Copy link

I was bitten hard by this change. It took quite some time to reach here from my server written with Servant crashing with an unfamiliar message Illegal instruction (core dumped) (a.k.a. SIGILL).
FYI I was compiling the server on a faster machine to run on a slower machine (that had an older CPU).

At least I'm relieved to know that there is a "quite significant performance boost" which could justify the tradeoff. But I wish the change would have been emphasized much more, for example by incrementing the major version number.

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

No branches or pull requests

3 participants