- cross-posted to:
- linux@programming.dev
- cross-posted to:
- linux@programming.dev
You must log in or register to comment.
I feel like linux users benefit the most from arm since we can build our software natively for arm with access to the source code.
no love for RISC-V?
Until risc-v is at least as performant as top of the line 2 year old hardware it isn’t going to be of interest to most end users. Right now it is mostly hobbyist hardware.
I also think a lot of trust if being put into it that is going to be misplaced. Just because the ISA is open doesn’t mean anything about the developed hardware.
deleted by creator
RISC-V is currently already being used in MCUs such as the popular ESP32 line. So I’d say it’s looking pretty good for RISC-V. Instruction sets don’t really matter in the end though, it’s just licensing for the producer to deal with. It’s not like you’ll be able to make a CPU or even something on the level of old 8-bit MCUs at home any time soon and RISC-V IC designs are typically proprietary too.
Same goes for RV, OpenRISC, MIPS and other architectures.
Is MIPS still around? I know it was used a lot in embedded stuff but last I heard they were shutting down development of new MIPS chips.
Baikal T comes to mind.
It doesn’t usually work that well in practice. I have been running an M1 MBA for the last couple years (asahi Arch and now Asahi Fedora spin). More complex pieces of software typically have build system and dependencies that are not compatible or just make hunting everything down a hassle.
That said there is a ton of software that is available for arm64 on Linux so it’s really not that bad of an experience. And there are usually alternatives available for software that cannot be found.
Long time Raspberry Pi user here, the only software I can’t load natively is Steam. What software are you having problem with on the M1?
Electron apps using older versions that don’t support the 16k page size are probably the biggest offenders
Fucking Electron. Again.
I can’t say I’m one who shares that sentiment seeing as the only two projects I’m involved with happen to be Electron based (by chance rather than intention). Hell, one of them is Pulsar which is a continuation of Atom which literally invented Electron.
Couldn’t we do that with x86?
We can. The point is that Windows users can’t compile for arm. They depend on the Dev to to it. That will take some time and some won’t do it at all.
Aha. I see so many Docker projects with examples of how to build for ARM, I just assumed it was always that easy.
It’s easy to compile something for a certain infrastructure if you can compile it yourself and won’t have to beg another party to do so.
Is that a developer licence thing? I know GitHub recently announced Windows Arm runners that would be available to non-teams/enterprise tiers later this year.
It isn’t as simple as just compiling. Large programs like games then need to be tested to make sure the code doesn’t have bugs on ARM. Developers often use assembly to optimize performance, so those portions would need to be rewritten as well. And Apple has been the only large install of performant ARM consumer hardware on anything laptop or desktop windows. So, there hasn’t been a strong install base to even encourage many developers to port their stuff to windows on ARM.
Yeah this has been our (well, my) statement on requests to put out ARM binaries for Pulsar. Typically we only put binaries out for systems we actually have within the team so we can test on real hardware and replicate issues. I would be hesitant to put out Windows ARM builds when, as far as I know, we don’t have such a device. If there was a sudden clamouring for it then we could maybe purchase a device out of the funds pot.
The reason I was asking more about if it was to do with developer licences is that we have already dealt with differences between x86 and ARM macOS builds because the former seems to happily run unsigned apps after a few clicks, where the latter makes you run commands in the terminal - not a great user experience.
That is why I was wondering if the ARM builds for Windows required signing else they would just refuse to install on consumer ARM systems at all. The reason we don’t sign at the moment is just because of the exorbitant cost of the certificates - something we would have to re-evaluate if signing became a requirement.
I’d rather see what RISC-V has to offer.
As a fellow risc-v supporter, I think the rise of arm is going to help risc-v software support and eventually adoption. They’re not compatible, but right now developers everywhere are working to ensure their applications are portable and not tied to x86. I imagine too that when it comes to emulation, emulating arm is going to be a lot easier than x86, possibly even statically recompilable.
They’re not compatible
This is what concerns me. ARM could dominate the market because almost everyone would develop apps supporting it and leave RISC-V behind. It could become like Itanium vs AMD64 all over again.
Well right now most people develop apps supporting x86 and leaves everything else behind. If they’re supporting x86 + arm, maybe adding riscv as a third option would be a smaller step than adding a second architecture
Exactly. Adding a third should be much simpler than a second.
Or what FPGAs have to offer.
Punch cards are gonna be back baby
For me, arm has already “won” this debacle – convenience > performance all day errday.
ARM won the mobile/tablet form factor right from the start. Apple popularised ARM on the desktop. Amazon popularised ARM in the cloud.
Intel’s been busy shitting out crap like the 13900K/14900K and pretending that ARM and RISC-V aren’t going to eat their lunch.
The only beef I have with ARM systems is the typical SoC formula, I still want to build systems from off the shelf components.
I can’t wait.
The only beef I have with ARM systems is the typical SoC formula, I still want to build systems from off the shelf components.
I’m here with you. ARM and RV could really go into standardization.
Thinking about it, the SoC idea could stop at the southern boundary of the chipset in x86 systems.
Include DDR memory controller, PCI controller, USB controllers, iGPU’s etc. most of those have migrated into x86 CPU’s now anyway (I remember having north and south bridge chipsets!)
Leave the rest of the system: NIC’s, dGPU’s, etc on the relevant busses.
I’m both surprised and not surprised that ever since the M1, Intel seems to just be doing nothing in the consumer space. Certainly losing their contract with Apple was a blow to their sales, and with AMD doing pretty well these days, ARM slowly taking over the server space where backwards compatibility isn’t as significant, and now Qualcomm coming to eat the windows market, Intel just seems like a dying beast. Unless they do something magical, who will want an Intel processor in 5 years?
Ok, no shot the title doesn’t contain “arm wrestle” on purpose…
It literally has a picture of arm wrestling on there. I think it’s on purpose.
recently got asahi running on an m1 macbook pro. loving the battery life that I get out of it
Arm is not any better than x86 when it comes to instructions. There’s a reason we stuck to x86 for a very long time. Arm is great because of its power efficiency.
Arm is better because there are more than three companies who can design and manufacture one.
Edit: And only one of the three x86 manufacturers are worth a damn, and it ain’t Intel.
Three? VIA?
Yes, everyone forgets them. Mostly for good reasons.
Do they (or whatever’s left of them) have a license to x86_64, or is it just x86?
They have x86_64 models.
That power efficiency is a direct result of the instructions. Namely smaller chips due to the reduced instructions set, in contrast to x86’s (legacy bearing) complex instruction set.
It’s really not, x86 (CISC) CPUs could be just as efficient as arm (RISC) CPUs since instruction sets (despite popular consensus) don’t really influence performance or efficiency. It’s just that the x86 CPU oligopoly had little interest in producing power efficient CPUs while arm chip manufacturers were mostly making chips for phones and embedded devices making them focus on power efficiency instead of relentlessly maximizing performance. I expect the next few generations of intel and AMD x86 based laptop CPUs to approach the power efficiency Apple and Qualcomm have to offer.
All else being equal, a complex decoding pipeline does reduce the efficiency of a processor. It’s likely not the most important aspect, but eventually there will be a point where it does become an issue once larger efficiency problems are addressed.
Yes I understand that and agree, but the reason x86 dominated is because of those QoL instructions that x86 has. On arm you need to write more code to do the same thing x86 does, OTOH, if you don’t need to write a complex application, that isn’t a bad thing.
You don’t need to write more code. It’s just that code compiles to more explicit/numerous machine instructions. A difference in architecture is only really relevant if you’re writing assembly or something like it.
Sorry, I should have been more specific. I am talking about assembly code. I will again state that I am pro-arm, and wish I was posting this from an arm laptop running a distro.
We stuck to x86 forever because backwards compatibility and because nobody had anything better. Now manufacturers do have something better, and it’s fast enough that emulation is good enough for backwards compatibility.
Acorn computers would like to say that’s not 100% correct.
