5 ms·
The unseating of x86 as the de facto standard for laptops, workstations, and servers would be a net benefit for both performance and security. Unfortunately, th
by DC-3 6y ago
The unseating of x86 as the de facto standard for laptops, workstations, and servers would be a net benefit for both performance and security. Unfortunately, though Apple will likely find very great success with their ARM Macs, it does not necessarily follow that the architecture will gain significant ground outside the Apple-sphere. I would love for my next laptop to be ARM-based, but I can't see Apple happily flogging chips to Dell or Lenovo, and I'm not sure if anyone else's ARM processors are up to the necessary standard.
- dijit 6y agoI mean, ARM is 'there' in most cases, the issue tends to be perceived latency of RISC vs CISC CPU's on desktop, not overall performance. There are decent quality laptops shipping with ARM already, like the Thinkpad Yoga: https://www.theverge.com/2020/1/6/21050758/lenovo-yoga-5g-snapdragon-qualcomm-8cx-x55-arm-windows-laptop-ces-2020 https://www.theverge.com/2020/1/6/21050758/lenovo-yoga-5g-sn... There's also the obvious: Pinebook pro.
- simias 6y agoWhat do you mean by latency here exactly?
- dijit 6y agoI'm not exactly sure what I mean and that's part of the issue, when using an ARM CPU with desktop software which has not been optimised to hide UI "lag" there's something that feels like it just.. lags. You can feel it on a rpi if you use it for a day, it's not that it's underpowered, you can grab a 15yo celeron that is much slower and single core and it will have less perceptable latency. The Celeron will "feel" as if it's working, the ARM chip will "feel" as if it's laggy. I can't quantify this behaviour, but it's consistent across all ARM CPU's I've ever used with traditional desktop software. Notably these issues don't seem to exist on Android or iOS, someone once told me this is due to the UI elements having a higher priority than anything else on the system.
- ianai 6y agoI forget the specifics, but risc winds up feeling slower because it’s a more “correct” arch than cisc. Been a while since this came up!
- _bxg1 6y agoDo those ARM systems have graphics chips, or are they rendering the UI on the CPU? Modern x86 processors have integrated graphics for GUI basics, video, etc. Linux desktops can theoretically run off of just the CPU, just... not super well.
- zozbot234 6y agoEven Raspberry Pi has an integrated GPU. They feel slower because they're lower-frequency in-order chips, and while the chips themselves have multiple cores many applications don't use them properly - more specifically, they don't render the UI in a dedicated thread.
- fouc 6y agoRPI are cheap hardware not really designed for desktop computing I guess.
- icedchai 6y agoYes, I've noticed this as well. ARM Linux desktops feel sluggish. It is not IO, because I have done tests after everything has been cached, loaded once. I have a RPi 4 here, as well as some older Pine64 boards.
- DCKing 6y agoIf your experience with "desktop UI on ARM" is based on the RPi and other ARM SBCs, the overwhelmingly likely explanation for this perceived lag is lacking I/O performance. Running a Raspberry Pi (or any system) from any cheap flash storage setup like SD cards or cheap eMMCs degrades desktop responsivity a lot. The ARM desktop hardware most of us have experience with has significant I/O problems, but that's due to them being cheap hardware, and not due to ARM. I/O is actually the real prevalent bottleneck for desktop interactivity on all modern hardware. Even older x86 systems with spinning platter hard drives are set up for a more responsive desktop experience due to the I/O performance being suited for the desktop. Modern Android phones and iPhones also have much better I/O setups for interactive use (UFS for high end Android, Apple actually uses NVME because responsiveness is so crucial) . Certainly CISC vs RISC has nothing to do with it as that discussion really has no bearing on the situation anymore on discussions about modern ARM and Intel (see my other post).
- ianai 6y agoRISC cpus have historically been under-clocked and perceivable slower than their cisc competitors. Apple was running on risc cpus before going intel x86. They were constantly marketing their speeds as less important than speeds matter to x86 architecture. I hope they’re able to devote two cores to UI/UX at a much higher frequency than the general compute cores. That would take some engineering know how, but could negate the performance complaints largely.
- Symmetry 6y agoThat's just a matter of the process node Apple's PowerPC chips were on. When RISC chips came out their big selling point was that they could be clocked many times faster than CISC chips at the time could because it was easier to pipeline them and because you could put the entire CPU on a single chip.
- kmeisthax 6y ago"RISC" isn't a single architecture, it's a philosophy for designing architectures. The "RISC" Apple was using before x86 was called PowerPC, and it was designed mostly by IBM. It was also a horrible piece of overheating garbage that I'm still honestly surprised wound up in the Xbox 360 and PlayStation 3. The "RISC" Apple is using now, ARM, is a far more practical architecture that Apple has already beat Intel with in single-thread perf... at a lower clock rate, with strict power limits. Letting the A13 stretch it's legs with wall power and a big heatsink would completely crush Intel and x86 in every benchmark except multi-threading. User-perceived latency has little to do with the clock rate of a processor, though. What you need is: 1. Immediate feedback upon user input 2. Progress animations that move, even if progress is indeterminate 3. High frame rates on your animations 4. No frame stutter or torn frames Out of the four, low clock rate will mainly impact frame rates and pacing, but that can still be mitigated by using what you have as efficiently as possible.
- DC-3 6y agoI think the Pinebook is an awesome piece of kit and if I could justify doing so I would absolutely buy one but from everything I've read it's not really something you'd want to do serious work on unless you also have the luxury of a beefy workstation to shell into. I suspect the same applies to the Yoga - perfectly alright for most of the day but just wouldn't have the firepower for big compilation jobs or serious multitasking.
- dijit 6y agoYour original assertion > Unfortunately, though Apple will likely find very great success with their ARM Macs, it does not necessarily follow that the architecture will gain significant ground outside the Apple-sphere. Does not imply heavy workloads, compilation being offloaded to cloud is something already being done though. I suspect that ARM will cannibalise most workloads, since it's shown very strong early competence already in photo and video editing on the iPad Pro, I highly suspect advancements in that direction will come to quallcomm CPU's in future.
- DC-3 6y agoMy original comment discussed the prospect of ARM becoming the leading architecture for the entire range of machines that at the moment tend to be x86 - that's laptops, desktops, workstations, and servers. For this to happen, ARM needs to be capable of dealing with intensive, CPU-heavy tasks like compilation. As the Torvalds quote in the linked article explains, ARM servers cannot become the norm without ARM desktops becoming the norm and vice-versa.
- dijit 6y agoSure, but it's not all or nothing. ARM can eat the earth but it will not be a shift in a single year, I was suggesting a likely way forward and that is bottom up, coming from low end laptops to higher end laptops and eventually workstations and servers. Just because it's not for -you- right now because you need local compilation does not mean a JS coder or a normal office worker would be unable to use an ARM based machine. Nothing prohibits ARM from ever being workstation grade, it's just not the focus right now- but you seem to imply that because there's no workstation capable CPU that there never can be one, which I find disingenuous.
- DCKing 6y agoThe RISC vs CISC discussion was important in the nineties but not anymore. There's absolutely nothing 'reduced' about modern ARM chips, and every Intel processor since the late 1990s has used significant RISC design elements. In modern contexts, the RISC vs CISC discussion still gets brought a surprising amount. But it is simply not relevant anymore. See also previous discussions on Apple SoCs: https://news.ycombinator.com/item?id=19327276 https://news.ycombinator.com/item?id=19327276
- mtgx 6y agoQualcomm's Snapdragon 8cx is a step in the right direction, as it's the first "PC-class" (more like mainstream laptop-class) ARM processor, a processor actually designed with laptops in mind, unlike all the other ARM processors that were put in laptops before that. But even the 8cx is limited to mainstream "browsing-only" type of laptops for one simple reason - there isn't demand for anything else from OEMs right now. So Qualcomm will not design a more powerful chip until the demand appears. This is in contrast to Apple, who can "generate the demand" simply by making such much more powerful Arm laptops available and convincing people to buy them. This is also one of the main reasons why Apple tends to have the more powerful processors in the smartphone market. No OEM is asking for a mobile GPU powerful enough to run advanced video editing on the devices and whatnot. So the suppliers comply.
- luch 6y agoNot sure if that's what you have in mind, but Microsoft now has an ARM-based product line :https://techcrunch.com/2019/10/02/microsoft-launches-the-arm-based-surface-pro-x/ https://techcrunch.com/2019/10/02/microsoft-launches-the-arm... They even implemented a x86 emulator in order to run your usual native software on it.
- starik36 6y ago> x86 emulator What they need is an x64 emulator. 32-bit apps are few and between now.
- koenneker 6y agoI think that the restriction to 32-bit apps is based on the fact, that only the patents covering the early iterations of x86 ISA have expired. Microsoft wouldn't want to be sued by Intel for infringing on later Tech (like x86-64), so emulation is still restricted to this subset.