Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Working in microprocessors, I hear this a lot, but, in the long run, Intel has a fundamental advantage over ARM, and ARM doesn't seem to have a fundamental advantage over Intel [1].

People talk about RISC vs. CISC, and how ARM can be lower power because RISC instructions are easier to decode, but I don't hear that from anyone who's actually implemented both an ARM and an x86 front-end [2]. Yes, it's a PITA to decode x86 instructions, but the ARM instruction set isn't very nice, either (e.g., look at how they ran out of opcode space, and overlayed some of their "new" NEON instructions on top of existing instructions by using unused condition codes for existing opcodes). If you want to decode ARM instructions, you'll have to deal with having register fields in different places for different opcodes (which uses extra logic, increasing size and power), decoding deprecated instructions which no one actually uses anymore (e.g., the "DSP" instructions which have mostly been superseded by NEON), etc. x86 is actually more consistent (although decoding variable length instructions isn't easy, either, and you're also stuck with a lot of legacy instructions) [X].

On the other hand, Intel has had a process (manufacturing) advantage since I was in high school (in the late 90s), and that advantage has only increased. Given a comparable design, historically, Intel has had much better performance on a process that's actually cheaper and more reliable [3]. Since Intel has started taking power seriously, they've made huge advances in their low power process. In a generation or two, if Intel turns out a design that's even in the same league as ARM, it's going to be much lower power.

This reminds me of when people thought Intel was too slow moving, and was going to be killed by AMD. In reality, they're huge and have many teams working a large variety of different projects. One of those projects paid off and now AMD is doomed.

ULV Haswell is supposed to have a TDP ~10W with superior performance to the current Core iX line [4]. Arm's A15 allegedly has a TDP of ~4W, but if you actually benchmark the parts, you'll find that the TDPs aren't measured the same way. A15 uses a ton of power under load, just like Haswell will [5]. When idle, it won't use much power, and will likely have worse leakage, because Intel's process is so good. And then there's Intel's real low power line, which keeps getting better with every generation. Will a ULV version of a high-end Intel part provide much better performance than ARM at the same power in a couple generations, or will a high performance version of a low-power low-cost Intel part provide lower power at the same level of performance and half the price? I don't know, but I bet either one of those two things will happen, or that new project will be unveiled that does something similar. Intel has a ton of resources, and a history of being resilient against the threat of disruption.

I'm not saying Intel is infallible, but unlike many big companies, they're agile. This is a company that was a dominant player in the DRAM and SRAM industry that made the conscious decision to drop out the DRAM industry and concentrate on SRAMs when DRAM became less profitable, and then did the same for SRAMs in order to concentrate on microprocessors. And, by the way, they created the first commercially available microprocessor. They're not a Kodak or Polaroid; they're not going to stand idle while their market is disrupted. When Toshiba invented flash memory, Intel actually realized the advantage and quickly became the leading player in flash, leaving Toshiba with the unprofitable DRAM market.

If you're going to claim that someone is going to disrupt Intel, you not only have to show that there's an existing advantage, you have to explain why, unlike in other instances, Intel isn't going to respond and use their superior resources to pull ahead.

[1] I'm downplaying the advantage of ARM's licensing model, which may be significant. We'll see. Due to economies of scale, there doesn't seem to be room for more than one high performance microprocessor company [6], and yet, there are four companies with ARM architecture licences that design their own processors rather than just licensing IP. TI recently dropped out, and it remains to be seen if it's sustainable for everyone else (or anyone at all).

[2] Ex-Transmeta folks, who mostly when to Nvidia, and some other people whose project is not yet public.

[3] Remember when IBM was bragging about SOI? Intel's bulk process had comparable power and better performance, not to mention much lower cost and defect rates.

[4] http://www.anandtech.com/show/6355/intels-haswell-architectu...

[5] Haswell hasn't been released yet, but Intel parts that I've looked at have much more conservative TDP estimates than ARM parts, and I don't see any reason to believe that's changed.

[6] IBM seems to be losing more money on processors every year, and the people I know at IBM have their resumes polished, because they don't expect POWER development to continue seriously (at least in the U.S.) for more than another generation or two, if that. Oracle is pouring money into SPARC, but it's not clear why, because SPARC has been basically dead for years. MIPS recently disappeared. AMD is in serious trouble. Every other major vendor was wiped out ages ago. The economies of scale are unbelievably large.

