ARM Computers

ARM computers have been on and off my mind since the start of this year, especially since I've tentatively been following the M1 chip and how it's doing in Apple's computers. It is keeping me somewhat interested by its efficiency which of course brings better battery life and not dealing with a x86 laptop roasting itself white because I have to run Yet Another Electron App for whatever I'm doing. Yes I know I shouldn't be running Yet Another Electron App, but without majorly uprooting my workflow or burning my brain in an IDE for a clone, it's going to stay like that unfortunately and is a topic for another time. The only thing really preventing me from jumping ship from x86 is mostly the laptop options. For context I'm using a ThinkPad E585 which features a compact fullsize with numpad and a matte LCD, which are really the two important things to me. Though admittedly additional physical left, middle, right buttons above the touchpad are nice to confidently click things quickly if not somewhat ergonomic in it's own weird way. In contrast lot of the laptops I see—of which are few—do not even have a fullsize or comparable keyboard on them which instantly turns me off. I still use the numpad for the occasional data entry or when I'm doing some programming and being without it is enough to bug me. Though if the situation doesn't change I might as well just buy an ARM laptop since I would still make use of it as an on-the-go workstation, and lean against the x86 if I expect more serious work. Additionally, seeing a ARM desktop would be interesting. And if it had PCI connections then hell we could have a power-efficient—or as power-efficient as you can with GPUs nowadays—graphics workstation or gaming rig.

Additionally, since Intel is already reaching the physical limits of what x86 can do to the point a literal unit designed to cool a laser for cutting stuff is struggling to keep up with the heat their CPUs are dumping out. Admittedly an issue of cooling design, but it does read like ARM would be the next step to push computing further.

>>68068 what about RISC V? I believe an open ISA should be the way to go!

>>68073 Oh yeah. When I was writing the post I kinda forgot about the RISC architecture, so I'd probably wanna look at that and see how good the performance/efficiency is on that front. Even if ARM is closed in the sense of licensing, it's still great that the architecture is open for everyone to tinker. But I do agree having an architecture that is open from beginning to end would be lovely. Full on open-source computing from hardware to software would be the ultimate goal and scratches my Right to Repair itch.

Instruction set has no bearing on performance, everything is decoded anyway. Modern x86 is RISC under the hood. Apple's advantage is not about the instruction set, it's about having exclusive access to TSMC's latest node and full hardware/software integration.

>>68066 I'm using an arm laptop and a regular desktop. I mostly use my laptop when I'm outside or traveling to another city. Having a numpad would have a noticable negative impact on the portability so I like it that way. Plus I already have a numpad on my desktop anyways. At worst I would connect an external keyboard to my laptop but I never had the need to do that. If you're going to use it as the only computer you have, things would be different. Besides open source games or emulation you don't have anything really.

>>68077 >Instruction set has no bearing on performance, everything is decoded anyway That decoding takes transistors and energy. RISC architectures have better performances per watt characteristics than x86. You're right about Apple's advantage mainly coming from tight hw/sw integration though. Intel and AMD are trying to catch up but they're still tied to emulating IBM PC's.

>>68313 >That decoding takes transistors and energy. RISC architectures have better performances per watt characteristics than x86. No. Decoders occupy such an infinitesimal amount of die area in a modern cpu that there's no perceptible, real world difference.

>>68324 Sure, caches and various interconnects take up the vast majority of almost any modern high-performance CPU. However those don't always need to be clocked as high as the critical path (or sometimes, they don't even need to be clocked at all). Since a microcoded architecture can't execute instructions faster than the microcode can decode and execute them, the microcode ROM needs to be clocked very high. Not to mention, SRAM is a very repetitive circuit and thus easier to manufacture correctly and compactly than a microcoded pipeline. So, even though the microcode is a really tiny part of the CPU die, it has significant impacts on the power usage of a core. It is obvious that this results in significantly higher performance, but if you want a really low power chip that can still run pretty well, you go for RISC-- by which I mean, the general philosophy that says "silicon is executing your instructions". That's why almost all phone processors are ARM and x86 chips have to be down clocked into oblivion to even be considered for mobile devices.

>>68066 ISA has little to do with cheap designs nowadays. X86 is not really CISC since the Pentium Pro where they started splitting complex instructions into microops to be able to reorder them better. The only real advantage of ARM over X86 is that it needs less complex decoder because it is a smaller ISA. But instruction decoder contributes very little power consumpion in modern chips. ARM chips generally happen to be more power efficient than X86 chips for low-power applications because that's what the designers of those chips optimized for. They optimized for phones and tablets while X86 chip designers optimized for desktops with laptops being a secondary concern. Even then, modern laptop X86 chips from AMD come very close to ARM when it comes to efficiency at low power. M1 Macs were a revolution when they released' but M2 was hardly an improvement and there have been 3 generations of mobile Zen chips in the meantime, each one better than the previous one. It's Intel that's the most behind because their litography process is like kicking dead whales down the beach ass compared to newest nodes from TSMC.

