The SQ1 is just the beginning. ARM is coming for the PC

[Black Phoenix]

I've been following this Youtuber for a while regarding how he delivers their thoughts to the viewers and this is his last video:



Well being this a forum with a lot of well educated and knowledge people, what are your thoughts about this?

[westfw]

• I fundamentally disagree with the assertion that systems need to have a common underlying architecture in order to have "seamless integration."
• (if I'm wrong, I find that depressing.)
• I sort-of viewed Windows8 as Microsoft's big experiment in unifying desktop and mobile UIs, and Windows10 as their admission that indeed, users don't particularly want their bug computers to work like their phones.
• I'm not convinced that RISC-V will penetrate high-end markets (mobile or desktop or mainframe) as quickly as people are predicting.  It's just an Instruction Set Architecture (as I understand it) as opposed to the full core design (like ARM or MIPS), and I suspect that it will be a lot more difficult to turn it into truly high performance silicon (at the desired MIPS/Watt points.)

[andersm]

Apple introducing ARM-powered laptops next year has been predicted for many years now. I believe it when I see it. ARM may be nipping at the heels of ultrabooks, but so far their performance outside mobile hasn't been great. I ran code compilation tests half a year ago, when Packet started offering eMag server instances, and was disappointed by the results. NXP have been hinting that their Layerscape CPUs will outperform eMag's 1st gen CPU, but I haven't seen any test results of it yet.

bug computers

Ha!

[techman-001]

• I fundamentally disagree with the assertion that systems need to have a common underlying architecture in order to have "seamless integration."
• (if I'm wrong, I find that depressing.)
• I sort-of viewed Windows8 as Microsoft's big experiment in unifying desktop and mobile UIs, and Windows10 as their admission that indeed, users don't particularly want their bug computers to work like their phones.
• I'm not convinced that RISC-V will penetrate high-end markets (mobile or desktop or mainframe) as quickly as people are predicting.  It's just an Instruction Set Architecture (as I understand it) as opposed to the full core design (like ARM or MIPS), and I suspect that it will be a lot more difficult to turn it into truly high performance silicon (at the desired MIPS/Watt points.)

I have a feeling that RISC-V will be disruptive because it's open. Look how disruptive Linux has been ? What happens if someone releases a multicore RISC-V optimized for parallel processing at a low price, it could be a game changer now that Moores Law has pretty much fizzled out ?

The designer of Mecrisp-Stellaris has been very excited about RISC-V from the begining and has made a Forth for it named "Mecrisp-Quintus". While I was ambivalent myself, now that Gigadevice has made a chip with a RISC-V core and peripherals from the STM32F103 I'm beginning to become a bit more interested.

[knapik]

Can it even be called a PC anymore if it uses ARM? I guess the term PC has pretty much lost its meaning a long time ago now.

That said, I'm very excited for the possibility of RISC CPUs  to finally come to the home computer. The main issue has always been binary compatibility with proprietary software, but as so much software these days is free and open source it can be a pretty painless transition.

[LeonR]

I've engaged on a discussion on another tech forum about how the PC segment evolution is stagnating, mainly because X86 is almost at it evolutionary limit. The big names (AMD, Intel, IBM, etc) should be working already on an new CISC ISA. PC actually need a total revamp, more akin to a new standard altogether - format factor, PSU design, interconnectivity (photonics for high bandwidth), multiprocessing, interop with other ISAs, etc. A modular format where you can add cards with whole systems on them, like those industrial backplanes would be nice.

[Mr. Scram]

Can it even be called a PC anymore if it uses ARM? I guess the term PC has pretty much lost its meaning a long time ago now.

That said, I'm very excited for the possibility of RISC CPUs  to finally come to the home computer. The main issue has always been binary compatibility with proprietary software, but as so much software these days is free and open source it can be a pretty painless transition.

Why would it cease to be a personal computer when it's powered by ARM? Not to mention some of the earlier examples of desktop computers were ARM based. Apple used PowerPC for their PCs too.

[Mr. Scram]

I've been following this Youtuber for a while regarding how he delivers their thoughts to the viewers and this is his last video:



Well being this a forum with a lot of well educated and knowledge people, what are your thoughts about this?

Thanks, I needed something to fall asleep.

[Ampera]

This is an incredibly common discussion in the former AfterNET eevblog IRC channel. Will see a CPU to topple x86?

While the argument can go on for a good while, the fact of the matter is we have had x86 since the late 70's, and it has seen continual and perpetual use and growth, in particular in the 00's and now again in the late 10's. One can walk into any datacenter and see x86 machine after x86 machine, and it's been this way for quite a while.

If you'd like to gear it back and say x86 will never be toppled, but simply will replace it in consumer devices, I'd argue it already has. How many people own a smartphone? How many people use it by the day? How many of those smartphones are x86?

At the end of the day, money is going into x86, and money will continue to go into x86. Nowhere near the amounts of pure capital are being put into any other platform for the purposes of developing a serious big iron/datacenter performer, and that will continue to be the case no matter how good your RISC is.

[SiliconWizard]

Yep. Besides, there are two big (huge) players behind the x86 architecture here: Intel and AMD. They can't be compared to ARM. ARM doesn't sell CPUs, they sell IPs. Completely different model. ARM has all reasons to favor multiplying the number of their customers, rather than sell to just a couple big ones. This is all good, but does "fragment" the ARM offering, so IMO this reason alone is what makes a big difference with x86. All manufacturers selling ARM-based processors are just too many, and not big enough individually, to pull off the business that Intel and AMD have been able to pull off.

Not even talking about RISC-V: same issue, with a tiny market. Even if it grew tremendously, it would eventually look like the ARM approach much more than the x86 one.

And then there are the performance questions. I don't think there is any equivalent to Core-i7 or Core-i9 (or Xeon, Ryzen, ...) CPUs based on ARM cores, performance-wise, at this point. Obviously even less so with RISC-V.

I don't see why the obsession with unification anyway. Diversity of offering for different markets and applications is a good thing.

[NiHaoMike]

And then there are the performance questions. I don't think there is any equivalent to Core-i7 or Core-i9 (or Xeon, Ryzen, ...) CPUs based on ARM cores, performance-wise, at this point. Obviously even less so with RISC-V.

The server class ARM CPUs are getting there. That said, the efficiency advantage of ARM over x86 is most significant for low power applications, so there's less incentive to go ARM in the first place.

I predict that x86 would eventually evolve into a pure 64 bit architecture, with legacy 32 bit and 16 bit apps supported by emulation. (In fact, I wouldn't be surprised if that's already the case for 16 bit.)

[andersm]

The server class ARM CPUs are getting there.

Not really. The best ARM server CPUs available today can't keep up with x86 server CPUs even with twice the number of cores.

I predict that x86 would eventually evolve into a pure 64 bit architecture, with legacy 32 bit and 16 bit apps supported by emulation.

That won't happen until Windows enterprise customers have gotten rid of all their legacy applications, which at this rate will happen sometime after the heat death of the universe. I've seen comments from some Intel/AMD folks that the 32-bit decoder of a modern x86 CPU is so small that just the validation effort required to remove it outweighs anything you'd gain from doing so.

[Mr. Scram]

Not really. The best ARM server CPUs available today can't keep up with x86 server CPUs even with twice the number of cores.

That won't happen until Windows enterprise customers have gotten rid of all their legacy applications, which at this rate will happen sometime after the heat death of the universe. I've seen comments from some Intel/AMD folks that the 32-bit decoder of a modern x86 CPU is so small that just the validation effort required to remove it outweighs anything you'd gain from doing so.

Define "keep up". The whole point is having more simple cores to handle more simple tasks instead of queueing them on less but more powerful cores. You can run X86 applications on ARM too. People somehow have it in their heads that's it's either option instead of both. It's a new tool in the toolbox with its own advantages and drawbacks.

[Mr. Scram]

The server class ARM CPUs are getting there. That said, the efficiency advantage of ARM over x86 is most significant for low power applications, so there's less incentive to go ARM in the first place.

I predict that x86 would eventually evolve into a pure 64 bit architecture, with legacy 32 bit and 16 bit apps supported by emulation. (In fact, I wouldn't be surprised if that's already the case for 16 bit.)

That's essentially what CPUs do. ik They don't execute instructions directly but translate them into internal instructions and then execute. There isn't separate hardware present for every instruction a CPU can handle. So you're correct although it's not quite a prediction. 

[andersm]

Define "keep up". The whole point is having more simple cores to handle more simple tasks instead of queueing them on less but more powerful cores.

But one of those more powerful cores can easily handle the workload of two or three of the less powerful ones, and they're cheaper too. ARM-based server chips may be fine for I/O-dominated workloads, but they're not very good at things requiring processing power, at least today.

[Black Phoenix]

From what I see probably in the near future it will be something like an hybrid: A X86 CPU architecture for the processing power and some low wattage arm cores for less demanding tasks.

That on a laptop could really increase the battery autonomy in hours, and on a server environment lower the power requirements and heat dissipation.

Or probably I'm totally wrong.

[thinkfat]

I think we will find, that once ARM CPUs are matching X86 in performance, they'll do that with a negligible different in power consumption. It's all about how many bits you need to flip for a certain operation, which will have a fixed lower limit. Once you're close to that limit, you can only further optimize your silicon process, which is what Intel has been doing for years.

[GeorgeOfTheJungle]

I think we will find, that once ARM CPUs are matching X86 in performance, they'll do that with a negligible difference in power consumption.

Exactly !

[Mr. Scram]

You don't need all that power all the time though. In fact you barely need it at all. Computers spend a tiny fraction of their time actually doing something and more often than not that small bit of work could be done leisurely.

[T3sl4co1l]

The bigger question will be software compatibility.

What is the one thing that, time and time again, kept resurrecting x86's rotten zombie corpse?

Compatibility.

Remember when Intel tried to ease developers into protected mode with the 286?  Yeah, no one f'kin used it, it was just an improved 8086.

Remember when Intel tried to push developers into a new instruction set (i432, Itanium) that could potentially be more efficient or powerful or faster?  (Though AFAIK it turned out they really weren't, after all?)  Remember how they lost billions each time?

Change is hard, especially when there's a billion existing products out there, a negligible fraction of which are currently under support and could conceivably be ported.  (Not that all billion are currently in use; but support is still a significant subset of in-use.)

So what about support?

Are enough existing products available in ARM, or trivial to port to ARM?  Are enough suppliers ready to support ARM for future and current customers?

The modest, but persistent, use of high level, JIT'd languages does show promise in this regard.  Anything that runs Java[/Script], C#, Python, PHP, etc. should be trivial, or almost trivial, to target.  At least down to issues of OS compatibility, which if the OS has multiple targets all using a fully compatible API, this should be trivial.  The only restriction being, whether a given language supports all its features on a given platform.  Which I think is generally a pretty strong priority?

What about high performance native code?  There should be very little ASM out in the wild, I would expect.  Perhaps the core parts of device drivers?  Drivers of course need to be similarly ported between both OS and CPU, another good point.  Most code is targeting an [OS] API, not an architecture, and between ARM64 and x64, I'm not aware of any gross omissions between the two (this isn't an assertion on my part, as I'm very unfamiliar with both; rather, take this as an invitation to provide examples).  Eh, probably instruction set extensions are weird?  But that's nothing the compiler can't fix.

Tim

[andersm]

You don't need all that power all the time though. In fact you barely need it at all. Computers spend a tiny fraction of their time actually doing something and more often than not that small bit of work could be done leisurely.

What are you even trying to argue here? Computer usage may be bursty, but when you need performance you need it. Knowing that the computer sits idle for 16 hours of the day does not make my builds finish any faster.

[Mr. Scram]

What are you even trying to argue here? Computer usage may be bursty, but when you need performance you need it. Knowing that the computer sits idle for 16 hours of the day does not make my builds finish any faster.

Fast core for ultimate performance, efficient core for the rest. Kind of what ARM is already doing except on a different scale. Maybe even perform tasks like receiving mail when sleeping. Of course some people will prefer you offloading those burst to the cloud entirely.

[NiHaoMike]

That won't happen until Windows enterprise customers have gotten rid of all their legacy applications, which at this rate will happen sometime after the heat death of the universe. I've seen comments from some Intel/AMD folks that the 32-bit decoder of a modern x86 CPU is so small that just the validation effort required to remove it outweighs anything you'd gain from doing so.

I recall that Windows has dropped native support for 16 bit apps since the 64 bit version of Vista, meaning that third party emulation software is required to run 16 bit apps. I could see native 32 bit support being phased out as well, although in that case, the emulation software would probably have to be preinstalled and ready to go.

Is there really that little to gain by redesigning the instruction decode to 64 bit only, moving 32 bit and 16 bit execution to higher level emulation software? Or more likely, the move to 64 bit only could take place when a new core architecture is being designed.

[knapik]

Why would it cease to be a personal computer when it's powered by ARM? Not to mention some of the earlier examples of desktop computers were ARM based. Apple used PowerPC for their PCs too.

Sorry, you're right and I'm wrong. I assumed PC only referred to the IBM computer line.