[X] Sorry, I'm editing this and not renumbering my footnotes. ARMv8 is supposed to address some of this, by creating a large, compatibility breaking, change to the ISA, and having the processor switch modes to maintain compatibility. It's a good idea, but it's not without disadvantages. The good news is, you don't have to deal with all this baggage in the new mode. The bad news is, you still have the legacy decoder sitting there taking up space. And space = speed. Wires are slow, and now you're making everything else travel farther.



The 10W chip will be a weaker SKU, probably even weaker than current 17W IVB CULV chips. They are not magically lowering the TDP from 17W to 10W for the next generation.

Cortex A15 will get the benefit of pairing up with A7. ARM says on average the energy consumption should be about half, compared to Cortex A15 alone.

Also Haswell is rumored to cost 40% more than an IVB Core. That's close to $300 for a CULV. That's simply not sustainable when it comes to the new market that is forming for tablets. $300 is more than the whole BOM for your typical $500 tablet. I doubt you'll see that chip in anything cheaper than $800, at a time when you get "good enough" tablets for $200 whole. Intel's competitor to ARM simply isn't the Core line-up. It's Atom, for better or for worse.

And as I said, Intel will lose not because of lack of expertise in making chips, but because of an unsustainable cost structure and business model (they now have to compete against several ARM chip makers at once, including Apple). The fact that they also have no momentum or market share in the mobile market doesn't help.


>Also Haswell is rumored to cost 40% more than an IVB Core. That's close to $300 for a CULV. That's simply not sustainable when it comes to the new market that is forming for tablets. $300 is more than the whole BOM for your typical $500 tablet. I doubt you'll see that chip in anything cheaper than $800, at a time when you get "good enough" tablets for $200 whole. Intel's competitor to ARM simply isn't the Core line-up. It's Atom, for better or for worse.

In terms of OS for an x86 tablet, you're looking at Windows 8, or Linux with a custom shell, and that's it. There's an unofficial x86 port of Android, but I wouldn't stake any real product on that without any support from Google.

Since MS has already established the baseline price for the Win8 tablet around $800, and they're marketing it more as a tablet PC that can do everything you do with a normal desktop or laptop than an iPad, is this really that much of an issue?


There is an official port of Android(done by Intel) on x86, it powers the several Atom phones out there(Orange San Diego & etc). You can even download an emulator build for Atom, which perform great(it has support for virtualization extensions).


The first gen Google TV platforms (Sony Bluray player, Logitech Revue) were also x86 based.


The real issue for intel is 7W is not worth 100$ to most consumers. OEM's have been selling good plenty of 400$ laptops for a while and tablet manufactures can always down-clock a laptop CPU from AMD.

However, this is the reason Microsoft is trying to stick to the 800$ price point for as long as it can. Cheaper options are more popular and they don't want most people to hear how 'crap' Windows 8 tablets are based on hardware anytime soon.


>The real issue for intel is 7W is not worth 100$ to most consumers. OEM's have been selling good plenty of 400$ laptops for a while and tablet manufactures can always down-clock a laptop CPU from AMD.

This is the kind of logic that says selling one million of $1 products is better than selling 100.000 of $10 products. I beg to differ...


The number of units sold is capped by the market size. If someone else is selling $1 devices and you are selling $10 but the $1 device meets the need, you won't be selling much. Microsoft/Intel might bank on those markets being "distinct" - but that's getting more tenuous each year.

The markets compact over time and $1 devices will kill $10 devices.


Overlaying instructions on top of each other by using different address-mode or condition flags isn't new - I remember 68K doing it nearly 30 years ago - and it's not that hard to deal with. I don't think the argument about ARM being harder to decode carries much water, though some of your other arguments are more compelling.


His argument, by my reading at least, isn't that ARM is harder to decode, just that it isn't that much easier.


Displacing Intel's base != disrupting.

Innovators dilemma raises the question "will market demand shift to products where ARM has already displaced x86? (i.e. mobile and tablets)"


"6] IBM seems to be losing more money on processors every year, and the people I know at IBM have their resumes polished, because they don't expect POWER development to continue seriously (at least in the U.S.) for more than another generation or two, if that. Oracle is pouring money into SPARC, but it's not clear why, because SPARC has been basically dead for years."

both IBM and Oracle have committed to two more generations of POWER nor SPARC. also there is Fujitsu keeping investing into SPARC. these uarchs are not going to go away anytime soon. they are high-margin niche products in the enterprise space and government with considerable footprints and huge long term service contracts attached to them.

POWER and SPARC are not competing against low-power CPU's but aim for the high-socket count, large unified memory, RAS market which for some workloads is the only alternative.

especially SPARC while having shrinking market share still makes Oracle more than a billion annually. afaik IBM's Power division is not loosing money either.

