this post was submitted on 28 Oct 2023
124 points (100.0% liked)
Technology
37525 readers
261 users here now
A nice place to discuss rumors, happenings, innovations, and challenges in the technology sphere. We also welcome discussions on the intersections of technology and society. If it’s technological news or discussion of technology, it probably belongs here.
Remember the overriding ethos on Beehaw: Be(e) Nice. Each user you encounter here is a person, and should be treated with kindness (even if they’re wrong, or use a Linux distro you don’t like). Personal attacks will not be tolerated.
Subcommunities on Beehaw:
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
The problem with ARM laptops is all of the x86 windows software that will never get ARM support and all of the users that will complain about poor performance if an emulator is used to run the x86 software.
Most Linux software already supports ARM natively. I would love to have an ARM laptop as long as it has a decent GPU with good open source drivers. It would need full OpenGL and Vulkan support and not that OpenGL ES crap though.
Windows as always turn out to be the main villain.
Windows has nothing to do with it. They are talking about software applications that were made for x86. Stuff like Adobe CC, etc.
Windows runs on ARM (and has for a decade) and the apps available in the Windows app store run on ARM.
Apple has shown that the market could be willing to adapt.
But then again, they’ve always had more leverage than the Wintel-crowd.
But what people seem to ignore is that there is another option as well: hardware emulation.
IIRC correctly old AMD CPU’s, notably the K6, was actually a RISC core with a translation layer turning X86 instructions into the necessary chain of RISC instructions.
That could also be a potential approach to swapping outright. If 80% of your code runs natively and then 20% passes this hardware layer where the energy loss is bigger than the performance loss you might have a compelling product.
Virtually all modern x86 chips work that way
Microcoding has been a thing since the 1950s, it's the default. Early RISCs tried to get away with it and for a brief time RISCs weren't microcoded kinda by definition, but it snuck back in because it's just too useful to not hard-wire everything. You maybe get away with it on MIPS but Arm? Tough luck. RISC-V can be done and it can make microcontroller-scale chips simpler, but you can also implement the RV32I (full) insn set in terms of RVC (compressed subset) and be faster. Not to mention that when you get to things like the vector extensions you definitely want to use microcode. The Cray-1 was hardwired, but they, too, dropped it for a reason.
I guess in modern days RISC more or less means "a decent chunk of the instruction set will not be microcoded but can instead be used as microcode", whereas with modern CISC processors the instruction set and the microcode may have no direct correspondences at all.
It's less that they'll adapt, and more that they don't really care. And particularly in the case of Apple users: their apps are (mostly) available on their Macs already. The vast majority of people couldn't tell you what architecture their computer runs on and will just happily use whatever works and doesn't cost them the earth.
I didn’t mean the customers, but sure.