News for hackers. Stuff that matters.
Re:Intel Problems by rapsey on Tuesday January 19, 2021 @11:48AM (#25835341)
Why would it be lock in. If you can compile for arm you can compile for x86.
Re:Intel Problems by optimiz3 on Tuesday January 19, 2021 @12:40PM (#25836115)
Memory model, execution units, simd instructions...
Re:Intel Problems by rapsey on Tuesday January 19, 2021 @01:36PM (#25836873)
The vast majority of code running is in python, js, jvm, php, ruby, etc. Far removed these concerns.
Re:Intel Problems by jlawer on Tuesday January 19, 2021 @05:57PM (#25840090)
Some of those languages (especially python & php) utilise C based modules or packaged external binaries. Both of which have to be available / compatible with ARM.

When you run pip or composer on Amd64 they often pull these down and you don't notice, but if you try on arm you discover quickly that some packages don't support ARM. Sometimes there is a slower fallback option, but often there is none.

Re:Intel Problems by rapsey on Wednesday January 20, 2021 @12:18AM (#25842824)
Those are pretty minor issues that will be fixed as arm servers get more popular
Re:Intel Problems by oblio on Tuesday January 19, 2021 @01:26PM (#25836766)
The real question is, can you compile for ARM and move the binary around as easily as you can for x86?

I'm reasonably sure that you can take a binary compiled with GCC on a P4 back in the day and run it on the latest Zen 3 CPU.

Re:Intel Problems by easton on Tuesday January 19, 2021 @01:33PM (#25836838)
As far as I can tell, yes. Docker images compiled for arm64 work fine on the Macs with M1 chips without rebuilding. And as another commenter said, you can compile a binary on a Raspberry Pi 4 and move it to a EC2 graviton instance and it just works.
Re:Intel Problems by cozzyd on Tuesday January 19, 2021 @01:38PM (#25836901)
it will probably be a similar situation to x86, with various vendors implementing various instructions in some processors that won't be supported by all. I guess the difference is that there may be many more variants than in x86, but performance-critical code can always use runtime dispatch mechanisms to adapt.
Re:Intel Problems by oblio on Tuesday January 19, 2021 @01:50PM (#25837063)
It's true that there are extensions to x86, but 99,99% of software out there (the one you'd commonly install on Windows or find in Linux distribution repos) doesn't use those instructions or maybe just detects the features and then uses it.

I don't recall encountering a "Intel-locked" or "AMD-locked" application in more than 20 years of using x86. Ok, maybe ICC, but that one kind of makes sense :-)

Re:Intel Problems by cozzyd on Tuesday January 19, 2021 @01:56PM (#25837174)
Encountering SIGILLs is not super uncommon on heterogeneous academic computer clusters (since -march=native).

But yeah, typically binaries built for redistribution use a reasonably crusty minimum architecture. Reminds me of this discussion for Fedora: https://lists.fedoraproject.org/archives/list/[email protected]...

Re:Intel Problems by mitjam on Tuesday January 19, 2021 @05:35PM (#25839849)
Audio software usually runs better on Imtel than on AMD.
Re:Intel Problems by ndesaulniers on Tuesday January 19, 2021 @03:28PM (#25838445)
That doesn't mean compilers will emit such instructions; maybe hand written assembler will become less portable if such code is making use of extensions...but that should be obvious to the authors...and probably they should have a fallback path.
Re:Intel Problems by volta87 on Tuesday January 19, 2021 @01:58PM (#25837205)
> can you compile for ARM and move the binary around as easily as you can for x86?

Yes.