long story short: in the next five years there will be at least four ISA's (ARM, SPARC, POWER, X86) in the server space, but not all compete for the same markets.

interesting times ahead!


[x] Isn't is possible to have your code base compiled soly for AMRv8 and leave the baggage and compatibility behind in one or two revisions. I am guessing Apple may be able to pull this off with a pure ARMv8 advantage.

I continue to hear how MIPS is still technically and architecture better then even the cleaner ARMv8. But they never succeed. So how an ISA succeed depends on a lot of other factors/


I'd like to point out that armv8 (the 64-bit version of arm) fixes basically all of the decoding issues of arm. It's really more of an entirely new isa than just an extension of old arm, and it ended up as a really clean and good high-performance isa.


Isn't it possible to have a Pure ARMv8 SoC? And leave all the old things behind?


Intel's problem is the technology, it is their business practices. ARM is all about customization, and Intel is about commodity motherboards. Intel has restricted every item that might give one PC manufacturer an advantage (e.g. no custom chipsets).


This is missing the point. The third party chipset market died off for exactly the same reason that you posit: all the features that were in the "chipset" are now in the SoC.

So what you seem to be saying is that ARM only makes CPU cores (and now a GPU, I guess), so there's a wide market available for NVIDIA and Qualcomm to enter to provide a complete SoC.

Intel, on the other hand, makes CPU cores, and GPUs, and display controllers, and DRAM controllers, and USB controllers, and PCI bridges, and audio hardware. And they put all that stuff on a single chip for their customers.

... and somehow you're spinning this as an advantage for ARM Ltd.?


No, the third party chip chipset market died because Intel killed it. NVIDIA had a superior chipset with a better GPU and Intel stopped them. Intel wants commodity production of a very limited number of designs.

Intel doesn't want customizations that can be offered by other companies. Intel wants Intel's GPU not a choice of NVIDIA, S3, ARM, and soon AMD/ATI. Intel wants to ship "Phone Motherboard 1", etc.

Its an advantage because ARM lets other companies play and Intel won't.


This is still spinning. What you're saying is still isomorphic to: ARM has an "advantage" because it's a smaller company with fewer product offerings and no ability to fab its own chips. That's just insane. ARM Ltd. (the company) is successful in spite of these facts, not because of them.

Maybe what you're really trying to talk about is the "ARM ecosystem", where the big mix of players has a market incentive to try new stuff. And there you might have a point. But it's certainly no disadvantage to Intel specifically -- every one of those players wants to be doing what Intel already is (Apple is very close already, with their own CPU core and SoC design).


'ARM has an "advantage" because it's a smaller company with fewer product offerings and no ability to fab its own chips.'

I think what he's saying is Intel is at a disadvantage because it's the only company with the ability to fab its designs. Therefore, any new designs will have to compete for production capacity and catalog space with whatever the currently most-profitable product is.

Large companies have great difficulty managing multiple product lines that diverge widely in their natural profit margin.


Didn't really think of that, but you are right.

I was saying Intel doesn't want any customization because it needs volume and price to maintain profits. Customization subtracts from volume. They have PC mentality not a Mobile mentality. Power consumption isn't the problem, but business model is.


The point of the article is that intel has been disrupted by ARM. You can disagree with this or not, but all these points are kind of irrelevant. People making mobile devices care about power efficiency, and Intel is behind for another year or two. Worse, even if it catches up it needs to compete with ARM's business model which cannot support Intel's revenue model. The point is that ARM allows — as you say — anyone make their own SoC and drain the profits from Intel's pool — they're not going to give that up unless Intel offers some incredibly compelling advantage, and it's not clear what that might be.


>The point of the article is that intel has been disrupted by ARM.

Has it?

Intel is a much smaller part of all CPU's sold, that's true, but it's also true that the market for CPU's has increased exponentially in the last few years. The places where Intel is losing is places where they have never actually competed in.

A decade ago, if you were looking for a low-power CPU for a mobile device, you sure as hell weren't looking at X86. You were going with an ARM solution. That hasn't changed, but the market for those CPU's has grown incredibly.


The difference is, a decade ago something like this couldn't exist:

https://www.google.com/intl/en/chrome/devices/samsung-chrome...

And it should scare the hell out of Intel.


Intel actually did license ARM tech at one point with their XScale chips. It also wouldn't matter if they never competed in the phone market before, because the phone and tablet market is eating away at the desktop/laptop market already. People are probably more likely to want a flashy new phone or tablet, than upgrade their desktop or notebook.