>>68648 > X86 is not really CISC still CISC, retard. > M1 Macs were a revolution when they released that never happened. m1 was literally dead in the water before it was released thanks to benchmarks uploaded to public sites. ever since apple released ARM macs they've lost more market share. since when does a revolution send a company backwards exactly? so revolutionary that apple had to halt production on m2 a few months ago because nobody was buying macs (first time in apple's history that they've had to halt production due to falling sales numbers). moving to ARM has been disastrous for apple's computer lines and end users. if apple didn't have their itoddler device market they would be heading to bankruptcy court and their share price would be worthless.

>>68648 ISA matters when you're targeting extremely low power and extremely low footprint (basically optimizing for # of transistors at that point) but aside from deeply embedded microchips in ultra-low-power applications that isn't really a concern for anybody. >>70584 Where are you hearing these things? Everyone I know who has used an M1 has been impressed by it, and they sold very well. M2 is just not that much better and a lot more expensive, that's purely a business problem not a technical one.

>>70584 >still CISC, retard. it's decoding instructions into some proprietary uop ISA that looks RISC-y >ever since apple released ARM macs they've lost more market share. windows is falling in market share cause of these accursed Arm SoCs, that's how hard Intel is losing right now >half production on M2 that's cause the M1 was so good and the M2 is so incremental there isn't a fuarrrking upgrade path and I guess logistics didn't think that part through

>>68066 ARM = locked bootloaders avoid ARM computers like the plague

ARM in the datacenter is really interesting nowadays. You can rent an 80 core ARM server from Hetzner for €200/month.

>>72196 >ARM = locked bootloaders >ARM is a family of RISC instruction set architectures for computer processors >A bootloader, also spelled as boot loader or called boot manager and bootstrap loader, is a computer program that is responsible for booting a computer. please do better next time

https://www.arm.com/company/news/2023/08/arm-announces-public-filing-of-registration-statement-for-proposed-initial-public-offering >Arm Announces Public Filing of Registration Statement for Proposed Initial Public Offering I'm holding out hope that RISC-V based silicon will be able to compete with ARM before the (((markets))) suck all the value out of the company. I've read that RISC-V chips are already deployed in plenty of embedded products, but it would be really nice to see RISC-V succeed in high-end applications like phones, SBCs, and servers.

>>72204 I think the point he is trying to make is that x86 has a standard booting mechanism, with backwards compatibility going back to the '70s and even earlier. The BIOS will load 512 bytes from a disk and then transfer execution over to it. If you write one bootloader, it will run on virtually all x86 processors. (There is still some variation, but they are minor and well-documented.) On ARM, there is no common mechanism for bootstrapping, which means that virtually every chipset has to be programmed individually, thus greatly diminishing portability. On top of this, most manufacturers won't provide documentation for how this all works, because consumer ARM devices aren't intended to give users control over that.

>>72222 Yeah but that's not ARM problem. That's problem of motherboard manufacturers. https://en.wikibooks.org/wiki/X86_Assembly/Bootloaders#What_is_a_Bootloader? As you see everything it takes to resolve the issue is a company making an open standard and following it, so that others may implement open source firmware.

Related: I've managed to turn my ARM e-reader into a (not very comfortable, but usable) typewriter. It took me a while to remap my wireless keyboard since Shift wasn't working properly, but now I can use it for lightweight tasks in the terminal. Pic related, it's my Kobo Libra H2O and my keyboard. https://mayvaneday.org/blog/2023/september/koreader.html https://letsdecentralize.org/tutorials/kobo-terminal.html Cross-compiling for ARM is a PITA for any programming language other than Golang, though, and the thing is running an embedded version of Linux, so it's not like I can just apt-get the Python interpreter or something. Anyone else done something like this to an old ARM device? I also have a Debian chroot on an ancient Android tablet, but it doesn't like multiplexers like Byobu, so I haven't written anything up on it yet.

>>72226 >As you see everything it takes to resolve the issue is a company making an open standard and following it, so that others may implement open source firmware. I wonder why that isn’t so already…

I'm kind of interested in seeing Nvidia get into the CPU space through ARM.

>>74035 nvidia must die perish collapse dissolve disitegrate

>>74036 Agreed… Try looking at their source code for certain things and you’ll think that more. I mean, look at this horrid soykaf: https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/src/nvidia-modeset/src/nvkms-modeset.c#L3597

>>74037 sorry i'm pretty dumb so i did not notice anything too out of my way except their silly goto use. even i don't do that. but again, i'm pretty stupid, so am a poor judge