I see it going the other way, consoles will likely drop X86 ASAP. With ARM they get like 3-4 vendors to bid between. On X86 there bascially always going to be using AMD, unless Intel takes less margins and get a better IGPU.
Since x86 has spread to consoles, not likely.
Hooray for another one of *these* threads.
ARM and x86 are instruction sets; being that x86 has a massive head start and most of the back-end infrastructure is running on x86 hardware / software that dumb devices like ARM powered internet phones use; x86 will never be replaced.
Also, ARM hardware designed to perform like x86 hardware will use about the same amount of power.
poofyhairguy said:I think the truth is there aren't really any fans of x86, just fans of Intel,
I think I'd rephrase a little bit to say that there aren't (or at least aren't many) fans of x86, there are fans of high-performance, commodity hardware. And that mostly means Intel.
I think I'd rephrase a little bit to say that there aren't (or at least aren't many) fans of x86, there are fans of high-performance, commodity hardware. And that mostly means Intel.
Indeed. x86 is fast and cheap. If ever ARM or some other architecture has fast and cheap computing solutions, I would definitely get one.
Indeed. x86 is fast and cheap. If ever ARM or some other architecture has fast and cheap computing solutions, I would definitely get one.
We already have fast and expensive (POWER, SPARC64), and while technically I could afford such systems, performance/$ is significantly better with x86 (even AMD stuff).
Just to provide a bit of background on the argument that Intel will be around for a long time, because of legacy code:
In a 2009 article in the FT, industry insiders estimated the amount of Cobol code at over 220 billion (10^9) lines of code, or more; the cost of re-writing in another language was put at $25 per line, over 5 trillion USD. Most code originated on mainframes, and it was being ported to the cloud, as Cobol still.
A more recent article, in 2015, does mention newer systems, but a lot of the $200 billion IT annual budget of the banks is still spent on maintenance of old systems, and meeting regulatory targets, rather than innovating. A lot of the world's code did not originate on X86 systems, it is just passing through.
This oft-cited paper has a lot of great raw data, but the ultimate conclusion, that ISA doesn't really influence power consumption, is completely pulled from nowhere. They took a bunch of x86 and ARM platforms with a ton of different variables and concluded that, since they gave very different results, that one of the variables didn't matter. It doesn't make any sense. It's very un-scientific.
That isn't to say that ISA does make a large difference. That's a very complicated question that's extremely difficult to examine, and probably not something you'll be able to do just by comparing real world hardware. You just can't isolate the variables. The most qualified people to give insight into that question would probably by CPU architects who are highly familiar with x86 and ARM. Over the years different CPU architects have commented on this, with somewhat differing answers - of course the actual answer is not going to be some fixed percentage difference in some metric but will be influenced by a ton of other factors.
I'm not a CPU architect, so I can't give insights like they could. All I can really do is look at things as an assembly programmer and look at aspects of existing CPU designs. But from my perspective, x86 has some major flaws in some areas.
x86 uses a byte variable encoding, vs ARM64 which uses a fixed 4-byte encoding. So x86's encoding is much more flexible and should enable a much better code density. Yet in studies I've seen the two (generated with the same version of GCC) tend to have comparable code density. And from my experience I would wager that in SIMD heavy code x86 has worse code density.
Why would this be the case? It's because x86 has been developed in a very inefficient way, by very gradually adding new functionality a bit at a time in many steps. This started with 32-bit mode. Adding the new operand sizes and expanding the addressing with SIB bytes was sub-optimal. Adding MMX then SSE took more and more prefix bytes. Lots of instructions have redundant encodings or do the same thing as other instructions. VEX undertakes a major restructuring to try to account for this, it's practically a completely new instruction set encoding but it too pays for having to live alongside legacy SSE.
So the key benefit to x86 ends up not actually being much of a benefit at all and you're stuck paying for it. People often say this payment isn't actually anything, just a little extra space in the decoders. But consider the lengths that Sandy Bridge and onward go through to avoid this decoder cost. They have this uop cache, and while it's not known exactly how many bits it takes we do roughly know what the uops are capable of, so I would estimate that the instructions take up at least 2-3x more space than they do in the L1 icache. This is before taking into account the extra space wasted on redundant data (from overlapping lines) and extra metadata needed over a normal cache (to maintain offsets into the cache lines). To pump out 4+ uops a cycle that need a really wide interface, a lot of wires compared to what they'd need to read from the L1 icache. All of this to avoid the decoders, which cost several pipeline stages.
And then, even with all of this work put into x86 instructions, even with the x86 instructions being relatively large for what they do.. in a lot of ways the instruction set still sucks.
Over the last few weeks I've been doing x86 optimization of my Android app. For me this means targeting SSSE3 in 32-bit x86. This is the realistic baseline for x86 on Android; 64-bit use is too low (even among 64-bit capable SoCs, which eg Medfield and Clovertrail+ were not) and SSE4.x doesn't add that much anyway.
I didn't really appreciate this until I had to do it but I can now list many disadvantages SSE4.2 has vs ARMv7 NEON (let alone ARMv8/AArch64). Especially with integer SIMD. SSE has some advantages but they're much fewer.
Here's a comparison of the inner loop from two functions to demonstrate some of what I'm saying:
ARMv7 NEON: http://pastebin.com/7g4Ad46N
x86 SSSE3: http://pastebin.com/E3wwyTif
Actual performance will vary depending on uarch and all that.. but the processor executing the second is going to have a really hard time doing it anywhere close to as efficiently as the processor executing the first. There's just only so much uarch can hide, I really can't look at this big gulf and say that ISA doesn't matter. Now this is kind of a contrived example, I picked something that looked especially bad afterall, for some functions SSSE3 basically nails it. But this is definitely enough of a thing to really make me feel a tangible difference.
AVX and AVX2 fix some of the disadvantages and add their own unique benefits. This is basically Intel's admission that ISA does matter, which is why they're addressing weaknesses in the ISA. But AVX is not supported on Celeron and Pentium branded processors, let alone Atoms. And at this point I'm wondering when they ever will be. From my perspective, they're only there on the processors that need them the least. They're sold as a luxury and not as a feature to make the CPU more competitive.
How could code cost $25 per line? That's pretty high. Decent coders can write hundreds of lines of code on a good day. Granted, we're talking COBOL here, which is like writing code by punching the keyboard, but come on.
Anyway, I think the amount of legacy code that was written in x86 assembly is a lot smaller than the amount of COBOL code. There's still costs associating with porting code written in something like C or C++ away from x86, but they're a different sort of less severe cost. Even porting ancient assembly code is easier, there are surely tools to help with that that are pretty reliable if you don't care hugely about performance, and I doubt you really could if the code is prehistoric.
That is COMPLETELY ignoring the main benefit of ARM:
x86, as it stands, is only licensed by three companies and two of them aren't very competitive in the general market. Even if a company that has the resources to be competitive (like Apple or Samsung) buy one of the weak companies the x86 licence does not transfer. x86 is a dead end LEGALLY.
Meanwhile anyone and we mean anyone can start making an ARM cpu. THAT is why it will beat x86 one day. Not because of actual tangible technical benefits to one instruction set or the other, but because the ARM market is more competitive and that competition will lead to the best possible CPUs.
What is funny is x86 fans know this- they watched as x86 killed Power, SPARC, and RISC using the same economic argument.
I think the truth is there aren't really any fans of x86, just fans of Intel, and they hate to read the obvious writing on the wall that one day Intel isn't going to matter like they did the last 30 years. Hell, Intel doesn't even know what they are doing. They cut the mobile budget, but increase the "Internet of Things" budget which is basically "mobile but even cheaper." That is why they are building robots and things like that, Intel knows in the long run the consumer market goose is cooked unless they can find a new use case for high margin CPUs.
Now this is kind of a contrived example, I picked something that looked especially bad afterall, for some functions SSSE3 basically nails it. But this is definitely enough of a thing to really make me feel a tangible difference.
AVX and AVX2 fix some of the disadvantages and add their own unique benefits. This is basically Intel's admission that ISA does matter, which is why they're addressing weaknesses in the ISA. But AVX is not supported on Celeron and Pentium branded processors, let alone Atoms. And at this point I'm wondering when they ever will be. From my perspective, they're only there on the processors that need them the least. They're sold as a luxury and not as a feature to make the CPU more competitive.
ARM works well here because a loss leader like a phone needs to be as cheap as possible in hardware, the money is made on the contract / after the hardware sale.
My ultimate point, which seems to be lost, is that an ARM desktop chip DESIGNED to compete with an i7 will probably use a similar amount of power and produce a similar amount of heat.
AND, why would someone (and not one person, but a whole lot of people and money too) design an ARM desktop chip with little useful ecosystem for it to work in??? Look at all the x86 / x64 software already in existence.
This is just re-invention of the wheel.
ARM works well here because a loss leader like a phone needs to be as cheap as possible in hardware, the money is made on the contract / after the hardware sale.
With all due respect, they are talking about banking systems, utility company systems etc; you can't just sit at a screen and write code, there is design, code, test and integrate phases, plus all the quality control.
In 2011, Micro Focus claimed that 1.5 million lines of Cobol were being written per day. Tools must help, but there is still a huge legacy of code to maintain and enhance; Micro Focus' share price has ramped up over the last five years; they must be very busy.
We've already had Windows ARM a few years ago. The original Surface was made both ways. It didn't take off. Maybe one day, but this isn't new. This is an attempt to try it again.
The ARM equipped devices will be running full Windows 10, so no desktop apps are left behind, unlike the previous time that Microsoft attempted this. The ARM chips at the time offered much less performance as well, so this time around, it should be a much better experience. Universal Windows Apps will be available compiled for ARM directly, but x86 apps will run in emulation, which is still a cause for concern for both performance and battery life, so we’ll have to see how that pans out. Microsoft has an “optimized” version of Office 365 for the new ARM powered PCs, which likely means it’s been recompiled for native performance.
We've already had Windows ARM a few years ago. The original Surface was made both ways. It didn't take off. Maybe one day, but this isn't new. This is an attempt to try it again.
Edit:
The biggest issue they had before, and will remain an issue, is all the legacy software will not work. Most software designed for current PC's will not work. They have to either write using high level code that will work for both and not as efficient, or they have to have to write code for both versions. This led to problems with adoption last time, and will likely make this a very tough sale for a while into the future.
I'm not entirely sure if that will change much. It requires a persistent online connection while in use. And was it really tied to the store, or was that the only place to find existing software that worked for it?I think thats small potatoes, what really held the old ARM version /windowsrt back was the fact that it was locked down. Windows store or bust and that sucked hard.