I'm not spinning, and no ARM's size isn't an advantage (I didn't say it was).

Intel wants to build everything in volume. Intel's current business model does not benefit from specialization or customization. Intel needs to make a large profit on each CPU sold. Intel drove out of the market anyone who could build a chipset since it interfered with volume and profits. Intel would be happiest with their current business model if they built one laptop motherboard, one server motherboard, and one desktop motherboard.

This is a strategy built for the PC market. It does not have anything to do with the current mobile market (non-laptop).

Samsung and Apple want to build the best end product. They want to put things in and leave things out. They cannot do that with Intel, but can do that with ARM. Intel doesn't allow or want customized SoC. Apple and Samsung do. Other vendors also make their own SoC from ARM cores. These SoCs provide different benefits. Having a common instruction set allows switching to another SoC when needed.


> Intel wants Intel's GPU not a choice of NVIDIA, S3, ARM, and soon AMD/ATI.

I haven't seen any sings of Intel trying to push their GPU's into ATI/NVidia's niche market (gamers).

NVidia and ATI (now AMD) GPU's have always had their strongest consumer base among gamers [1]. Intel GPU's have never been in the same class as their contemporary NVidia/ATI cards on any measure -- triangles per second, texture bandwidth, gigaflops. Intel also generally uses shared-memory architecture, which means their memory bandwidth is limited and contends with the CPU.

Intel's GPU's are focused on being a low-cost, low-power, on-board graphics solution. As long as they can run a 3D UI and play HD video, they're not going to push the performance envelope any more, for the good and simple reason that they don't want to incur additional manufacturing cost, chip area, design complexity and power consumption for features that are irrelevant to non-gamers.

[1] By "gamers," I really mean anyone who's running applications that require a powerful GPU.


I completely agree with performance per watt Intel is on the path to be where they need to be but ARM is on path to be par with a chip that even AMD's x86 offerings can't touch on a core by core basis. Now with Microsoft's Windows 8 trying it's very best to be a tablet experience it seems by sales figures people much rather prefer an Android or Apple tablet compared to even i5/A10 laptops with Windows 8. The technicalities you present are right on the money but what we have here is a perfect storm. Microsoft wants to be a tablet OS manufacturer and is skirting the traditional desktop/laptop experience leaving Intel with no real face value to their contribution.

When people go to their local stores and see rows of tablets that look like tablets and rows of laptops that look like tablets and rows of desktops that look like tablets, well they just seem to get actual tablets. Sure an Intel i3 will handily beat out the upper echelon of ARM offerings but with Android and IOS be entirely optimized for this experience we are finally realizing what AMD fans have been shouting for decades, the extra horsepower really does not come into effect often enough to make it a deal breaker. Your web page may load 40% slower on an ARM rig but when the Intel model will load it in 1.5s and you tablet will load it in 2s we now experience the Law of Diminishing Returns. If a dual core ARM A15 can consistently run at around 40-50% of the speed of an i3 mobile processor, a quad core ARM should settle at around 60-75% while being tasked to do much, much less.

With Intel and ARM you are also dealing with 2 very different ecosystems. x86 has had to be fast because most of the applications you will run on a daily basis are likely not really optimized, profiled or threaded anything above a couple compiler switches. They have to be fast because the code is so slow. Now with Android and IOS the language, libraries and sand-boxing improves the underlying mechanisms to the degree that most of the code that matters is optimized by Apple and Google where the equivalent Microsoft Windows libraries are not as optimized and in many cases so specialized that it gives a look and feel of a Wordpad type app rather than what you are really after.

Basically I feel by looking strictly at Intel's raw performance as to the reason why a platform will succeed is improper and an unfair comparison. People are moving en-mass to tablet and smart phone ecosystems not because they are faster or run by a particular processor but because it feels like a custom solution and the integration overall is acceptable. So I don't think it is ARM v Intel but rather tablet v notebook and laptop. If Microsoft keeps up with making their desktop OS look and feel like a tablet OS people buy tablets and Windows 8 doesn't have the applications, word of mouth or market penetration to make that possible right now.

If things don't change and quick we may just have a Microsoft and Intel "Double clutch"

"Double clutch: this is where a non-swimmer ends up in deep water and, out of panic, grabs the closest person to them to stay afloat." http://www.firstaid-cpr.net/lifeguarding/minor_major.html


>x86 has had to be fast because most of the applications you will run on a daily basis are likely not really optimized, profiled or threaded anything above a couple compiler switches. They have to be fast because the code is so slow. Now with Android and IOS the language, libraries and sand-boxing improves the underlying mechanisms to the degree that most of the code that matters is optimized by Apple and Google where the equivalent Microsoft Windows libraries are not as optimized and in many cases so specialized that it gives a look and feel of a Wordpad type app rather than what you are really after.

