They even implemented a x86 emulator in order to run your usual native software on it.
What they need is an x64 emulator. 32-bit apps are few and between now.
There are decent quality laptops shipping with ARM already, like the Thinkpad Yoga: https://www.theverge.com/2020/1/6/21050758/lenovo-yoga-5g-sn...
There's also the obvious: Pinebook pro.
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
> 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.
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.
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.
I don’t know what workflow other JS coders have, but mine starts with local development in Node. Does V8 produce code that’s as optimal for ARM as x86_64? That’s a pretty big deal to me, and can in fact be very enabling. The local development experience really needs to be good to build a platform, otherwise development will be halting and piecemeal the way embedded development usually is.
> never tested on android
just as planned
???
I’m back-end, not front-end. I think I mentioned Node, right? Why would I test backend code on a phone?
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.
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).
Not really, if the system has enough free RAM to use as disk cache. For many scenarios, that suffices to run quite acceptably.
I'm not saying SBCs are "unusable" for desktop use cases, I'm saying I/O is the likely explanation for desktop responsiveness issues they encounter on SBCs.
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.
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.
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.