3 ms·
> it's not ARM vs x86, it's the integration pieces. Mind boggling that nothing is being done by PC makers. Intel spent over a decade and billions of dollars to
by duped 4y ago
> it's not ARM vs x86, it's the integration pieces. Mind boggling that nothing is being done by PC makers.
Intel spent over a decade and billions of dollars to make a mobile x86 chip that could compete with ARM on battery life and they failed. And now they're getting taken to the cleaners by an ARM chip for laptops. I don't think it's the integration that's the problem, x86 is just too inefficient relative to ARM.
When it's more efficient to emulate x86 on an ARM chip than to use a native x86 processor you have to ask some questions about the ISA and design.
- blinkingled 4y ago> x86 is just too inefficient relative to ARM Like, in what way and how much inefficient in 2022? Would it still be that when Intel finally gets to 5nm/3nm? Is the video reviewer lying or mistaken when he says 2 biggest differences that make up for most of the power draw between x86 and ARM are not in the ISA?
- duped 4y ago> Is the video reviewer lying or mistaken when he says 2 biggest differences that make up for most of the power draw between x86 and ARM are not in the ISA? Naive is a better word. The question is really, why don't designers (who have a vested interest in making a feature like battery life better to improve sales) take these "obvious" actions to improve their products? The answer is usually because they're not sound optimizations, or at least come with some heavy tradeoffs.
- blinkingled 4y agoThat's not at all a logical/technical argument - it's just further lazy speculation to claim that only reason designers don't take these obvious actions to improve their product is because "x86 ISA sucks". As pointed out it is hard enough to get obvious things done when there is one company and 3 org units involved - let alone a CPU vendor, an OEM, a BIOS vendor and SoC with 10 other chips by different OEMs. Oh and after that the OS vendor.
- duped 4y agoDisabling peripherals in sleep is an excellent way to brick a device or make sleep equivalent to "off." Disabling boost without understanding why its happening is not really a good idea, that's like removing memory because chrome is using too much.
- blinkingled 4y agoNone of those are ISA (https://en.wikipedia.org/wiki/Instruction_set_architecture https://en.wikipedia.org/wiki/Instruction_set_architecture) issues - they are firmware/os/SoC issues. The other issue is manufacturing process - AMD is getting to 5nm only recently and the results in lower power consumption are already telling. IOW ARM doesn't have some magical ISA level stuff to do more stuff with less power or avoid doing stuff entirely that x86 couldn't replicate.
- D13Fd 4y agoStraight-line performance per watt is not the problem IMO. The problem is something along the lines of sleep/wake states and how MS + Intel can’t seem to get it together to handle the times when the CPU doesn’t need to be working.
- duped 4y agoFrom what I've heard this is mostly on board designers and the complexity of how x86 handles the multiple levels of sleep/power state. Taking a conservative approach is done to prevent bricking devices on wake. I wouldn't blame MS for this. Linux has the same, if not worse, state.
- g_p 4y agoI think the root issue on sleep is Microsoft/vendor induced - this issue only really began when Microsoft introduced connected/modern standby, and started to incite OEMs to remove BIOS/UEFI support for S3 sleep. It seems unfathomable - maybe there is a valid reason for modern standby, but I've yet to find it. S3 resume is quick on a good laptop with good firmware. Modern sleep seems to drain the laptop battery quickly for some reason, and yet this has been going on for years now. Maybe standby drain isn't part of the Windows logo requirements and ought to be?
- Thoreandan 4y agoSelling StrongARM / XScale to Marvell might be something they regret. Wonder if they held onto a cross-licensing deal for the architecture.