This is so wrong, I actually don't know where to begin.

1. It's true that most code isn't optimized for x86. But most code isn't optimized, period. Optimization is freaking hard. Android and iOS aren't necessarily better optimized than Windows. And Linux, especially RHEL, is screaming fast on the new Intel chips. Windows isn't that terrible, either.

2. Sandboxing actually hurts performance, because it requires an additional layer between the OS and userland to make sure that the code the user is executing is correct.

3. None of this actually matters for chip architecture, since #1 is true of code in general, and #2 doesn't have any special architecture-based support.

4. x86 isn't just Windows. It's Linux, too.


Let me clarify.

When you program for Android/IOS how much of the logic you write is referenced from optimized libraries and how much is your own craft? Now look at the entire Market Place / App Store and figure how many of those apps entirely rely on Android / IOS optimized libraries.

While it may be true that some may wander off the beaten path and write their Apps in OpenGL ES directly and maybe even C/C++ most rely on frameworks and libraries already built in (which are indeed optimized).


You're still running on the blind assumption that Apple and Google are magically better at optimization than everyone else. I would not make that assumption, because, as I said before, optimization is hard. There's a billion variables that goes into your code's performance, and tiny changes can completely ruin performance-or make it awesome.

Look at Android(as an example). For the first few years of existence, the OS was plagued with issues of bad battery life due to poorly optimized code and bugs. Android 3.0 was basically scrapped as an OS due to bad performance.

iOS 5.0 had absolutely horrible battery life due to a bug. The Nitro Javascript engine isn't available outside of Safari, too.


So you are suggesting that it is out of reach for Google and Apple to publish libraries and frameworks that are optimized for a specific hardware platform (ARM A7 + A15) or is it that since Windows X already optimizes Intel / AMD offerings to an overwhelming extent that the differential would be moot?


It's out of reach for anyone - Google, Apple or Microsoft - to optimize their libraries enough to make up for CPU performance differences.


The only data point I can think of is this JSON benchmark:

http://soff.es/updated-iphone-json-benchmarks

...where Apple beats three community-developed libraries. But maybe it just wasn't that hard to beat them.

I'm also skeptical because I don't see how Apple has any incentive to optimise code ever. Their devices (ARM & x86) are doubling in CPU power left and right while the UX basically stays the same. The second-to-last generation inevitably feels sluggish on the current OS version...which just happens to be the time when people usually buy their next Apple device. Why should they make their codebase harder to maintain in that environment?


Look at https://github.com/johnezang/JSONKit, which is fast.


>...where Apple beats three community-developed libraries.

That's just in one very restricted area (JSON parsing) where there are TONS of third-party libraries of varying quality for the exact same thing. Doesn't mean much in the big picture.

>I'm also skeptical because I don't see how Apple has any incentive to optimise code ever.

And yet, they use to do it all the time in OS X, replacing bad performing components with better ones. From 10.1 on, each release actually had better performance on the SAME hardware, until Snow Leopard at least. They had hit a plateau there I guess where all the low hanging fruit optimisations were already made.

Still, it makes sense to optimise severely, if not for anything else to boast better battery life.


> Still, it makes sense to optimise severely, if not for anything else to boast better battery life.

No doubt about 10.0-10.5/10.6. But that seems to have been an afterthought for the last two OS X releases:

http://www.macobserver.com/tmo/article/os-x-battery-life-ana...

And has there ever been an iOS update that has made things faster on the same hardware?

I don't think that Apple is intentionally making things slower, which is what I'm trying to say with the JSON parser (it is easy to write a wasteful implementation). But in the big picture, they're not optimising much either.


How is this any different on Android/iOS than it is on Windows/Linux/Mac?


>"When you program for Android/IOS how much of the logic you write is referenced from optimized libraries and how much is your own craft?"

It doesn't matter either way.

For one, Apple and Google aren't that keen on optimising their stuff either.

Second, most desktop applications use libraries and GUI toolkits by a major source, like Apple and MS, so the situation regarding "a large part of the app is made by a third party that can optimise it" is there for those too.

Third, tons of iOS/Android apps use third party frameworks, like Corona, MonoTouch, Titanium, Unity, etc etc, and not the core iOS/Android framework.

Fourth, the most speed critical parts of an app are generally the dedicated stuff it does, and not the generic iOS/Android provided infrastructure code it uses.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: