Comment by pythonaut_16 | Hacker News Reader

Comment by pythonaut_16 | Hacker News Reader

Parent Full thread

I don't know that this is what they're doing, but what I've wanted for several years is a dual power mode computer.

In powered up mode it would operate like a normal x86_64 chip, full power and full speed. But in low power or standby mode it could switch to an ARM chip or core and maintain access to RAM and disks to let it run updates and downloads in the background.

For example, right now to update Windows or Steam games or other software, I have to leave my computer running at full power. Generally depending on what I'm doing I want to throttle or stop the downloads so it doesn't interfere with my normal use. But I also hate leaving my desktop on at full power and with the fans running just so it can do downloads and background tasks.

Or an ARM core could run a simple file server, letting me access files and information stored on my desktop without leaving it on all the time.

TL;DR: I wish I could have an ARM core in my desktop to run background tasks like downloads and other things Raspberry Pi-ish levels of performance.

That's an intriguing concept, but it seems like it would be a headache to implement, from a software perspective. Unless I'm mistaken, if you wanted this low-power chip to perform windows updates, you would need MS to provide an ARM compiled program to perform x86_64 updates. Or you'd need a third party to do it somehow, which sounds messy. The same would apply for anything else you wanted to do that's more complicated than putting files in fixed locations. I suppose it could be relatively easy to just do the downloads, and leave installations/updates for when the main chip kicks in.

And the fileserver concept is pretty neat. Rather than having a separate low power machine that you send files to, your main PC could act as a fileserver using separate software while fully powered or in low-power mode. I'd buy that, if only for the novelty.

It is a fascinating idea. I'm wondering if something like an ARM build of Windows 10 S could already support an ARM to x86_64 handoff with the main kernel/OS/UWP apps running immediately available in low power scenarios and where it might pass things of to Win32 on ARM emulation instead pass things to an x86_64 core? Then from there build out more hand-off capabilities for power hungry processes or performance-hungry apps (like Xbox Game Mode)?

To some extent, I would be surprised if there aren't teams at Microsoft exploring such crazy hybrid notions already, if at least for options for future Xbox or Surface hardware. Recalls to mind Microsoft already experimented with a notification platform of a low power CPU screen coupled to a Windows device way back in the Vista timeframe [1].

[1] https://en.wikipedia.org/wiki/Windows_SideShow

It would absolutely require some level of Windows/OS support.

While you could definitely allow apps to run arbitrary ARM code on it, I also think it would be quite feasible for the hardware or the OS to expose a simpler API as well with basic functions like 'queue download' that would simply take a protocol, a URL, and a disk location.

The fact that programs are shipped as machine code bytes has plagued computing since the beginning. Security issues and backwards compatibility shackles abound in this model.

The obvious solution to these sort of problems problems is to send programs in some intermediate or high level form, with compilers for local CPUs being part of the loading process. While some successful environments have already done this (notably OS/400, and the ever-up-and-coming Mill CPU), there's just still too much momentum in the popular OSes for the "simpler" binary model.

ARM has a system they call "big.LITTLE" which essentially works this way: each processor contains pairs of cores, one high-performance core matched up with one low-power core, using a cache-coherent interconnect so that jobs can be swapped back and forth. They're not trying to use heterogeneous ISAs, though, so it's not quite as complicated as what you're describing.

Samsung's Exynos 8 mixed-and-matched cores of different cache line sizes and didn't bother to make the reported cache lines be the same size.

This recipe led to a hard-to-debug condition that the Mono team wrote about [1] (posted on HN [2]).

[1] http://www.mono-project.com/news/2016/09/12/arm64-icache/ [2] https://news.ycombinator.com/item?id=12481700

That is an unfortunate implementation. The concept is still interesting, though.

Previous attempt by Dell, http://www.eetimes.com/document.asp?doc_id=1253118

Reply on news.ycombinator.com