Intel Confronts a Big Mobile Challenge: Native Compatibility

smaxp writes: "Intel has solved the problem of ARM-native incompatibility. But will developers bite? App developers now frequently bypass Android's Dalvik VM for some parts of their apps in favor of the faster native C language. According to Intel, two thirds of the top 2,000 apps in the Google Play Store use natively compiled C code, the same language in which Android, the Dalvik VM, and the Android libraries are mostly written.

The natively compiled apps run faster and more efficiently, but at the cost of compatibility. The compiled code is targeted to a particular processor core's instruction set. In the Android universe, this instruction set is almost always the ARM instruction set. This is a compatibility problem for Intel because its Atom mobile processors use its X86 instruction set."

Comments

Ha ha

[Anonymous Coward]

Can I just say that I remember people moaning about the ARM not being x86 compatible when it came out in '87 or thereabouts.

(Yes, am I that old.)

Re:Ha ha

[BasilBrush]

I'm lots older than that, and I don't remember any such complaints. Because originally the ARM chip was made only for the Acorn Archimedes. Which sold to people who certainly didn't want a PC clone. Later it started to be used as the CPU in PDAs, printers and mobile phones. None of which would have benefited at the time from Intel compatibility.

Issues with ARM not being x86 compatible are a recent thing.

Maybe there were complaints in the hobbyist Linux-everywhere crowd before there was an ARM port of Linux?

Re:Ha ha

[Wdomburg]

More to the point, the problem is that x86 is not compatible with ARM. And it's pretty much just a problem for Intel. So not really a problem at all.

Re:Ha ha

[Darinbob]

At this point, the tables are reversed, since what the actual Android users want is ARM compatibility, and x86 is the odd man out.
However, even in the ARM universe the compatibility is murky as there are so many varieties; straight up ARM, thumb, thumb-2, Jazelle as the basic instructions sets, plus some models that have multiply instructions, some have DSP instructions, and so on. Most of the Androids though presumably come with high end Cortex-A series and enough memory to use 32-bit ARM instructions which simplifies it.

They should have just done the whole thing in Forth, which can be faster than many VMs, low level enough to do everything you want, time tested and proven, and with optional nonportable escapes to assembler for special system operations.

Re:Ha ha

[dbIII]

I'm sure I saw a BBC micro with an ARM chip in it some time before then.

Fsck x86

[Anonymous Coward]

I like compatability, but I've had it with x86. Let ARM hog the limelight for a while, no reason it shouldn't have its fifteen minutes. And let x86 die, it's way past its BBE date and has outstayed its welcome by several generations.

Re:Fsck x86

[Anonymous Coward]

This person is likely in their 20s, I am assuming early 20s. With that said, I am in my 30s, somewhat early. My first PC was an 8088 and I've deep dived into every modern processor since then. Even with the debacle that was Windows 7 and 8, I am still going to stand behind x86 as a great architecture that can stand the sands of time.

Scalability: What other architecture has scaled so far that it was completely decimated two competing architectures from the past and the future at the same time. The original 8088/86 was 3mhz, the latest x86 offering is 4ghz.

Popularity: Both Apple and Sun saw the writing on the wall, Sun saw it too late, Apple saw it early (or saw what happened to Sun). They both shifted from a proprietary processor and chipset to a more common and popular platform. Both platforms had specific benefits over x86 until x86 scaled far and beyond what they both offered.

Backwards Compatibilty: I know my x86 processor is still going start in 8-bit mode and I know that I can put it in 16bit mode and run my 1992 applications. But to that extent, x86-64 just extends the instruction set. eg ARM32 does not play on ARM64.

Let's face it. I witnessed Y2K. I witnessed every weak architecture under the sun get wiped out because it had shortcomings. Intel designed the best architecture with x86 and naysayers generally harp because it's "too big". I, for one, plan to teach my children x86 ASM so they understand the basics.. then let them find MIPS or ARM or whatever-fad-arch-is-current so they too can appreciate the design of x86.

Re:Fsck x86

[lagomorpha2]

I, for one, plan to teach my children x86 ASM so they understand the basics.. then let them find MIPS or ARM or whatever-fad-arch-is-current so they too can appreciate the design of x86.

This is just a guess but you don't actually have children yet, do you?

Re:Fsck x86

[PhrostyMcByte]

ARM has already had its 15 minutes, just like AMD's Athlon did.

There's a good possibility that Intel will wipe the floor with all the ARM offerings. Maybe not with this generation of CPUs, maybe not the one following it, but they've got the best fab in the world and extremely smart people using it.

They've been actively focusing on increasing power efficiency for a number of years now, so I have no doubt they'll be able to bring strong competition.

Re:Fsck x86

[Anonymous Coward]

You have no concept. Many companies, including Intel, have tried to move away from x86 - the market won't let them. There is too much software out there written to the x86 architecture to move away from it. You are completely underestimating the market forces behind x86.

Staying with x86 is *not* Intel's choice, of even their desire (they have tried to shift the market off x86). This is where real world forces/issues trump ivory tower technical perspectives.

Re:Fsck x86

[Anonymous Coward]

Backwards Compatibilty: I know my x86 processor is still going start in 8-bit mode

x86 never had an 8 bit mode.

But to that extent, x86-64 just extends the instruction set. eg ARM32 does not play on ARM64.

all the information i've seen says that 64-bit arm chips can run 32-bit arm mode at least in user mode (not sure about kernel mode)

Re:Fsck x86

[Anonymous Coward]

>What other architecture has scaled so far that it was completely decimated two competing architectures from the past and the future at the same time.

Doesn't mean the architecture isn't a sprawling pile of shit with shit tacked on of other shit on top of older shit.

Re:Fsck x86

[gbjbaanb]

x86 is good in the same way that a modern police baton is good - its still a stick you hit people with, and serves its purpose. But there are better weapons available.

So saying that x86 is great because technology has had to improve to make up for its deficiencies is just stupid. x86 isn't some wonderful architecture, putting 4 cores on a single die isn't anything that x86 made happen that others couldn't do, fabrication techniques that shrunk the die size isn't anything to do with x86 either.

Think that a motorola 68000, way back in the day was better than the old 286s it compared to. Imagine that the 68000 took off instead of the 286 - if MS and IBM had built DOS for 68000 instead of x86... today we'd be in pretty much the same position but with a different chipset. But it would be faster and cheaper and more efficient.

BTW x86 32-bit doesn't run on x86_64 either. The software and chips have emulation routines that allow it to happen. The same as happens with A64 that allows old A32 and T32 instructions to still run on the same chip.

Re:Fsck x86

[dave420]

Windows 7 was not a debacle. ME & Vista, fair enough, but not 7.

Re:Fsck x86

[Anonymous Coward]

I do (I am the person you are replying to), I have a 2 year old and another on the way. Yes I know my children may not find programming computers to be interesting.. but it is a geek father's hope isn't it?

Re:Fsck x86

[ericloewe]

Blind hate for an instruction set. Brilliant. /s

Re:Fsck x86

[Anonymous Coward]

Aye, and ARM is new hip and fresh without all the cruft right? ARM also doesn't scale nicely, so we should use ARM until we have something else that is better than ARM and then we migrate everything to that platform right? Because everyone will jump ship at the same time and we will never need to support multiple platforms. I mean it worked for Amiga so it should work for ARM right? Oh wait...

What can we replace x86 with, today, that won't also turn into a sprawling pile of backwards compatible shit?

Re:Fsck x86

[K. S. Kyosuke]

ARM also doesn't scale nicely

You figured that out...how exactly? It's a RISC, RISCs have historically scaled very, very well.

Re:Fsck x86

[Anonymous Coward]

As always, it's more complicated than that.

The zealous ARMists are mostly those people who bought AMD during the speed-wars of the 90's. Intel won, and they can't stand that. ARM is their next hope for trying to get revenge on Intel (even though Intel is more than capable of optimizing ARM designs and fabricating them at half the size of any competitor). The minor fact that Intel's Atom line had surpassed ARM at every benchmark except the "power consumption when doing nothing" in 2012 does not in any way alter their firmly held belief that ARM is infinitely efficient and the future of computing.

Re:Fsck x86

[K. S. Kyosuke]

x86 is good in the same way that a modern police baton is good - its still a stick you hit people with, and serves its purpose. But there are better weapons available.

So Intel is essentially crying "Don't ARM me, bro!"...? ;-)

Re:Fsck x86

[drinkypoo]

You figured that out...how exactly? It's a RISC, RISCs have historically scaled very, very well.

What does that even mean any more? Visibly-CISC processors are now internally-RISCy (All of them since Am586) and there is actually a benefit to be derived from variable-length instructions and the x86 decoder is a small portion of the modern CPU. But ARM cores have never gotten up into the big, big clock rates because they've never been designed for them, instead targeting efficiency. That's a much easier goal to reach than bigger shinier if you're on a constrained budget, and it certainly has paid off for them now that we care about power budgets, but they're still having trouble scaling.

I'd sure like to hear anything insightful anyone has to say about XScale. It was the fastest ARM implementation of its day, but it was also the most power-hungry, and AFAICT Intel never really managed to scale either performance up or power consumption down after their initial release, and then dropped it. Is that how it played out?

Re:Fsck x86

[aethelrick]

ARM is massively dominant in the embedded and mobile markets. These markets make up a vast quantity of electronics gear. Intel (the X86 pushers) even make ARM chips. ARM is starting to make in-roads into larger devices and encroach on traditional Intel/X86 stomping grounds. ARM have plans for servers and PC's running with their chips. They are low cost, low power and quite good at what they do. Admittedly they won't be replacing your PC gaming rig any time soon, but they're not chasing that market (yet). You are sadly unaware of just what ARM is if you think it's had it's "15 minutes" it's just getting started at the edges of the PC market, it's backed by many vendors and I for one think it'll be around for a while yet. Look at the market share tablets have stolen from the PC, they are mostly ARM powered. Sure netbooks seem a little crusty, and havn't had the uptake their manufacturers were hoping for, but ARM server gear is taking off. Also the IT nippers are playing with ARM with their Arduino and Raspberry Pi gear. I wouldn't count ARM out just yet. Hell, I just replaced my decade-old trusty Linux server at home with a Wandboard Quad running Arch Linux for ARM. Guess what, it works really well, as a Samba, Backup and Email server for the family and I'm not even an ARM enthusiast, it was just MUCH cheaper than a regular Intel or AMD replacement and perfectly up to the task.

Re:Fsck x86

[AcidPenguin9873]

Can you name several reasons why the x86 ISA has a negative impact on your computing experience?

Re:Fsck x86

[OneAhead]

First of all, at this point, it is misguided to talk about x86 as an architecture; there is generally little or no architectural overlap between two x86 processors that are a few generation apart. x86 is an instruction set, or even more correct, a family of instruction sets. The distinction is important, especially in the age of complex instruction decoders; a lot of the more complex x86 instructions are internally decoded into smaller pieces, and one could say that the CPU internally runs its own, different instruction set. The fact of supporting a certain instruction set nowadays says almost nothing about the underlying architecture.

So we're talking about an instruction set. One that was conceived in an age where manual coding in machine language was far more common than it is today; the original x86 instruction set was designed to be easy for a human bitpusher to handle, whereas newer instruction sets like ARM are more geared to get the most out of a decent optimizing compiler. What followed for x86 was extension upon extension, and the instruction set is now so byzantine that x86 is a very difficult market to break into; the design complexity of the decoder can probably be overcome, but all the cross-licensing between Intel and AMD cannot. The complex, organically-grown instruction set also leads to some waste of silicon in having to support all those instructions, and waste of performance/energy efficiency in that the instruction set is not designed from the ground up towards efficiency. People on the x86 side make a compelling argument that this has become negligible, but the fact remains that I'm still not seeing any x86 processor getting (unbiased) performance/W scores that are close to common ARM processors.

My first computer contained a Z80, a true 8-bit processor (your claim that x86 has 8-bit mode is false; the lowest common denominator for x86 is the 16-bit 8086, which you're probably confusing with the 8-bit 8080 which is not x86 compatible). More relevantly, I also have experience running scientific workloads on a whole zoo of processors. I have particularly fond memories of the later Alphas, which wiped the floor with everything up until and including the Pentium 4, and were very competitive even against Athlon 64 and Core2 performance-wise (but not price-wise). Repeat after me: x86 has zero inherent architectural advantage!!! The big advantages it has is (1) economies of scale and (2) the higher profits of a mass market that generate more revenue to be pumped into R&D. There hasn't been a kid on the block that could compete on these fronts - not until ARM came around.

While Intel is sitting on an impressive pile of cash and R&D potential, their attempts to match ARM in performance/W are so far unsuccessful when looking at non-biased benchmark results, and ARM has profited from this in establishing a mass market of its own. Things are about to get interesting from here onwards. I can't predict whether x86 or ARM will win. The outcome might be coexistence, with x86 keeping its dominance in the server room, workstation, office and hard-core gaming, and everything else becoming ARM. Whatever the outcome might be, I am firmly rooting for ARM, though. Technically, it's leaner, more rationally designed instruction set that is more frugal with resources (die size, cache & memory usage) and better reflects present-day usage cases. And the fact that it's relatively straightforward for a newcomer to license it and start making chips will bring some healthy competition onto the stage.

Re:Fsck x86

[ezelkow1]

then let them find MIPS or ARM or whatever-fad-arch-is-current so they too can appreciate the design of x86.

Mips and arm as fads? You do realize mips has been around almost as long as x86 has, and is still widely used. People all too often forget that the majority of devices out there are not full fledged computers, they are embedded devices, to which mips and arm own the space. This is exactly why mips is still widely taught in colleges as it is readily accessible, open, and still used in the industry. It also gives a good foundation to build on when looking at other ISAs

Re:Fsck x86

[the_B0fh]

What kind of nonsense are you spouting? Every processor out there with the exception of that one open sourced one, *IS* proprietary! *YOU* go try and make an x86 and see if Intel sues the pants off you.

You also don't understand what scalability and all the other big words mean. You don't even know that your Intel processor is now effectively a RISC core with a CISC layer of microcode on top.

And who the hell cares if you can run 8bit or 16 mode shit? Those were all design inefficiencies and now you are fucking bragging about it? What an idiot.

Re:Fsck x86

[K. S. Kyosuke]

What does that even mean any more? Visibly-CISC processors are now internally-RISCy (All of them since Am586)

How is that relevant to the issue I was commenting on? That doesn't make ARM scale worse, that makes x86 scale better, doesn't it?

and there is actually a benefit to be derived from variable-length instructions and the x86 decoder is a small portion of the modern CPU

Sure, if you're cranking out single thread performance. Which may not be the best thing to do in all application areas, though. Especially if you're doing something like ARM's big.LITTLE configuration, where you may not want the LITTLE cores to have complicated instruction decoders - to keep them actually simple - but you still need them to support the same ISA, otherwise you'd have to use fat binaries and you wouldn't be able to move threads between the cores (not without huge hassles at least).

Re:Fsck x86

[Anonymous Coward]

Imagine that the 68000 took off instead of the 286 - if MS and IBM had built DOS for 68000 instead of x86... today we'd be in pretty much the same position but with a different chipset. But it would be faster and cheaper and more efficient.

[Citation needed]

Re:Fsck x86

[the_B0fh]

Wow. A factual followup. Wish I had mod points.

Re:Fsck x86

[BitZtream]

Why?

LONG mode x86-64 works out most of the major 'problems' with x86 from a programmers perspective. Thanks AMD! ARM has its own set of silliness that devs at the assembly level have to deal with (For reference, I fluently speak x86, ARM, and ATmega ASM).

Furthermore, x86-64 is a language the rides on top of the core, the core doesn't actually speak x86 in pretty much any x86 processor, it has a translation unit in front of it that breaks the CISC instructions up into more RISC like ones for the core.

I wouldn't put it past Intel to put an ARM translation unit in front of their cores with little effort, performance wouldn't be 100% identical but it already isn't across different ARM cores so thats probably not really that large of an issue.

Other than 'its old', do you have an actual insightful reason that x86 needs to die or are you just spouting something you heard some one else say a long time ago without understanding at all why they said it?

Re:Fsck x86

[PhrostyMcByte]

I'm hardly counting ARM out. I doubt Intel will ever try to apply themselves to all the areas ARM is in. For phones and tablets, though? There is no doubt that ARM will have some very serious competition in the near.

I realize we like to root for the underdog here, but realistically, Intel's got a leg up in the long run.

Re:Fsck x86

[sexconker]

This person is likely in their 20s, I am assuming early 20s. With that said, I am in my 30s, somewhat early. My first PC was an 8088 and I've deep dived into every modern processor since then. Even with the debacle that was Windows 7 and 8, I am still going to stand behind x86 as a great architecture that can stand the sands of time.

I doubt your age and I doubt your "deep diving" into "every modern processor". What does Windows 7 or 8 have to do with x86 as an architecture? In what way was Window 7 a debacle? How is Windows 8 a debacle? The overblown bullshit about MS locking it down? The raving lunacy about the new Start menu? Seems to me the media has the problem, not the OS.

Scalability: What other architecture has scaled so far that it was completely decimated two competing architectures from the past and the future at the same time. The original 8088/86 was 3mhz, the latest x86 offering is 4ghz.

Decimate means to reduce by a factor of one tenth. WTF does the clock speed increase over decades have to do with anything?

Popularity: Both Apple and Sun saw the writing on the wall, Sun saw it too late, Apple saw it early (or saw what happened to Sun). They both shifted from a proprietary processor and chipset to a more common and popular platform. Both platforms had specific benefits over x86 until x86 scaled far and beyond what they both offered.

x86 is hardly any less proprietary than PowerPC or SPARC. You've got Intel and AMD at the helm. VIA walked the plank ages ago.
Apple ditched PowerPC because Apple's market share was so fucking low that the only company compiling for PowerPC was Adobe. The decision to drop PowerPC had to do with market share and cost, not the architecture itself.

Backwards Compatibilty: I know my x86 processor is still going start in 8-bit mode and I know that I can put it in 16bit mode and run my 1992 applications. But to that extent, x86-64 just extends the instruction set. eg ARM32 does not play on ARM64.

x86 CPUs don't start in an 8-bit mode. They start in Real Mode. x86 CPUs are 16, 32, and 64 bits, not 8 bits. The 8088 simply has an 8-bit data bus. Registers are 16-bit.

Let's face it. I witnessed Y2K. I witnessed every weak architecture under the sun get wiped out because it had shortcomings. Intel designed the best architecture with x86 and naysayers generally harp because it's "too big". I, for one, plan to teach my children x86 ASM so they understand the basics.. then let them find MIPS or ARM or whatever-fad-arch-is-current so they too can appreciate the design of x86.

Let's face it, you're an AC posting malarkey.

Re:Fsck x86

[Anonymous Coward]

Backwards Compatibilty: I know my x86 processor is still going start in 8-bit mode

Maybe the 8008, but (IIRC) the 8086+ starts in 16-bit real mode.

Re:Fsck x86

[Cornelius the Great]

BTW x86 32-bit doesn't run on x86_64 either. The software and chips have emulation routines that allow it to happen. The same as happens with A64 that allows old A32 and T32 instructions to still run on the same chip.

Disregarding built-in microcode that converts CISC instructions into simpler RISC-like operations, this statement is not accurate. All x86-64 processors have the same native 32-bit registers and instructions that the original 386 had (some may be deprecated, but IIRC there is 100% compatibility). No hardware emulation is being done.

You may be confusing the virtual memory translation scheme (Wow64) that Windows uses to run 32-bit processes in Windows x64. Yes, there is some slight overhead, but it isn't considered to be emulation.

Re:Fsck x86

[JohnFen]

Since we're all playing the age card, I'm 50 and have been actively developing software since I was 12 (using punch cards and the ultra-fast and modern paper tape!)

The x86 is a fine architecture, despite its numerous warts. However, so is arm. Each has distinct advantages and disadvantages -- and being able to operate in power-starved situations (such as with smartphones) is one of the main strengths of arm and one of the main weaknesses of x86. If my experiences has taught me anything, it's that there's no such thing as a single approach that works well in every situation. If all you have is a hammer...

"Intel designed the best architecture"

What is "best" depends on what it's used for. There's no such thing as a single architecture that is the "best" in every situation. Arm is hardly the "current fad". It's been around and going strong for a long, long time -- and it's being used in smart phones because it happens to be the best solution for that application currently on the market.

Re:Fsck x86

[Type44Q]

BTW x86 32-bit doesn't run on x86_64 either. The software and chips have emulation routines that allow it to happen.

Unless I'm mistaken, that's completely incorrect.

Re: Fsck x86

[Anonymous Coward]

MIPS is taught in schools because the instruction set has one particularly useful feature: sanity. I've written in MIPS and TI C6X and when I look at x86 code, my head begins to turn inside out. It's a complete fucking mess.

Re:Fsck x86

[Anonymous Coward]

BTW x86 32-bit doesn't run on x86_64 either. The software and chips have emulation routines that allow it to happen.

I don't know if emulation is entirely the correct term in this case.

The x86-64 is designed as an extension to x86-32, and Compatibility Mode is a subset of Long Mode. As far as applications are concerned, Compatibility Mode is the equivalent of Protected Mode.

Re:Fsck x86

[cb88]

The "superiority" of X86 had nothing to do with the demise/back burnering of other architectures.

Just about every processor arch has been maimed by confrontation on a marketing front... Alpha, Sparc, Power, Arm.... the ones that have survived have regulated themselves to niche markets (in the case of ARM a really really big niche) so they don't have to do battle with Intel and AMDs marketing and established user base.

I don't know about the rest but Sparc has backward compatibility that rivals Intel's as well as good performance.

Re:Fsck x86

[Pepix]

Popularity: Both Apple and Sun saw the writing on the wall, Sun saw it too late, Apple saw it early (or saw what happened to Sun). They both shifted from a proprietary processor and chipset to a more common and popular platform. Both platforms had specific benefits over x86 until x86 scaled far and beyond what they both offered.

Did you mean: 'Apple suffered from a PowerPC processor shortage, while Sun added x86-64 to their lines of workstations and servers'?

Get you facts right: Sun didn't shift to being an x86 shop, and Oracle hasn't, too. In fact, the SPARC architecture is so alive, that is used in some of the Top 500 Supercomputers... as IBM's PowerPC.

Re:Fsck x86

[drinkypoo]

How is that relevant to the issue I was commenting on? That doesn't make ARM scale worse, that makes x86 scale better, doesn't it?

It means ARM isn't going to just magically scale well because it's RISC, and it won't scale any better than x86 because x86 is RISC, too — even if it doesn't look like it from the outside.

Re:Fsck x86

[K. S. Kyosuke]

I never claimed any such thing. Put those things into somebody else's mouth.

Re:Fsck x86

[drinkypoo]

First of all, at this point, it is misguided to talk about x86 as an architecture;

Thank you. I got a raft of shit when I argued that there was no such thing as an x86 instruction set architecture any more just recently, and hasn't been since the Am586 took x86 into RISC-land.

I'm still not seeing any x86 processor getting (unbiased) performance/W scores that are close to common ARM processors.

On the other hand, I'm seeing a pretty massive gap between the high-end in x86 (really, amd64) processors and in ARM processors. This doesn't mean ARM can't be scaled up, but I think it's worth remembering what x86 went through in being scaled up. It didn't happen overnight. It may well be that x86-compatible processors embrace low power consumption before the ARM-compatible processors scale up to the high end.

Re:Fsck x86

[Pepix]

Think that a motorola 68000, way back in the day was better than the old 286s it compared to.

Not quite right, IMHO: the memory protection, multitasking and 4 rings of execution levels in the 286 leave the 68000 in the dust. Xenix, TopView and some others in the era benefited from these enhancements.

OTOH, if your only experience with a 286 was using MS-DOS, you only saw it as a 'fast 8088', and I have to agree with you.

Re:Fsck x86

[drinkypoo]

BTW x86 32-bit doesn't run on x86_64 either. The software and chips have emulation routines that allow it to happen.

Unless I'm mistaken, that's completely incorrect.

The CPU's functional units don't execute x86 instructions or amd64 instructions. They execute micro-operations into which the x86(_64) decoder decomposes the instructions issued to the CPU.

Re:Fsck x86

[drinkypoo]

I never claimed any such thing. Put those things into somebody else's mouth.

Testes today, aren't we? Someone said ARM doesn't scale well, you said how did you figure that out, RISC designs have historically scaled well. I'm calling the relevance of RISCyness of ARM into question. You can either continue to be defensive, or you can respond to that.

Re: Fsck x86

[K. S. Kyosuke]

And? What I meant was that the general design school of RISC CPUs has never had any significant scaling obstacles, and that the ARM ISA to my knowledge isn't somehow magically worse. I most certainly didn't mean that merely by virtue of being a RISC design, it's going to be magically better, either. I also spelled out that having the instruction encoding simple actually allows simple cores to stay simple. And of course I'm defensive. If I didn't stand for my opinion, I'd be surrendive instead.

Re:Fsck x86

[rahvin112]

A typical processor design takes around 4-5 years from concept to production silicon. Intel did not even consider power as a constraint (other than a maximum) until 2008.Haswell was the first ground up design where power was a constraint, but still not a major constraint. With Haswell Intel was within shooting distance of ARM power levels without even compromising computing power.

In about 2010 power consumption became not just a feature, but a required feature in low watt to milliwatt ranges. Intel should have a processor to meet that requirement later this year or early/mid next year. Intel's already preliminarily released some (un-handicapped) atoms that have about 75% of the performance of Haswell and are power competitive with ARM.

Up until a year or two ago when the PC market began to crater Intel wasn't interested in playing in the low power market because margins were atrocious, but with the rise of high margin smartphones and the reality that they will likely replace a significant chunk of the personal PC market they've begun to take the market seriously. Writing them off as unable to play this game because they haven't bothered in the past would be incredibly stupid. They are the largest CPU designer in the world and they have some of the smartest CPU designers in the world working for them, it just takes a while to turn such a big boat. Give it a few more years then come back and talk about x86 being unable to compete.

  I don't know if Intel will succeed but if they put their resources into it they will easily outpace ARM because in the CPU design game it's about design resources and FAB's and Intel has both in spades (in FAB's Intel is one entire process step ahead of everyone else), more than the rest of the ARM market combined and they won't be designing the same thing 50 times. See that's the ARM markets biggest handicap, there are dozens of companies reinventing the wheel over and over again. Intel's biggest handicap is their desire to not eat existing markets and it might be their undoing (a processor with 75% of haswell's power with ARM's power use could likely cannibalize much of their Haswell sales and the tricks to prevent that, ie sales restrictions, will also handicap the processors chances in competing with ARM). IMO if Intel fails at competing with ARM it will only be because they didn't want to cannibalize sales with lower margin parts.

Re:Fsck x86

[maccodemonkey]

x86 is hardly any less proprietary than PowerPC or SPARC. You've got Intel and AMD at the helm. VIA walked the plank ages ago.
Apple ditched PowerPC because Apple's market share was so fucking low that the only company compiling for PowerPC was Adobe. The decision to drop PowerPC had to do with market share and cost, not the architecture itself.

Yes? No? I think this is a misunderstanding of the motivations behind Apple's PowerPC switch. (Source: I wrote PowerPC Mac apps at the time and was in the room at WWDC when Apple announced the switch.)

The PowerPC market was a bit wider than that. Microsoft had Office on PowerPC, Adobe had their suite, and there was a smattering of other apps.

At the time, the future of PowerPC had looked pretty bright. Microsoft's Xbox, Sony's PS3, and Nintendo's Wii were all switching to PowerPC. Within a span of several months, the community was looking at a majority of gaming hardware being PowerPC based. PowerPC was going to be in very high demand, which would mean great things for the Mac PowerPC platform. Far from "the only company compiling for PowerPC was Adobe", Microsoft was buying Power Mac G5 boxes for their dev kits and they were porting Windows to the PowerPC for the Xbox. And in the end, Microsoft, Sony, and Nintendo combined shipped several hundred million units based on the PowerPC (With Nintendo still shipping the Wii U with PowerPC today.)

So why did Apple leave the PowerPC?

At the time, laptop sales were on the rise, but Apple's laptop CPUs were not designed by IBM, they were designed by Motorola. IBM's PowerPC G5 was suitable for the Xbox 360 and desktop machines, but it ran far too hot to go into laptops. This left Motorola with their G4 CPU. And let me tell you, Motorola probably had very smart people working for them, but their execution was incompetent. The G4 had a 133 mhz system bus (which was slow even for the time), and ran very hot (but still cooler than the G5), and worst of all, was much slower than Intel's Pentium M.

Meanwhile the Pentium M was doing very well. It was faster than the G4, more power efficient than the G4, and it actually had a modern chipset and bus. Switching to the Pentium M was a no brainer.

There was speculation that Apple was trying to get IBM to make a mobile G5, but they were never able to get the power consumption down. When Microsoft and Sony entered onto the scene, IBM's interest shifted to getting the PowerPC into larger form factors, and Apple just didn't ship enough units in laptops to balance out the R&D demand that Microsoft and Sony created.

Motorola in the meantime with the G4 just kept sucking. There was a new architecture that was basically a modern architecture for the G4 that did eventually end up shipping, but by then Apple was just done with PowerPC.

Intel provided a stability the AIM (Apple, IBM, Motorola) alliance just didn't provide, with a quality chip. PowerPC did end up scaling, but there simply wasn't the same demand for PowerPC machines at the time to make it scale well enough.

So were people not actually writing code for PowerPC? No, lot's of people were. I'd actually guess that after Apple left PowerPC, the number of PowerPC developers continued to rise. And with the Xbox 360, Sony PS3, and the Nintendo Wii/Wii U continuing to get new games, there are still a lot of PowerPC developers out there.

Re:Fsck x86

[Anonymous Coward]

Re: "...ARM server gear is taking off"

States facts not in evidence. For all the hype and promotion, ARM servers aren't even a rounding error in the market. And the company all the fans had their hopes pinned (Calxeda) on went out of business. Oops.

I for one am getting deeply cynical about the concept of ARM servers. 'Oooo, but wait, 64-bit ARM will change everything!' Really? Why?

ARM knows and understands the mobile space. They deserve serious respect there. ARM doesn't know and doesn't understand the server space. The sales, support, capability and technology attributes are completely different in enterprise technology. I doubt that ARM brings enough to the table to break through except in very limited, niche roles.

Re:Fsck x86

[Anonymous Coward]

It's only a matter of time, x86 will trounce ARM, Core M is only the first step.

Re:Fsck x86

[Anonymous Coward]

This person is likely in their 20s, I am assuming early 20s. With that said, I am in my 30s, somewhat early.

Assume all you like, but don't be surprised when it turns out you're wrong. I'm past "early 30s" these days, so that lawn you're pontificating on, you'd best be getting off of. Moreso because you appear to be confusing "good" with "popular".

They're not the same and in fact bear little relation to each other, certainly in technology, perhaps paradoxically. Something you could've figured out watching Carly wipe out PA-RISC and Alpha both, all but betting the company on itanic, and losing.

"x86" is still a good moneyspinner for intel, but that doesn't make it good as an architecture, as OneAhead explained. It's good to remember what intel does well, and what it doesn't. Fab process and fabbing fabs is what they do best, ahead of everyone else. Instruction Set Architecture is not one of their strong points. It's not all that hard to see with a little ISA history homework. And that is but one reason why I'd prefer x86 finally wither and die.

Re:Fsck x86

[BasilBrush]

No-one who hasn't learned assembler for at least a couple of processor architectures would understand it.

I too have a deep dislike of X86 that dates back to approaching it as my third processor architecture after 6502 and 68000 and hating X86 for it's inelegance. I've learned a couple more since than and nothing has shifted that initial distaste for X86. Even though it doesn't matter anymore as few people, and certainly not me, programs CPUs in assembler any more.

Re:Fsck x86

[tippe]

I *do* have mod points, but can't mod him any higher, as he is already at 5. The most I could do is mod him down so that somebody else could come along and show how awesome his post is by modding him back up, but that doesn't seem like a very efficient use of mod points...

Re:Fsck x86

[BasilBrush]

The zealous ARMists are mostly those people who bought AMD during the speed-wars of the 90's. Intel won, and they can't stand that.

You're projecting, big time. These are completely different groups of people. They just happen to be 2 groups of people that you, as an Intel fan, dislike.

I like ARM, and as far as I'm concerned there's nothing to choose between Intel and AMD. It's the x86 instruction set that I dislike. And the power inefficiency.

Re:Fsck x86

[lagomorpha2]

I do (I am the person you are replying to), I have a 2 year old and another on the way. Yes I know my children may not find programming computers to be interesting.. but it is a geek father's hope isn't it?

I think deep down we all want our kids to end up being geeks.

Re: Fsck x86

[Anonymous Coward]

Intel are only competitive in power even with the new designs because their fabs are one step ahead of everyone else. To see the difference you should compare designs on the same production process.

Both chips have can be built with an out-of-order superscalar architecture, so the difference in instruction set only affects the instruction decoder right? Except the ALU and registers on an x86 are only 40% of the chip area. Instruction decode and control is over half the chip. The x86 being tied to a Byzantine instruction set cannot be changed and will result in higher power consumption on the same process technology.

Re:Fsck x86

[Anonymous Coward]

I hear this time to time.
It doesn't matter from a programming point of view if you can't write programs in those micro-operations.
A programmer may not be able to do better than the hardware micro-op scheduler but we wouldn't know unless access is allowed.
Then again, wasn't Itanium's VLIW more or less this?

Re:Fsck x86

[Blaskowicz]

Last time I read about these old stuff, it said the 486 DX/2 66 kicked the crap out of a 68040. From then on, a consumer CPU never has beaten x86 again. (Apple benchmarks in the late 90s were crooked, pure lies)

Re:Fsck x86

[spire3661]

Intel Bay Trail is laughing at your comment.

Re:Fsck x86

[Blaskowicz]

The complex, organically-grown instruction set also leads to some waste of silicon in having to support all those instructions, and waste of performance/energy efficiency in that the instruction set is not designed from the ground up towards efficiency. People on the x86 side make a compelling argument that this has become negligible, but the fact remains that I'm still not seeing any x86 processor getting (unbiased) performance/W scores that are close to common ARM processors.

This is not entirely exact, in fact Intel CPUs have a tremendous per watt, take a 80W or more Intel and compare it to a 2W ARM CPU, the Intel is so incredibly faster (and faster, bigger caches, lower latencies etc.) that it holds its own or even beat it handy if we were to consider total power consumption of the system (if you were to add up ARM systems till you get the same amount of gigaflops going on)

ARM server SoCs will change that a bit. Else, the power efficiency advantage of ARM is foremost there with low loads, e.g. want to run in 200mW, or 500mW (perhaps just throttling down from 2-5W) : here you go.

Re:Fsck x86

[Anonymous Coward]

Hell no. I want my kid to learn how to code, sure, because that's what logical men excell at. But it's FUN only as long as it stays a hobby and not a profession. I'd rather see him do something tangible with his two hands. Like be a machinist or carpenter or something. I f****n hate sitting at a s**t box all day long fiddling with trivialities. I should have followed my original career plan of being an international man of mystery, or a space cowboy.

Re:Fsck x86

[unixisc]

Had Intel's Itanium plan worked, Intel would have been happy to let x86 die. Problem was that AMD would have none of it, and extended x86 CISC to 64-bit. So if you are pissed @ x86 not being dead already, look @ AMD, who'd have had the option of Alpha CPUs had they been open to RISC. Had AMD gone w/ Alphas & Intel w/ Itanium, AMD would likely have won that one

Re:Fsck x86

[marcomarrero]

x86 survived because of price/performance caused by fierce competition (Intel, AMD, Cyrix, Rise, Centaur, etc.), and popularity of Windows/DOS. It was fun experiencing how x86 beat faster RISC CPUs (Alpha, PowerPC, Itanium) when there were builds of Windows NT.

Now, people are downgrading to ARM to use their low-power, low-performance portable toys (tablets, smartphones) running inferior operating systems. Sadly, Intel did an horrendous job with the Atom until 2-3 years ago, and Microsoft did even worse releasing the bloated Vista, which was awful for the now-dead netbook market.

Atoms are finally good enough, but still, the absurd 2GB RAM limit, and high power consumption (most Windows tablets can't charge from USB hub or PC) is still not good enough for Windows 8 (the real one, not RT).

And, please don't teach your kids x86 ASM. Modern C++ compilers generate good optimized code, runtime libraries are optimized. Besides, x86 code looks backwards, instruction set origins are from a 1970 terminal! (datapoint 2200), has endianness from hell, few registers, etc.

Re:Fsck x86

[uncqual]

Being over two decades older than you, I recall some of the microprocessor battles :)

The x86 instruction set is really quite a mess -- for some of the same reasons it's been a success. The company made what was largely a marketing decision (correctly) to maintain high levels of compatibility between generations - but that resulted in the mess we have now. Once Intel had volume (mostly thanks to the IBM PC adopting the 8088), they then had the money to fund massive efforts to crank out ever faster designs even with the cruft tacked on. Intel has been able to fund such development not because the architecture was particularly better, but because they built enormous volume on the shoulders of the PC. Interestingly, as a result, Intel was able to withstand such colossal disasters as the Itanium (as well as other smaller disasters). The story is a bit more similar to the Betamax vs. VHS story than one of pure technical excellence.

It's really (I think) impossible to love the x86 instruction set -- one tolerates it and accepts it understanding how it got that way. Fortunately, not many developers (except for those building compilers) have to deal with it anymore except when debugging.

For the youngsters out there, Wikipedia has an interesting article that includes some history of the Intel microprocessor we know today. Bob Noyce apparently initially wasn't interested in the building a microprocessor for the Datapoint machine (I programmed on one of those - a later one than the 2200 whose model number I forget and can't find quickly online) but changed his mind - if he hadn't, you might be saying the same thing about a TI microprocessor family that you are saying about the x86 family.

BTW, I don't see that x86 microprocessor architecture had a meaningful relationship to Y2K. Y2K may have spurred replacement of some old systems that didn't use x86 processors with those that did. But they were not replaced because they used another processor -- mostly they would have been replaced even if they had been running an 8088. Also, they were replaced with the common machine of the time - which often happened to be a x86 based machine. SPARC, PowerPC, and all the other architectures were perfectly capable of handing Y2K and all that were still being sold, did (and had for many years) support Y2K (of course, absolutely no changes were required in the hardware to do so).

Re:Fsck x86

[uncqual]

Because we think that it means they won't get dates until they are mature enough to not do something stupid that results in a baby geek being born to a 16 year old who then never gets around to going to college?

(Although, I hear that in some schools geeks are "in" now -- maybe it's safer to aspire to have your kid be a dolt in those schools!)

Re: Fsck x86

[Orion Blastar]

Take an ARM chip and then make a consumer PC out of it. See how well it sells. Can cheaper ARM based PCs outsell Intel based ones?

Re:Fsck x86

[ArmoredDragon]

Same here, and I ran into the same dilemma. I solved this problem by down moderating his post in the traditional method (when you simply disagree with a post, the well established thing to do on slashdot is to pick completely at random either troll or flamebait, and then mark it as such.) I then posted this reply to your post, thereby up modding his post, as is also tradition on slashdot.

So you see, even though he was already 5 before I started, I got to up mod him.

Re: Fsck x86

[OneAhead]

Instruction decode and control is over half the chip.

+1 Interesting! If true, this would actually explain the discrepancy between what the x86 fanbois say and the results "on the field".

Re:Fsck x86

[Anonymous Coward]

It's because x86 is aesthetically unpleasing. Not only that, it's associated with Microsoft. Eew.

Re: Fsck x86

[Anonymous Coward]

Take an ARM chip and then make a consumer PC out of it. See how well it sells. Can cheaper ARM based PCs outsell Intel based ones?

What, like these? http://en.wikipedia.org/wiki/R... http://en.wikipedia.org/wiki/R...

Re:Fsck x86

[uncqual]

First of all, at this point, it is misguided to talk about x86 as an architecture; there is generally little or no architectural overlap between two x86 processors that are a few generation apart. x86 is an instruction set, or even more correct, a family of instruction sets.

I don't disagree with this technically, but in common usage the term "architecture" has become to, depending on context, mean just the externally visible characteristics of a processor family independent of internal implementations. Mostly this is the instruction set (including memory model, side effects, undefined ops/fields -- all the behavior that is externally visible to software and, to some extent, interfacing hardware at an architectural level). It bugs me too, but I've come to accept it - terms morph sometimes becoming ambiguous w/o context.

For example, if one looks at the document titled The SPARC Architecture Manual Version 9 (© 1994), one finds a description of the instruction set and a little about hardware issues like MMU:Processor interactions. About the only hint of "architecture" as you (and I used to before I gave up worrying about it) consider it appears in notes like "IMPL. DEP. #: xxx" and these only implicitly acknowledge that underlying implementations may not all be the same.

Re:Fsck x86

[UnknowingFool]

They both shifted from a proprietary processor and chipset to a more common and popular platform. Both platforms had specific benefits over x86 until x86 scaled far and beyond what they both offered.

In my opinion, Apple shifted to x86 mainly for logistical reasons not architectural reasons. The problem with staying with PPC was two fold: 1) Intel offered better laptop chips and 2) Apple was going to have problems with PPC supplies.

The first one is fairly self-evident. Intel laptop chips were being updated all the time and they were better at power efficiency than the PPC4 based chips Apple was getting from Motorola. IBM never manufactured a mobile PPC5 chip probably because of the heat dissipation problems. If Apple stuck with IBM and PPC then they would have to be further behind Intel based mobile chips.

The second one is more complicated. Motorola then IBM supplied Apple with chips but even with millions of chips a year, Apple would be a small customer to either company. Compounding this is that Apple's chip was heavily customized so that it was costly to maintain and develop for any chip maker. Apple needed those customizations as other PPC chips by Motorola and IBM were not designed to be used for consumers in computers. For example IBM's chips for servers do not need any multimedia processing capabilities as they were designed for servers not desktops.

As such it was burden for Motorola and IBM to make changes to any supply schedules. If Apple got a sudden upswing in orders, IBM wouldn't be able to keep up. Also IBM would have to dedicate more and more resources to develop newer generations with Apple's changes and IBM was reluctant to spend possibly billions in research for one small customer.

Intel on the other hand was better logistically. Any development Intel did for Apple could be used for other customers. In fact, the ultrabook specifications came out of Intel's work with Apple on the MacBook Air.

Re:Fsck x86

[InvalidError]

x86 really started kicking the pants off just about everything else when it went superscalar out-of-order with the Pentium Pro.

As far as cost, speed and efficiency goes, I think modern-day x86 CPUs have proven that x86 can scale surprisingly well across all three parameters.

BTW, x86-64 does not use an "emulator" to run 32bits code. 32bits application code runs natively but the application itself is wrapped inside a 32bits "Windows-on-Windows" layer to map 32bits APIs to the OS' native 64bits APIs. Even in a "native 64bits" Windows application, the use and generation of 64bits code is actually optional; the only immediate difference is the ability to do direct calls to native APIs.

Re:Fsck x86

[Anonymous Coward]

Nope. x86's greatest weakness is Intel. With the breakneck speed that Intel went from 80386 to Pentium 4, they were only competing clock-for-clock against their previous model and AMD/Cyrix. Then everyone hit the thermal limit and was like "oh crap, how do we keep up with Moore's law now?" So we went BACKWARDS to the Pentium 3 and decided to multiply the cores, so that's what we've done since. However PROGRAMMERS have not. Go look at any application, or game made before the core duo and you will find that not a single one of them are multithreaded beyond the conventional MVC programming model. Everything from Video codecs to DirectX, assumed single-threadedness. Including all games programmed for DirectX9x (Xbox 360) level. This is why 300$ game consoles (who were using PPC last generation) tended to be better than 4000$ PC's for games. Because the PC was hobbled by software needing to still work on single-core processors.

We also see this lack of threading problem with lack of 64-bit software on the PC. Hello Google Chrome, Mozilla Firefox.

The only software out there that is really 64-bit and multithreaded are video codecs, because we've largely moved past h263/mjpeg codecs to h264/h265 which can be multithreaded on both the encoder and decoder end.
libpng/zlib is hobbled by single-threadedness, and damn near everything uses it. We don't need a "replacement" for png, but we do need a way of reading a lossless image accross multiple cores, which is impossible since -ALL- lossless compression algorithms are drawn from LZ.

Meanwhile ARM, has only recently jumped on the muilti-core and 64bit bandwagons, but none of the software currently out there is going to be programmed to use either because the devices they are targeted for, do not have 4GB of RAM, and often don't have multiple cores. That Dalvik thing? Entirely single threaded until Honeycomb. iOS has always had multi-core support because iOS is derivative of OS X, not a crappy JIT layer on top of linux.

Apple did not switch from PPC to x86 because it felt x86 was better, it switched because IBM was not interested in producing low-power chips. IBM was producing PPC chips for game consoles. Game consoles sell in much higher quantities than computers. The PPC technology was likely superior if Apple was still building servers, but Apple wasn't ever building "big iron" servers, it was building stylish boxes that people buy because they're easy to use.

This is why every time some investor think-tank floats the idea of Apple switching to ARM for everything, they completely miss the reason for the x86 switch in the first place. It was because Apple had no source for CPU's, It's hand was forced. That is not the story today. Intel ONLY produces CPU's for servers/workstations, desktops, and laptops, and Apple primarily uses the laptop parts, even in their desktops. Let me highlight that again
"APPLE USES LAPTOP PARTS IN THEIR DESKTOPS", now go look back at why IBM was not producing the parts Apple wanted. Apple would never switch to ARM for their laptops/desktops because Intel already sets the bar for for performance/watt. If Apple started putting ARM parts in the desktop/laptop, not only would they have to compete against themselves (which they would fail at) but everyone else selling ultrabooks. Apple could claim "48 hour battery life" but that is a meaningless metric when the ARM parts are 1/10th the power and PROGRAMMERS STILL DON'T KNOW HOW TO MULTITHREAD. A report the other day said Apple has a ARM laptop prototype that has many cores. Yes... but nobody programs that way, Intel knows this. The winning CPU will always be the one with the highest single-threaded performance, and that is NOT ARM.

The switch to ARM might come at some point, but not until several arms are twisted on the multithreading front.

Re: Fsck x86

[rahvin112]

Your numbers are wrong. Very very wrong.

The last time I looked the x86 decoder area is less than 200k transistors which is typically less than 2% of the processor die. x86 has been nothing but an abstraction layer for more than a decade. It allows Intel to make the internal risc CPU at the heart use whatever instructions or architecture works best while maintaining compatibility with existing.

Re:Fsck x86

[InvalidError]

With Intel bringing the fight to ARM with their 2-3W Atom-based SoCs that give most ARM-based chips a run for their money at least on the CPU front, I would not say x86 is failing to scale to low power anymore.

If Intel continues pushing mobile performance as hard as they have been for the past year, next year should be really interesting.

Re:Fsck x86

[Anonymous Coward]

No kidding. I'm willing to bet half of these "x86 arch is shit" dickheads have never programmed in anything lower level than java.

x86 assembly isn't that bad. Most of the main difficulties were ironically in the beginning, when you had to deal with the segmented memory model. The other issue that dragged on for longer was the lack of general purpose registers (as compared to other architectures), which x86-64 addresses to a degree.

Re:Fsck x86

[Darinbob]

I'm 50 (ish). The 8086 was a sort of mashup, like most Intel microchips, an incremental improvement over 8 bit 8080/8085 series which mainly allowed addressing more memory by the use of segments. Non-micro CPUs who had used segmented approaches were leaving this scheme in their newer designs, since it was a pain in the ass for programmers. Maybe you could excuse Intel since they were aiming for the microchip market rather than competing with real computers (ie, intended for calculators or I/O processors). This was a 1976 design I think, several years before the PC.

When the PC was designed there were already competing chips to choose, and those chips had been designed later and had more luxury of design (more transistors in the same space). 68000 was a much better architecture in almost every way, except for not having backwards compatibility with Intel family of processors. IBM wanted an 8 bit bus, so thus the 8088 was chosen intead of 8086, but there was also a 68008 as an alternative. The real deciding factor for the PC however was not the quality of the architure but the availability of the supporting chips necessary to build an inexpensive computer board, and Intel had them. So it won for pragmatics rather than being a good architecture.

Companies die not because they are "weak" with their designs. They die because the market is fickle and customer buy based upon impressions and biases rather than actual research. The same with market analysts where someone can kill a company overnight with a new stock advisory. But the PC and the x86 family are chock full of major shortcomings and they keep trudging through and the better designs get ignored.

PC: ridiculous styles of buses for ages. ISA and flipping jumper switches when the real computers at the same time had auto configuring devices; then later the VLB which was just a hack that caught on; and MCA bus on PS/2 was a superior solution but rejects by PC market because it wasn't compatible with the clones; overly complicated BIOS still locked into a 16-bit boot up sequence and code sequences stored in add-on card's ROMs; etc. It won only because it was the cheapest solution and compatible with what everyone else had.

8086-80286: extremely limited register selection, every register having some specific purpose in some instructions, segmented architecture, heaps of special purpose instructions. Later designs improved on this, but were saddled with the backwards compatibility which were not necessary if an emulator can do the same things. The only reason this architecture scaled was because it brought in so much money to Intel that they could afford massive amounts of man hours to beef it up; essentially it's on steroids. It's real advantage is that it uses a relatively small amount of code space compared to most RISC systems, however that advantage has become somewhat moot as memory is cheap and PCs are full of giant caches.

Even Intel tried to create newer and better designs but were unable to make headway against their x86 line, so they were a victim of their own success. Even when they had their 64-bit Itanium it failed compared to the competition's 64-bit chip that retained x86 compatibility.

Anyone who studies ARM or MIPS will realize how badly designed the 32-bit x86 line was.

Re:Fsck x86

[JohnFen]

Intel has to do more than provide parity with Arm, though. They have to provide a compelling reason to use their chips. "As good as arm" doesn't cut it at all, since arm is the defacto standard and developers will just continue to target that. What benefits do Atom chips bring that offsets the cost of supporting them?

Re:Fsck x86

[Darinbob]

If I had a child, I'd want him or her to be able to do what they think is fun and interesting, rather than just get a job for a job's sake. Believe me, a lot of programming and engineering is a really awful job, more fun as a hobby or when studying it than in dealing with it in real life. And good and fulfilling programming jobs are RARE, most of the people doing it are code monkeys creating social media apps or business applications, whereas those creating a new life saving medical devices, scientific instruments, or sending people to mars are rare.

Re:Fsck x86

[Darinbob]

True, but the 68000 was a competitor to the 8086, not the 80286. That comparison is better with 80286 versus 68020. Though it's hard to make direct comparisons as competing chip families didn't release new versions at the same time.

As for 4 rings of execution, I think that's overkill. Very few people use more than two (user versus kernel), some use three (adding a middle supervisor), but I can't think of an example where four rings of protection were used.

Re:Fsck x86

[Darinbob]

ARM also has a mash up of instruction sets, and it can look very byzantine as well to someone new to it. It's not just that later versions added new instructions, but that it's a branching tree so different branches have different add-ons, plus the 4 different fundamental instruction sets.

As for winning, ARM has already won essentially on the smart phones, and has a significant presence on low power 32-bit embedded CPU market where Intel has nothing significant. ARM shows up in many ASIC designs as well so it's hidden around in many places you might not expect.

Re:Fsck x86

[gtall]

Can I license Intel's designs, modify them, and get my own chips made? No. Game over.

Re: Fsck x86

[Darinbob]

And it's a project in some schools to design a scaled down MIPS-like CPU on an FPGA.

Re:Fsck x86

[alexo]

My opinion is that Intel (and AMD) achieved those things not because of the x86 architecture but in spite of it.

Re:Fsck x86

[Darinbob]

Intel x86-64 and ARM are in completely different market segments. Intel is making high performance CPUs for the desktop/laptop market, ARM is licensing a range of designs for low to medium power/performance chips. Most of the ARM cores in the world run on systems with less memory than an x86-64 has on-chip in the caches.

It's like saying that Ferrari would beat the pants off of a Tesla model S. Ferrari wins on speed of course, but the goal of Tesla is not to be the fastest impractical car in the world. With x86-64 versus ARM, this is more like comparing Ferrari to a Prius.

Re:Fsck x86

[Darinbob]

Competition will be difficult, because ARM on phones now has the advantage that Intel has had on the desktops, it is what you need to be compatible with. No one wants a phone where you can't run the iOS or Android apps, in the same way they don't want a PC where you can't run PC apps.

Although saying "ARM" is sort of wrong. These chips are all being made by other people, using ARM's designs. Even Intel makes ARM chips.

Re:Fsck x86

[Anonymous Coward]

ME, Vista, and 8/8.1

Re:Fsck x86

[Anonymous Coward]

Perhaps we will see the reemergence of the workstation PC. When I need some intense number smashing, I wouldn't give that task to an ARM. A 72 hour genome assembly on a Core i7 would take weeks on the best ARM has to offer. Intel is going to keep pace and I can't see ARM ever outclassing Intel released the same year. Maybe we will see ARM take over the consumer space where web browsing is key while Intel finds itself in serious scientific/engineering work.

Re: Fsck x86

[Anonymous Coward]

"surrendive" isn't a fucking word MORAN.

Re:Fsck x86

[Anonymous Coward]

I asked my kids if they wanted ice cream or to reverse engineer assembly code and port it to arm today.

Re:Fsck x86

[Zynder]

That method was entirely dizzying and mindboggling yet technically got the job done. Do you work for Intel?

Re:Fsck x86

[Your Average Joe]

Your full of SH!T, must be a paid troll from Intel.

I recall seeing the DEC Alpha in person running CADRA-III CAD software and it ran circles around Intel and it was 64 bit pure. 64 bit PowerPC is way better than Intel x86 as well.

Now if you were a real techie you would know the current CPU was derived from AMD with the AMDx64 architecture. AMD's early chipsets could access the RAM at 40 bits wide so you could use up to 1TB of RAM while Intel was crippled at 36 bits and 64gig of RAM(http://www.nordichardware.com/CPU-Chipset/amd-athlon-64-3200/Benefits-of-a-64bit-architecture.html). AMD also had the hyper transport bus where Intel was still pushing the clock race war and Front Side Bus with a 40 bit RAM limitation on the first version.

Sun and Apple use what they want and are niche players, you do know that HP is still trying to push the itanium. You do remember that failure... The monopoly power is the thing that allow those nut jobs to send a totally different architecture on the world of desktop PC's and servers tied to the Windows monopoly.

Now go eat a SH!T sandwich!

Re:Fsck x86

[Anonymous Coward]

You are, of course, theoretically correct that there's no architectural advantage to x86. As a practical matter, however, x86 will live forever because Intel and Microsoft support it. Intel is so far ahead of the curve on lithography that it's not even funny anymore. I mean, Intel is shipping 22 nm silicon with 14 nm due by the end of the year with Broadwell. They're pushing 10 nm by the end of next year. Most of its fabs are on 300 mm wafers. Intel can push these 22 nm chips in bulk, with high yields. Even when Intel makes a strategic mistake such as Itanium, the high-heat high-frequency P4 architectures, missing the x64 boat, missing mobile, the lithographic advantage is way too big for its competitors to seize advantage of. Even if TSMC or Samsung catches up to 14 nm, it's far from certain that they can deliver the quantity and achieve the high yields necessary to recoup the investment to get there; Intel can.

Intel missed the boat on mobile/portable processing because these are relatively low profit chips; Intel was focusing on desktop/laptop users for business and gamers. People have been foretelling the death of desktops for a while now but the fact is that desktops will always offer higher performance than laptops at a lower price. Business users and gamers tend to use larger screens, precluding their use of laptops, so that's a bread and butter crowd for Intel. The big selling point of ARM--power efficiency--isn't that great when Intel's processors are just much more powerful than the competitors.

Add to that the fact that Microsoft is pretty much set on x86 (aside from Win RT, which has gone over like a lead balloon) and Intel can prop up x86 for a much longer time.

Re:Fsck x86

[Anonymous Coward]

I got a raft of shit when I argued that there was no such thing as an x86 instruction set architecture any more just recently

And well you should. There is such thing as an x86 instruction set architecture (or family of related instruction set architectures). It's true that the ISA now has significantly less influence on the processor architecture than in the past, but that doesn't make the ISA disappear. Try reading Wikipedia to learn what an instruction set architecture is.

Re:Fsck x86

[Dahamma]

In mobile maybe. It's doing well but not "massively" dominant in the TV market, though. In that area it's gaining ground but still in heavy competition with MIPS.

ARM is SO not going to be competing in servers any time soon. Our "cheap" x86-64 servers are already at 24 cores and 64-96GB RAM. Once ARM gets anywhere near that those server specs will be 4x that, or more...

Re:Fsck x86

[Lennie]

There are 2 problems, that both companies are putting a lot of effort in:
Intel trying to scale down
ARM trying to scale up

Re:Fsck x86

[drinkypoo]

It doesn't matter from a programming point of view if you can't write programs in those micro-operations.

That's okay, we're talking about hardware, not software. That is actually a supporting point to my argument.

Re:Fsck x86

[evilviper]

the instruction set is now so byzantine that x86 is a very difficult market to break into

The patents, which you can't get a license for, are the show-stopping problem. The complexity is not.

I have particularly fond memories of the later Alphas, which wiped the floor with everything up until and including the Pentium 4, and were very competitive even against Athlon 64 and Core2 performance-wise

Bull. Alphas wiped the floor with the original Pentiums they were up against, but with each successive generation, their lead was *dramatically* reduced. In the P4/Athlon days, there was no performance advantage left, and the only sales were from those with Alpha legacy software they wanted to keep running for another generation. Much like HP-UX and Solaris systems, today.

Repeat after me: x86 has zero inherent architectural advantage!!!

x86's complex instruction set does have some performance advantages. The smaller size of common opcodes reduces the memory and bus bandwidth needed, for a nice little gain. It also made it easy to keep tacking extensions on, since they weren't limited to a specific number of fixed-width instructions. It similarly lent itself to OoO and pipelined execution better than many other simpler architectures.

The big advantages it has is (1) economies of scale and (2) the higher profits of a mass market that generate more revenue to be pumped into R&D.

Completely wrong. Many proprietary architectures got MORE R&D money than x86, at least for a time.

x86 being open meant the sale price of the CPU was the only cash Intel/AMD/etc. would get out of it... With proprietary architectures, a fast processor helped not just sell more processors, but the entire PLATFORM. Selling the rest of the single-source proprietary hardware, software, support services, etc., etc. was quite profitable, and some of that money went back into CPU development, to keep the entire market alive. This is the same reason IBM's POWER architectures is alive and well, and (occasionally) performance-competitive with x86. Other companies just couldn't keep the model going.

While Intel is sitting on an impressive pile of cash and R&D potential, their attempts to match ARM in performance/W are so far unsuccessful when looking at non-biased benchmark results

Intel is at a decade's disadvantage, over ARM in R&D on low-power chips, and ARM's success has kept Intel out, and prevented Intel getting market effects and profits to further development. Just having a pile of cash doesn't make it happen, and doesn't prove whether something is technically possible or not. Boeing has a pile of cash, yet they aren't making all the drone aircraft, either... Microsoft has a pile of cash and can't break-in to mobile... Apple has a pile of cash and can't keep-up with Android. etc., etc.

Also, framing this as an Intel versus ARM fight is dishonest. MIPS was huge, long before ARM, and is still found in many embedded devices, like your WiFi AP/router, the architecture is getting lots of R&D by the Chinese government who wants a domestic designed/produced chip, and was one of the players in the PDA days, yet also got steamrolled by ARM when smart phones debuted. Never mind SPARC, SH-3, Power, etc.

Re: Fsck x86

[NotRightAway]

First you need to define "PC." You can carry out pretty much any task you want on a smartphone platform, provided it's connected to a display, keyboard, and mouse, on a desk. What does that have to do with x86?

Re:Fsck x86

[bitSmiter]

The competitors to x86 (esp. PPC) could have scaled just as well, if not better. But they didn't have large enough markets to justify the expense of development. Whereas x86 did.

It really comes down to market share.

Re:Fsck x86

[InvalidError]

Baytrail had a fairly big performance lead on most ARM-based chips in CPU-centric benchmarks at launch and scored a fair number of design wins early this year so Intel appears to be making a fair amount of progress there.

Since the "defacto standard" for Android is also for developers to use the ADK which is Java-based (the Android developers' guide recommends against using the NDK unless absolutely necessary), a fair chunk of applications out there do run on Atom-based Android devices as-is; albeit possibly not a chunk of the top-2000 most popular ones that do depend on the NDK for purposes beyond optional optimizations.

If there is a company with years of experience optimizing (re-)compilers, Intel is probably it. I would not be too surprised if Intel optimized the pants off their x86 native recompiler to convince Android developers to quit messing with the ARM NDK.

Re:Fsck x86

[Agripa]

Think that a motorola 68000, way back in the day was better than the old 286s it compared to. Imagine that the 68000 took off instead of the 286 - if MS and IBM had built DOS for 68000 instead of x86... today we'd be in pretty much the same position but with a different chipset. But it would be faster and cheaper and more efficient.

While 68000 had a more orthogonal instruction set, starting with the 68020 it also included double indirect addressing which is difficult to implement in a super-scalar out-of-order design.

Re:Fsck x86

[dkf]

ARM is SO not going to be competing in servers any time soon. Our "cheap" x86-64 servers are already at 24 cores and 64-96GB RAM. Once ARM gets anywhere near that those server specs will be 4x that, or more...

With large server deployments, performance per watt is a very relevant metric. This is because the limiting factor is actually keeping the server cluster from cooking itself, even with very good cooling in place. PPW is an area where ARM is generally quite a lot better than the x86 variants. After all, who cares if a system is slower when you can compensate by just cramming more cores in? (I don't know if ARM's floating point handling is good enough yet to compete in this area though; the big server guys really care about their number crunching.)

That said, ARM's really large advantage over at least x86 is that they're a design that they license out to others to manufacture. This does mean that they can't typically use all the very latest fabrication technologies, but it also means that for a third party manufacturer who has some of their own secret sauce for a specific market, they can get an ARM core for a reasonable amount and integrate it (rather than having to send it elsewhere for fab where they won't know who is watching). This is an advantage that it is hard to overstate; there will be lots of ARMs about for a long time to come.

The other thing to consider in mobile applications is what the noise ceiling of the CPU is; lower noise means less shielding and so less weight and cost. You've got to think in terms of optimising the whole system, not just the CPU core.

Re:Fsck x86

[ras]

your claim that x86 has 8-bit mode is false; the lowest common denominator for x86 is the 16-bit 8086, which you're probably confusing with the 8-bit 8080 which is not x86 compatible

He was probably thinking of he 8088, which was an 8086 with an external 8 bit bus. Internally it was identical to an 8086, and so by any reasonable definition it was a 16 bit chip. It was probably the commonest version of 8086 released because it was used by the original IBM PC.

their attempts to match ARM in performance/W are so far unsuccessful when looking at non-biased benchmark results

True, but to have hope of winning the power/watt race currently, they would have to produce a chip that runs as slow an ARM. If things were static they might have be tempted to do that, but they aren't. Instead Moore's law means a OOO superscalar chip will practical on a phone in a few generations. And with it, the power advantage ARM gains form less complex, slower chips will disappear. Once that happens, the overhead imposed by the amd64 instruction will be so small it becomes irrelevant. Intel seems to be content to just wait for that to happen. Or maybe it's more a consequence of not having a choice, because the complexity of x86 did appear to impact the underpowered Atom badly.

Whatever the reason, Microsoft's abandonment of Windows RT hints that simply waiting will work. Microsoft abandoned RT because ARM simply doesn't have the horsepower, and while an i5 does get over a day worth of battery time. So they have already hit the power budget of a tablet. A phone can't be too many generations off.

But with the Mill architecture claiming a 10 to 1 MIPS/Watt advantage, while having the same raw horsepower as an OOO superscalar core, I can't help but wonder if both ARM and amd64 will loose this race in the end.

Re:Fsck x86

[Daniel Hoffmann]

Well thank you for the only sensible technical explanation on the subject so far. Just want to leave this link here:

http://en.wikipedia.org/wiki/M...

Who knows, maybe Intel will license some of the ARM instruction sets and have processors that can run both x86 and ARM code (and its extensions/variations.) I don't think that ARM wants that, but to prevent a monopoly they may be forced to license their instruction sets to their rivals.

Re:Fsck x86

[TemporalBeing]

The complex, organically-grown instruction set also leads to some waste of silicon in having to support all those instructions, and waste of performance/energy efficiency in that the instruction set is not designed from the ground up towards efficiency. People on the x86 side make a compelling argument that this has become negligible, but the fact remains that I'm still not seeing any x86 processor getting (unbiased) performance/W scores that are close to common ARM processors.

This is not entirely exact, in fact Intel CPUs have a tremendous per watt, take a 80W or more Intel and compare it to a 2W ARM CPU, the Intel is so incredibly faster (and faster, bigger caches, lower latencies etc.) that it holds its own or even beat it handy if we were to consider total power consumption of the system (if you were to add up ARM systems till you get the same amount of gigaflops going on)

ARM server SoCs will change that a bit. Else, the power efficiency advantage of ARM is foremost there with low loads, e.g. want to run in 200mW, or 500mW (perhaps just throttling down from 2-5W) : here you go.

So I'm looking at designing a server set whose total power envelope (hard drives included) is 50W; yet still does everything necessary and then some. Yeah, x86 isn't even a thought - I'm only looking at ARM boards where the entire board utilizes around 5W.

Re:Fsck x86

[marxmarv]

"they won't be designing the same thing 50 times. See that's the ARM markets biggest handicap, there are dozens of companies reinventing the wheel over and over again."

They aren't inventing squat. They're taking a soft IP core processor provided by ARM and connecting their own pieces up to it, same as any other SoC or S-100 computer. No testosterone-drunk manly geek auteur nonsense, just instantiating, wiring, simulating, taping out and profit. Buying that three-year head start from ARM was a good idea for them.

Get yourself a book on Verilog or VHDL and build yourself a couple of toy SoCs using IP from OpenCores. If you're feeling really adventurous, borrow the Hennessey book from someone at work and design your own processor. Really, if you're gonna fanboi, at least know what you're fanboi-ing about.

Re:Fsck x86

[sjames]

Actually, x96_64 does natively run 32 bit code, no emulator involved. You may be thinking of Itanium.

In fact, x86_64 still starts up in real mode.

Re:Fsck x86

[sjames]

There are a number of DOS based industrial apps and the people using them care very much about 16 bit support.

Re:Fsck x86

[JohnFen]

I would not be too surprised if Intel optimized the pants off their x86 native recompiler to convince Android developers to quit messing with the ARM NDK.

I'm sure that you're right. All I'm saying is that it's going to take more than that to get everyone to shift. There's no reason to for developers to change their workflow to accommodate anything special for x86 right now, because there's no compelling design or business reason to do so.

Intel needs to provide that reason.

Re:Fsck x86

[InvalidError]

Intel needs to provide that reason.

Google already provides that reason by strongly encouraging developers to use the ADK (Java) instead of NDK (platform-specific) for Android app/game development exactly to avoid locking themselves down to a specific ISA. Google is probably not too pleased with prevalent use of NDK in Android's top-2000 apps.

If Intel manages to produce an ART or DALVIK JRE for x86 that performs closer to native performance in more circumstances, it would make x86-based SoCs stronger options for portable apps and weaken the case for developers choosing to use ARM-NDK. I imagine Google would be quite happy with that.

Re: Fsck x86

[Orion Blastar]

See if ARM based PCs sell and scale better than x86 based PCs.

Can't run Windows on an ARM PC but maybe Linux or Haiku or AROS or something. Raspberry PI isn't a PC because it is in kit form. Make it a $100 or $200 brick PC and then see how well it sells. Make it on an ATX motherboard and then sell ARM based ATX PCs.

Re:Fsck x86

[lsatenstein]

I like compatability, but I've had it with x86. Let ARM hog the limelight for a while, no reason it shouldn't have its fifteen minutes. And let x86 die, it's way past its BBE date and has outstayed its welcome by several generations.

And what architecture would you put into place? RISC? A competitor's chipset? This is not a challenge to you, but an RFI?

I used to program ibm360. There was no little endien arrangment for integers as is the norm in x86. Changing to big endien architecture will make for an interesting change, if it comes about, and with potential performance gains.

Intel has no Android phone market share

[Anonymous Coward]

Even according to their own developer website, only three phones on the entire market use x86.

This is a problem for tablets, then. But wait! This could all be solved by Google simply filtering their store offerings by what's available to x86 tablets vs ARM phones, which would be a real kick in the nuts for Intel.

Re:Intel has no Android phone market share

[EasyTarget]

I think they do that already; filter apps you see via a device compatibility matrix. Or is this only at a crude level to distinguish (say) Tablets from Phones, etc.

Re:Intel has no Android phone market share

[drinkypoo]

I don't know how it works precisely but I do know from experience that selecting a different model can permit you to install an app when you were disqualified for all manner of reasons, including such details as display resolution. Finless roms for MK908 show up as a Samsung device or something because otherwise lots of apps which work fine don't install

"newsy" bits

[bill_mcgonigle]

Somehow missing from TFS...

Intel has released a beta of its native development environment called Intel Integrated Native Developer Experience, (INDE) and written plugins for Eclipse the most Android developers use to build for Android so the apps can be X86 compatible and execute efficiently on Atom processor-based hardware.

Not very well written then

[guruevi]

Well-written C can be cross-platform compatible. It's all in how you write things (or the libraries you use).

Re:Not very well written then

[Atzanteol]

A compiled binary doesn't care how well-written your C is if you are running it on the wrong platform.

Re:Not very well written then

[Anonymous Coward]

No but a system for recompiling ARM code to x86 does. RTFA.

Re:Not very well written then

[TheRaven64]

Most people get Android apps from an App Store though, and it can easily select the correct version. This happens already for MIPS-based devices, so there's no reason why it wouldn't work for x86, if it were worth the effort for developers to provide them.

Re:Not very well written then

[Mad Bad Rabbit]

Clearly we just need a small set of POSIX apps to do 'git, 'make' and 'gcc' on your phone.
Download the signed source code from the app store.

Re:Not very well written then

[Anonymous Coward]

So app developers can create multiple compilations of the same app, and the app store will automatically give the user the one most compatible to their device?

.

Re:Not very well written then

[tepples]

Yes, as I understand it. Perhaps the biggest things preventing it are 1. developer apathy and 2. use of third-party closed-source native libraries.

Re:Not very well written then

[AuMatar]

In fact one of the main reasons to write your logic in mobile in C is that it will run on any platform- then you only have to rewrite your UI layer. But this isn't what they're talking about- they're talking about multiple processors. However Android allows for fat binary apks with multiple versions of libraries, so it isn't that big a deal.

Re:Not very well written then

[RyuuzakiTetsuya]

For Android, I'm shocked this isn't part of the install process. Either done server side and cached(Compile once, then cache the stored binary) or done on the phone. If compilation fails for the target, the app dev is notified and made unavailable for those on that platform.

Re:Not very well written then

[lister king of smeg]

Clearly we just need a small set of POSIX apps to do 'git, 'make' and 'gcc' on your phone.
Download the signed source code from the app store.

like a gentoodroid

Re:Not very well written then

[rdnetto]

Clearly we just need a small set of POSIX apps to do 'git, 'make' and 'gcc' on your phone.
Download the signed source code from the app store.

You jest, but given that ChromeOS is a Gentoo-derivative, it might not be that far off...

Intel once made ARM processors...

[supersat]

For a while they had their XScale line of ARM processors and SoCs. I think one of the dumber moves they've made was to sell that line of business off to Marvell in 2006 and go "all-in" on x86 before they were ready.

Re:Intel once made ARM processors...

[alen]

i've read that they kept their ARM architecture license. one of the few good licenses where they can make their own CPU and instruction set as long as it's compatible with ARM. like apple and qualcomm. not like the regular licenses where you simply manufacture whatever ARM designs with minor changes

Re:Intel once made ARM processors...

[TheRaven64]

With ARMv8, a lot of companies have this kind of license. I think there are six independent ARMv8 implementations that I'm aware of, but there may be more. Well, I say independent - they all had engineers from ARM consult on the design, but they're quite different in pipeline structure. This is the problem Intel is going to face over the next few years. They could compete with AMD by outspending them on R&D: Intel could afford to design 10 processors and only bring 3 to market depending on what customers wanted, AMD couldn't afford to throw away that much investment. This is how the Pentium M happened: they rushed to market one of their back-burner designs. Now, however, they're competing with half a dozen companies all of whom have ISA-compatible chips and all of whom are content to heavily optimise their designs for a particular market segment.

Re:Intel once made ARM processors...

[bluefoxlucid]

XScale and StrongARM.

Re:Intel once made ARM processors...

[Kjella]

I think you can spin that any way you like it, on the one side they're a many headed beast for Intel to deal with but on the other side they're also in pretty intense competition with each other so they're not willing to share their secret sauce either. You pool resources but you are also at the mercy of a third party which may have interests that aren't exactly aligned with yours. The saying is "divide and conquer", not "spread yourself thin and attack from all sides".

I also wouldn't underestimate the amount of cash and brainpower freed up by AMDs inability to compete at the high end, they're basically printing money in the server and enthusiast market now. Margins and prices are two entirely different things, selling i7-4790K/177mm^2 for $339 makes a bundle and a single Xeon 8800 can set you back up to $6841, I bet Intel pockets thousands on each.

Personally I'm sitting on an i7-860 from 2009, I'm thinking it's soon time to upgrade and while the FX-8350 is barely better it's not really enough to justify the upgrade. So my choices seem like Intel, Intel or Intel.... get an i7-4790K? Wait for Haswell-E? Wait for Broadwell? Either way Intel is going to get my money it's only a matter of how. That's a good position for Intel, not so good for me but ARM is fighting a company with lots and lots of money to burn.

Re:Intel once made ARM processors...

[rahvin112]

Reinventing the wheel 8 times is not effective use of R&D. The minor differences between these ARM vendors doesn't justify the expensive redesign of the same thing 8 times. If Intel goes all in and chases this market that divided R&D will be a significant handicap in competition against a well orchestrated and heavily financed competitor like Intel, not a benefit.

Re:Intel once made ARM processors...

[TheRaven64]

You're assuming that they are all independent. ARM's role in this is to coordinate cross-licensing, so companies chasing different market segments can share R&D results and even portions of processor design.

Apple did this when they switched to PPC.

[hey!]

It worked amazingly well, but it still sucked.

Re:Apple did this when they switched to PPC.

[Anonymous Coward]

Apple came up with a far better solution.

Re:Apple did this when they switched to PPC.

[Trepidity]

They had fat binaries for apps compiled to both PPC and x86, but that wasn't the only solution, since with just that you wouldn't be able to run apps until the developer recompiled and shipped a new version. They also had a binary translator to run unmodified PPC binaries on x86.

Re:Apple did this when they switched to PPC.

[tepples]

Fat binaries were fine when software was shipped on CD-ROM or over unmetered wired broadband. It's less fine when software is shipped over a cellular connection that's billed by the bit. It's also less fine when people routinely uninstall large applications from a device's single-digit GB storage to free space for other things. And without an emulator for legacy applications, it's also less fine for people who want to continue running applications that haven't been recompiled.

Re:Apple did this when they switched to PPC.

[petermgreen]

Yeah it's nothing new to put such emulation in place, apple did it twice when they switched to powerpc and when they switched to intel. DEC did it for windows NT on alpha. Intel did it for windows and linux on itanium (the itanium originally had hardware x86 support but it sucked so much that software emulation was faster and it was removed in later versions). qemu can do it for linux binaries across a wide range of cpu architecture combinations.

It's doable but there is a significant performance penalty. Thats tolerable if your new CPU is significantly better than your old one/competitors one but if your new chip is only slightly better than your old one or your competitors one then it's going to suck badly.

Re:Apple did this when they switched to PPC.

[0123456]

Out of interest, what apps are big enough for doubling their size to matter, yet most of their storage usage isn't data of some kind that can be shared between both versions?

Games, for example, might be a few megabytes of code with tens or hundreds of megabytes of game data.

Re:Apple did this when they switched to PPC.

[ericloewe]

The binaries are a small part of the whole package. Besides, you don't have to download all the binaries.

Re:Apple did this when they switched to PPC.

[BronsCon]

So, then, why not have the device be able to unpack the APK (oh look, it already can!), strip out the incompatible binaries, repack the APK with the remaining bits and pieces, and sign it with its own key? I know that doesn't solve the data transfer problem, but it does (and securely so) solve the "users uninstall largest apps first" problem. Hell, it would even be possible to use a different signing system for repacked APKs (making it obvious) and have the APK subsystem refuse to install repacked APKs from other devices, or at least devices not associated with your Google account (so you know the APK you're installing is from an official source, or one that was repacked by one of your own devices).

Any reason this wouldn't work?

Re:Apple did this when they switched to PPC.

[BronsCon]

You do if the APK is signed. Removing files fro ma signed APK changes the checksum and invalidates the signature. However, there's a solution for that, though it doesn't solve the data transfer issue.

Re:Apple did this when they switched to PPC.

[phantomfive]

What sucked is when Apple removed compatibility for PPC and all your applications (some of which were rather expensive) stopped working.

Re:Apple did this when they switched to PPC.

[ericloewe]

The solution is easy: provide signatures for the various download options.

Re:Apple did this when they switched to PPC.

[NJRoadfan]

Back in the 68k days, there were tools to strip the un-needed binaries from FAT applications depending on the machine you had. The forked files used by classic Mac OS were an advantage, you could store the common resources in the resource fork of the file for both PPC and 68k.

Re:Apple did this when they switched to PPC.

[BronsCon]

Since the developer typically signs the APK before submitting it to the market, then the market signs it again, having the market split the already-signed APK into multiple platform-specific APKs isn't really an option; this brings us back to requiring the developer to upload multiple platform-specific APKs, which is what we're talking about not having to do.

Re:Apple did this when they switched to PPC.

[JesseMcDonald]

If you're going to go that far, why not just have developers sign a manifest which lists each file in the original APK, the architecture(s) it's required for, and a hash of the file? Then anyone could repack the APK to strip out some or all of the extra files, and the end user could still verify that they have all the right files for their architecture, and that all the files present correspond to the hashes in the manifest.

Re:Apple did this when they switched to PPC.

[BasilBrush]

Are you (and were you) a Mac user?

Re:Apple did this when they switched to PPC.

[BronsCon]

Uhm... what? That's totally unnecessary and adds extra work for the developer; this is about *not* requiring extra work form the developer. Clearly, the APK subsystem can already unpack APKs, it's kind of, oh, let's see... what it does. It can also repack them; the functionality already exists. Know what other functionality the APK subsystem already has? Signing packages, and verifying signatures of packages. Well, would you look at that? The APK subsystem can already do what I'm suggesting! Simple to implement, at that point.

You start with an APK signed by the market (and likely also signed by the developer), a known-good point. You need nothing more than that, honestly. And, as far as the market (and most developers selling apps there, I'm sure) is concerned, the inability to safely and securely share repacked APKs is a benefit, not a hinderance, which your over-the-top proposed extension to my solution does away with.

I see where you're going with this and I agree, it would be nice for pirates.

Re:Apple did this when they switched to PPC.

[BasilBrush]

Similarly there were tools to remove the unwanted architecture code from Universal Binaries during the PowerPC to x86 transition.

Re:Apple did this when they switched to PPC.

[phantomfive]

yes and yes (I have a mac and a windows box at home, plus a mac and a linux box at work)

Re:Apple did this when they switched to PPC.

[JesseMcDonald]

Uhm... what? That's totally unnecessary and adds extra work for the developer; this is about *not* requiring extra work form the developer.... The APK subsystem can already do what I'm suggesting! Simple to implement, at that point.

It would only require different work, not extra work, and the difference would be entirely behind the scenes. The developer signs one thing now (the APK) and they would still sign one thing under my proposal (the manifest). In exchange, the end user's device doesn't need to download APKs stuffed full of dozens of megabytes' worth of files for other architectures which they'll never need, and which would only be deleted after download.

Complexity of implementation is pretty much a wash. In both cases all the basic elements are already implemented. In your version you'd need to add the ability to selectively delete files from downloaded APKs on the target device, with heuristics to determine which files are actually needed for a given architecture, and significant problems when it guesses wrong. In mine you'd need to parse the manifest and perform signature verification in individual files rather than the whole APK, a relatively trivial change; modifications would not need to occur on the device, and developers would be free to specify which files are necessary.

the inability to safely and securely share repacked APKs is a benefit, not a hinderance... it would be nice for pirates.

This is a non-sequitur. The only repacking anyone could do while retaining the developer's signature would be to remove files not required for the target architecture. Any other change, such as to remove a DRM check, would result in the files failing to match the signed manifest. On the other hand, if anyone were inclined to share modified versions of the software in either scheme, they need only generate a new signature which their users will trust; the lack of a signature from the original developer would not be a significant obstacle.

not like intel hasn't done this itself

[alen]

taking x64 except for one or two instructions to hurt AMD
or their SSE extensions

Old News

[Anonymous Coward]

This isn't news. Anyone who's been watching the Android space even casually for the past few years has seen this coming. ARM gets a strong foothold and a huge, predominant market share on the hardware side of Android. Intel then decides they want to shoehorn x86 into the mobile space, and they like Android. Chaos ensues.

A more interesting study would be to see what percentage of those top 2000 apps have dual-arch natives depending on your platform. MX Player, for instance, ships a bunch of different native codec packs (separate "apps" you install from the Play Store), compiled for different versions of ARM. Given their build process for this setup, they could probably add x86 (if they haven't already) very easily. There are production x86 Android devices on the market right now, so this needs to happen.

Bigger problem than Intel admits

[edxwelch]

ARM ran a survey of the top 500 Android apps in the market and found that only 20% are pure Java, 30% are native x86, 42% require binary translation and 6% do not work at all on Intel's platform. To make matters worse the level of compatibility is falling. They also found that running an app in binary translation mode takes a huge performance hit."
http://www.theregister.co.uk/2...

Re:Bigger problem than Intel admits

[Anonymous Coward]

Just for balance ....
http://www.theregister.co.uk/2014/06/05/intel_disputes_arms_claims_of_android_superiority/

Re:Bigger problem than Intel admits

[phantomfive]

I can't speak for all app developers, but the first time I got an x86 device on my desk at work, I ran machine code for several hours before even realizing it wasn't an ARM device. It was somewhat shocking when I finally ran 'cat .proc/cpuinfo.'

Re:Bigger problem than Intel admits

[edxwelch]

Yes, unfortunately there is no independant analysis, it's just Intel's word against ARM's.
But in the case of binary translation, nearly everyone (except Intel) agrees that it has a performance impact:
http://blog.apedroid.com/2013/...

Re:Bigger problem than Intel admits

[Anonymous Coward]

Don't quote a tabloid like The Register for balance.

Re:Native

[Anonymous Coward]

You has a probrem with dat?

Thank You Google, you were Wrong.

[goruka]

> two thirds of the top 2,000 apps in the Google Play Store use natively compiled C code

Of course, how else would one make code portable between platforms? Yet their support for using their native Java API from C or C++ is horrible. JNI is unsafe and crash prone and the NativeActivity is so limited that barely anyhthing can be made with it.

Re:Thank You Google, you were Wrong.

[tepples]

Of course, how else would one make code portable between platforms?

By writing the app in JS instead of Java or C++.

Re:Thank You Google, you were Wrong.

[Gibgezr]

I laughed, but in that way that also makes you throw up a little bit.

Not useful to me, but I'll support Intel anyway.

[Dr. Manhattan]

I made an app for Android - ported an emulator written in C++. (Link in sig, if you're interested, but this isn't a slashvertisement.)

So the core of the app, the 'engine', is in C++ and must be natively compiled, while the UI and such is in Java. Naturally, the binary's compiled for ARM first. This actually runs on a lot of Intel Android tablets because they have ARM emulators. But, thanks to a user finally asking, I put in some time and now I can make an Intel version. (Heck, the original source was written for Intel anyway, so it wasn't a big stretch.) The existing tools are sufficient for my purposes. And it runs dramatically faster now on Intel.

However, for the developer it's mildly painful. The main issue is that you have a choice to make, with drawbacks no matter which way you go. You can include native libraries for multiple platforms, but that makes the APK larger - and according to a Google dev video I saw, users tend to uninstall larger apps first. In my case, it'd nearly double the size. So instead I'm putting together multiple APKs, so that ARM users get the ARM version and Intel users get the Intel version - but only Google Play supports that, not third-party app stores. I haven't looked into other app stores, and now it's less likely I will.

Note that native development can be important to apps for a non-technical reason: preventing piracy. An app written purely in Java is relatively easy to decompile and analyze, and pirates have a lot of techniques for removing or disabling licensing code. Adding a native component makes the app much harder to reverse-engineer, at least delaying the day that your app appears on pirate sites.

Actually, it needn't be a technical issue.

[Dr. Manhattan]

As I just got done saying in a comment above: Note that native development can be important to apps for a non-technical reason: preventing piracy. An app written purely in Java is relatively easy to decompile and analyze, and pirates have a lot of techniques for removing or disabling licensing code. Adding a native component makes the app much harder to reverse-engineer, at least delaying the day that your app appears on pirate sites.

Though I do agree that JNI is a serious pain. On the other hand, I've developed for Netware and Palm OS, so my standards for pain are probably artificially high.

Price discrimination

[tepples]

I think they do that already; filter apps you see via a device compatibility matrix.

The challenge is to make the filtered list other-than-empty without having to convince developers to recompile. I imagine that some developers are likely to refuse to recompile in order to price discriminate between the desktop market and the mobile market, where people aren't willing to pay as much per app as in the desktop market.

Re:Price discrimination

[HiThere]

More to the point, you are asking them to cross-compile rather than just recompile. And if you don't have the hardware, you can't test the result.

Re:Price discrimination

[lister king of smeg]

More to the point, you are asking them to cross-compile rather than just recompile. And if you don't have the hardware, you can't test the result.

Because no devs anywhere has any x86 or x86_64 units under their desk. And its not like we have dozens of emulators and virtual machines for ever instruction set under the sun. And it is absolutely impossible to buy touch screen after windows 8 was released... oh wait we have all of those more so than ever.

Symptom of a much bigger problem

[zerofoo]

Microsoft and Intel spent 20 years building bigger. Intel made bigger more complex silicon and Microsoft bloat happily expanded to fill that bigger silicon.

I remember times in the 90s where I was upgrading CPUs for clients that were 6 months old - crazy.

These two companies where wholly unprepared for the mobile revolution that required small and efficient. Neither company could shrink their offerings down fast enough. Unix on ARM was there to fill the need.

I say to both companies - tough cookies. Had they had an eye toward efficiency instead of bloat from the very beginning, they would have been much better prepared for the mobile/app revolution.

Re:Symptom of a much bigger problem

[ericloewe]

Are you kidding?

Atom is now competitive on phones, better than ARM on tablets and Haswell destroys ARM on larger tablets and everything above.

The Windows NT kernel runs smoothly on hardware that would choke on Android.

Don't forget that 90s processors were slower than current mobile processors. Good luck using a Pentium (Pro/II/III) for anything useful these days, regardless of the OS.

Re:Symptom of a much bigger problem

[JohnFen]

I use several PIII machines, and one PII, regularly as servers in my LAN. They perform very well in that role.

Re:Symptom of a much bigger problem

[ericloewe]

Serving what? DNS, NTP and DHCP?

The power savings from retiring something as old as a Pentium II or Pentium III certainly pay for newer hardware.

Re:Symptom of a much bigger problem

[DickBreath]

Hey now, a C64 can run a small TCP implementation with a Finger daemon.

Re:Symptom of a much bigger problem

[unixisc]

Not much. What changed in the 2000s was NT becoming more multi-threaded & multi-processed, enabling performance scaling from multi-core architectures from both Intel & AMD. That's what made it easier for newer & faster CPUs: in the 90s, Wintel PCs couldn't improve their performance by tossing more CPUs @ the box, whereas today, they can. Not so much an issue w/ Unixstations

Re:Symptom of a much bigger problem

[Kjella]

I think you're forgetting how much of a gap there used to be between phones - mostly feature phones - drawing <1W for the entire package on idle and even "ultra-portable" laptops that drew 10W for the CPU alone. The early Microsoft tablets had flopped, there was no middle ground asking for anything in between. I had some of the crappy early implementations of JavaME games, WAP surfing and it sucked real bad, that phones could be really useful wasn't very obvious until the iPhone in 2007. And back then Intel was very busy trying to beat back AMD with their Core processors, while AMD was trying to follow up the Athlons with their K10 arch.

Intel did bring out the Atoms in 2008, which were generally hated for performing so poorly but caught AMD between a rock and a hard place by undercutting their value offering and yet still were far, far too power hungry for mobile. With the cheap netbooks Intel probably thought they had Apple contained, besides Apple never went for the low end market right? Except Apple decided to sell a high-end botique tablet and despite costing as much as a laptop the iPad sold and sold big. So around 2010 some Intel execs go "uh-oh" and in 2012 the first Atom SoCs start showing up, that's roughly the lead time you need to bring up such a product.

Yes, in hindsight it's easy but back then... no, I thought the iPhone would be like iPod + phone, a decent music player that could do calls and texts that could kill off some phone manufacturers but that was it. I mean there were apps before the iPhone but they were expensive, crap and not very user friendly and I never expected that to become a big selling point. That an overgrown phone with 10" screen would become popular was also not on my radar. And even if I was an Intel exec and suspected, hitting those power levels, SoC design, mW idle states so early I wouldn't be playing catch-up to ARM would be near impossible.

That said, I don't think Intel is too late... there's been a few nice tablet/laptop hybrids that let you use the screen as a tablet or dock it to have a laptop, to me that kind of dual purpose is rather nice because for going mobile flexibility is also rather important, if I can cover both needs with one device there's less trade-off. I don't want a Microsoft phone though, but hey... I didn't think I'd ever want an Apple phone either but hell didn't freeze over so who knows what the future might bring.

Re:Symptom of a much bigger problem

[JohnFen]

All of the above, as well as a web server, file server, VPN, and other miscellaneous oddities. Yes, I would get a power savings from upgrading the hardware, but not enough to be worth the hassle of doing that. The existing boxes work just fine. When the day comes that they fail, I'll upgrade.

But my underlying point is that these machines have more than enough horsepower to do these tasks. They're far from worthless.

Re: Symptom of a much bigger problem

[zerofoo]

Yeah, now they are competitive, but the 5 year headstart that Unix on ARM has will be very tough to undo.

The mobile market is very solidly Android and iOS on ARM, and will continue to be so for the foreseeable future.

LLVM byte code

[reg]

I still don't understand why APKs are not just pure LLVM byte code, and either the store or the phone completes the byte code to native compile, including the final optimization passes...

Regards,
-Jeremy

Re:LLVM byte code

[Anonymous Coward]

Because LLVM bytecode is a moving target.

Re:LLVM byte code

[outlaw]

Those who don't remember the past are doomed to repeat it...

http://en.wikipedia.org/wiki/A... (one of the earlier UNCOL)

I'll go back to my cave now

Re:LLVM byte code

[Anonymous Coward]

Bad idea for god knows how many reasons.

http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html

Re:LLVM byte code

[Anonymous Coward]

Write once, debug everywhere...

Re:LLVM byte code

[Anonymous Coward]

Although LLVM bitcode can in theory be translated to native code on a variety of platforms, in practice it is at the wrong level of abstraction for this to work well because by the time you've run your source through Clang you've already run your platform's C header files, with all of their platform-specific bits and bobs, and compile-time endianness detection, etc, and bakes some of the calling convention into the bitcode instructions. You often need to return to the source to produce bitcode that will run well (or at all) on a different architecture.

C was designed to deal with compatibility at the source level, not at the binary level... LLVM managed to shift that abstraction a little, but it's not a magic bullet.

There are a few different LLVM mailing list discussions about this area, but I found one that seems particularly pertinent to your question.

Of course (as alluded to by that thread) the PNaCL project is attempting to add an additional layer of abstraction to solve this problem. They use a mixture of techniques, including defining an idealized "platform" for their toolchain to target, subsetting the LLVM bitcode, and adding a bunch of special intrinsics that their specialized compiler is able to use. It definitely has promise, but I don't think it's really been proven as the ultimate solution just yet.

Re:LLVM byte code

[phantomfive]

The article explains what ANDF is, but it doesn't say what was wrong with it. What was wrong with ANDF?

I'll go back to my cave now

I feel that way all the time at work now, every time my manager tells me about some programming technology a company 'invented.'

Re:LLVM byte code

[Anonymous Coward]

It's also known as P-code or a P-code machine:

http://en.wikipedia.org/wiki/P-code

http://en.wikipedia.org/wiki/P-code_machine

The problem is that P-code can't take advantage of processor specific optimizations such as special instructions. You have to write wrappers around those instructions to make them conform to generic P-code instructions. Thereby defeating the purpose of those instructions.

Re:LLVM byte code

[WilliamBaughman]

That may just be Google's goal with ART (a new Android runtime). Details are scarce but it seems that ART compiles to machine code at install time for better power/performance and especially better start times than Dalvik. It's still experimental but if Android starts to support two flavors of ARM, x86, and MIPS, this type of runtime could be the future.

Re:LLVM byte code

[outlaw]

The article explains what ANDF is, but it doesn't say what was wrong with it. What was wrong with ANDF?

That is a very good question. The quest for an UNCOL (http://en.wikipedia.org/wiki/UNCOL) goes back to the mid 1950s.

A terse, but readable history/background upto and including early ANDF (http://homepage.ntlworld.com/michael.harley/uncol.html) This paper seems to argue that a change in relative costs betwixt machines and programmers changed the landscape to where the complexity was not worth doing a true UNCOL.

Things changed from complexity to business politics, much like we see now with cell carriers (and lockin), customers wanted to be able to move work from one vendor to another, and up sprang another organization to guide that - the OSF (http://en.wikipedia.org/wiki/Open_Software_Foundation)

A changing playing field (enter MS and Apple) and business politics seemed to doom OSF and most of its work - as it turned to 'every man for himself' until Linux came into being and pretty much changed everything... How many vendors still have their own Unix ?

I've been playing in this industry since the mid 1970s, professionally since the early 1980s - most all with a bent towards compilers and operating systems.

My reading of the tea leaves entails a re-birth of the UNCOL idea - and again, due to changing relative man/machine costs, and the prevalence of the IoT.

I believe we actually wind up with the ANDF variant of UNCOL
* You compile language du-jour (with whatever optimization, say to SSA, you can do at a high level), and generate a distribution package (apk, deb, rpm) that includes the UNCOL instead of binaries.
* At install time, the UNCOL is compiled to native (for some definition of native) code... This too, should be optimized

This is where Android is already moving - ART vs Davlik. On smaller devices, you don't want the interpretation overhead unless you have a scheme to handle JiT and building up a native application as the various codepaths are exercised.

Today, we have fewer architectures to contend with (x64, arm, ppc), a better battering ram (open source/crowd source & funding) - ie, driving from the correct side.

This still requires effort by the hardware business to create the UNCOL->Native binary

Re:LLVM byte code

[Anonymous Coward]

What's wrong with java byte code? And why is it allowed to get around it on Android, in the first place.

well...

[buddyglass]

Unless the native code includes ARM-specific inline assembly or uses ARM-specific processor features then the lack of x86 libs is just due to laziness on the part of developers. All the dev would need to do is compile his native code for x86 and include it in the APK. Devs feel free to be "lazy" in this way because ARM is so prevalent relative to x86.

Re:well...

[iggymanz]

wrong, different architectures can and do cause problems for pure C code too. here's tip of the iceberg for you, find out about various ARM model endian modes

Re:well...

[buddyglass]

"...or uses ARM-specific processor features..."

I'll count byte order as a processor feature.

Basically there's C code and then there's architecture-optimized C code. The former should be easily ported between architectures. So, if an app's native code is architecture-agnostic and the dev doesn't include x86 (and MIPS, for that matter) versions then he's just being lazy.

Re:well...

[Anonymous Coward]

What current ARM SoC use BIG endian?

Re:well...

[iggymanz]

nope, there is very high quality code which deals with platform specific issues that are not easily ported, laziness not the issue. For example, POSIX compliance for some functions means the function is declared in the system headers, but it doesn't actually have to be implemented! Your beautiful library that handles things perfectly on all architectures up to the present flops over because Apple decided the function isn't really there even though your code compiiled!

Re:well...

[iggymanz]

http://isp.netscape.com/pf/new...

Re:Not useful to me, but I'll support Intel anyway

[gbjbaanb]

what would be even better is if you could submit your source code to the Google store and it would compile it for you on a server farm and produce APKs optimised for each chipset they support.

i remember the days when sourceforge had such a thing, you supplied your code and it got built for all manner of Linux and (IIRC) windows architectures/platforms.

No, they have not

[Anonymous Coward]

In fact, this is the opposite of a solution, it is a capitulation. A solution was part of the AZ210 phone by Intel, which had an ARM to Intel translator. This phone was quickly abandoned by Intel, and it is now irrelevant, stuck on Android 4.0, and it only supports ARMv6 code. Adobe AIR still does not work, although Flash did at some point.

Fat binaries just shift the blame to the developers. And with the track record that Intel has in abandoning mobile solutions, I doubt anybody will take it serious. Yes, there is the Galaxy Tab series, but it is a budget series - not where the money is. Otherwise mobile Intel is pretty much dead in Android land.

intel and power efficiency

[Mspangler]

"They've been actively focusing on increasing power efficiency for a number of years now, so I have no doubt they'll be able to bring strong competition."

It Intel wants to, they can bring strong competition. They used to have their own ARM variant, but sold it off. They decided that there was no future in low power. Oops.

When they do get a low power chip they seem to lose interest, and then crank up its performance, and its power budget. Then Steve Jobs would yell at them, and they would produce another low power chip. Then repeat the cycle. Now that Steve is gone, will they go back to thinking a 135W CPU is acceptable?

In Intel's world, Grand Coulee dam exists to power their CPU, and the rest of the hydropower on the Columbia is to run the cooling system for that chip. Institutionally they haven't figured out that we have all the cycles per second we need, and battery life is now the critical parameter. Obviously if your dream PC has a 1000 W power supply on a dedicated circuit you will not care about power the same way you will if your phone keeps going dead every time you need it.

As is often the case, the problem is Management, not Engineering.

For the record, I'm using a 2.5 Ghz Core 2 Duo P8700. It's 6 year old technology and entirely fast enough. It has a 25 W power budget. The "ultra-low power" 2 core Haswell has a 35 w power budget. So they have gone backwards. Remember, I don't need more speed, so I don't care if the Haswell CPU is faster.

The question is does Intel get this point? If they say "you are not our target demographic" then fine, and I'll pay them just as much attention as I pay to Miley Cyrus. Which is to say none.

Re:intel and power efficiency

[cb88]

Not really... Integrated GPU. The GPU on your core2 is in the chipset which will blow a few more watts than the 10watts difference to the Haswell. So overall the Haswell will probably win in overall at the wall power measurements.

Re:intel and power efficiency

[aczisny]

The "ultra-low power" 2 core Haswell has a 35 w power budget.

There are many Haswell processors below 25W TDP, in fact that list is made up of most of the actual "ultra-low power" ones (U and Y branded). ARK will list every Haswell processor for you. Do they make lots of processors that draw more than 25W? Sure, but the trend has been flat or downward since the Core 2 release while providing more processing power (so regularly improving performance per watt). If they were binning to throw away anything over 25W they'd just end up with a lot of waste throwing away "bad" parts that work just fine in an environment that isn't that power constrained, like my local desktop. I know my processor is 84W because I wanted good performance when needed and for a desktop that level of power draw just isn't that relevant. When it's not working, it idles about the same as one of the better power bins.

Re:intel and power efficiency

[kevmatic]

You cannot use the TDP (the "power budget" in your post) to compare actual power consumption of the chips. The 35w Haswells will consume less power than your Core 2 chip in actual use, thanks to massive gating and idle power gains that Intel has made. Haswells are also faster, allowing them to go back to idle quicker.

That's the thing about Intel- some chips have higher TDPs, sure, but the performance per watt is unparalleled. You need more ARM cores to do the same things- and many people would like more performance, especially in the server and tablet markets. When the Cortex A15 was released, people were excited that the performance finally approached the Atom, but for some reason were surprised that power consumption started to come up as well... Huh, maybe Intel isn't terrible at the CPU thing after all?

Oh look- The Haswell dual core Core i5 4210Y has a TDP of 11.5W. And the quad core 4702EC is 27w...

They did not go backwards in any way shape or form.

By the way, Haswell's TDP includes the GPU. Penryn's GPU was on the northbridge and not included in CPU TDP. And the 945 GPU sucked compared to all the Haswells' GPUs.

Re:intel and power efficiency

[Anonymous Coward]

I just returned from a trip to the mountains with my Atom-based Motorola Razr-i phone. It was fully charged on Thursday morning. Now back at home on Sunday, my battery is at slightly over 50% remaining, not having seen any charger since I started my trip.

Last week, I drove for about 4 hours, reaching the end of GSM service and putting my phone in airplane mode. I used its GPS features throughout the weekend with the Google My Tracks application to record my hiking or to locate myself with OSMAnd (open street maps for Android). I also used the camera function with HDR processing to take pictures, and I reviewed my photo gallery back at camp each night. I didn't turn off airplane mode until returning to the highway today, four days later.

In my experience after a year with this phone, the screen and radios use almost all the power. The Atom SoC seems perfectly viable for a smartphone... my wife's Nexus 4 had similar battery life over the same trip, but it is also a heavier phone with a larger battery!

No love for Intel XScale?

[jendral_hxr]

Welcome to Linux on PXA! We are just repeating more-or-less the same thing, at least it was good... very good.

Re:Intel is run by the filthy Juden.

[captjc]

Hey Juden, don't make it bad.
Take your sad chip and make it better.
Remember to put it into their phones
Then you can own
The Android market.

Andriod vs iOS development

[fulldecent]

For I minute I though we had it bad because Apple is now creating a brand new language we have to learn just for "Apple development".

But actually it seems...

You're the ones getting fucked.

old news: Lenovo K800 had this 2yr ago

[Anonymous Coward]

I think some Intel PR wanker is recycling this story now that the launch of their K800 phone in India is two years old, and was updated by the K900 a year later. I guess they don't have a phone this year so they're making a news cycle instead. Intel wrote libraries for this phone to JIT-compile arm to x86, like Rosetta on Mac OS X. The libraries made their way into androvm as warez and have been there ever since.

two YEARS old, guys.

Speed is NOT the primary reason for native code

[FryingLizard]

It's not (just) for speed, if at all, it's BECAUSE YOU HAVE PORTABILITY WITH iOS (and other platforms)
If you use Java you're hosed. If you use regular C you can compile on both platforms, with a shim to interface to either iOS or Android as required.
The GLES code can easily be compatible. The UI stuff not so much but (high end) games generally implement their own UI in GL for specifically this reason.

It's not pretty but it's what most pro game developers have been doing since at least 2010, and it's a _hell_ of a lot better than having to totally rewrite your Java app in ObjectiveC or vice versa.

The extra performance is sometimes useful in some places but it's almost always about compatibility with iOS or (more rarely) with existing C libraries e.g. video encoding or whatever.

x86 using the NDK is simple

[Anonymous Coward]

When building with the Android NDK you already specify ABI(s). Newer NDK's are already x86 compatible and have been for some time. So your line line like this:
APP_ABI := armeabi armeabi-v7a

Becomes this:
APP_ABI := armeabi armeabi-v7a x86

And viola! Your code is now built for all three.

This is really not a issue.

Time not important

[ArcadeMan]

Only life important.

Oh wait, wrong topic...

When we talk about mobile devices, efficiency comes before compatibility.

Inaccurate emulators

[tepples]

For one thing, I've written plenty of programs that work in emulators but fail on hardware. (It takes literally four instructions to get Nesticle's behavior to diverge from that of an actual NES, for instance.) For another, the x86-64 box under a developer's desk is unlikely to support multi-touch input for pinch zoom, virtual gamepad, and anything else needing two points of contact.

Re:Not useful to me, but I'll support Intel anyway

[Anonymous Coward]

How to these different apks work, do they share the same bundle id so that if I upgrade from an ARM device to an INTEL one I still get the proper binary or will it suddenly stop working?

Multiple APK info.

[Dr. Manhattan]

Google is your friend, but I'll save you a little time. Some info from Google and Intel.

Should have been plan A

[seyfarth]

Google should have designed Android around C or possibly C++. It would be more power efficient, but, more importantly, it would be free from involvement with Oracle. There is no reason why apps written in C for Android shouldn't be recompilable for X86 or ARM. It does require a bit more care. Fat binaries would also work well enough. Any large app is likely to be mostly data anyway.

Did I accidentally go to The Register?

[Anonymous Coward]

The very next sentence in the article explains that these natively compiled apps _do_ run on x86.

"Apps that use the ARM instruction set still run on Intel mobile devices because Intel-specific Android versions have a compatibility layer called Houdini that maps ARM instructions into X86 instructions."

Re:Not useful to me, but I'll support Intel anyway

[DickBreath]

You could offer the ARM-only and Intel-only APK's on Google Play store, and then offer the larger combined APK file on other stores that do not support processor specific binaries. Make the app version number somehow indicate which one it is, maybe with a one letter value in the version. Then insert these lines into your header files...
#define struct union
#define while if

But Java == Speed!

[Anonymous Coward]

Java is faster than C! Java is faster than C! The profiler just has to run..the GC just has to run..the hot spot just has to run...

So if Java is indeed faster, or as-fast as C, we need to run the Java VM, on a Java VM, written in a Java VM running on a Java VM. More recursion == more speed!

Java is simply a nice sandbox, to limit the damage non programmers and other tinkerers can do, but at a cost of performance.

Want speed? Go native.

Re:Not useful to me, but I'll support Intel anyway

[cant_get_a_good_nick]

..but only Google Play supports that, not third-party app stores. I haven't looked into other app stores, and now it's less likely I will.

With the pushing back on Samzung/Tizen, and new Google Silver program, Google seems to be trying to tighten up. The fact that growing Android with more chipsets has a side effect of making Google Play more central to the experience will make some Mountain View folks very happy.

P8700 doesn't have graphics or memory controller

[Chirs]

And lets be real in our comparisons. The 35W Haswell is going to destroy your P8700.

The i5-4202Y still beats the P8700 handily in cpu benchmarks and has a max TDP of 11.5W, including memory controller and graphics.

The worlds most popular byte code

[radarskiy]

Nobody does x86 natively any more, it's all just additional translation. Back when IBM was producing Pentium and PowerPC, they pretty much only changed the front-end and kept the same exec stack, caches, etc.

If you really needed it Arm could be just another byte code, with just another front end.

re: Popularity? Not really

[mveloso]

Well, this is an unfortunate simplification of reality.

Apple has changed processor architectures for various reasons, but the generally accepted reason for moving to the x86 architecture from PowerPC was that IBM was unwilling to continue to invest in a low-power version of the PowerPC line. You can't build a Macbook air with a PowerPC unless you have a lap made of asbestos.

There were other benefits as well, but that was a significant one.

Apple didn't move to x86 because it was popular, Apple moved to x86 because Intel was able to provide them the thermal envelope they wanted.

Nobody ever develop software on this site?

[Anonymous Coward]

I find the comments from so-called experts who claim that x86 can never ever run Android apps to be rather amusing considering every Android app out there is developed on an x86 PC and the first round of testing & debugging takes place in an Android emulator running on an x86 processor. Apparently the concept of compiling code for some random Android app is now considered to be FAR too difficult.

Here's something else that will blow your little minds: Every single iOS application that exists has not only been compiled for x86, but x86 has run every iOS app there is BEFORE Apple's ARM chips. That's right kids, the iOS development environment includes an iOS simulator -- not an emulated ARM environment but a simulator that run x86 code compiled apps -- for the initial build & testing before the apps get tested on actual phones.

But go on believing that a "compiler barrier" prevents your fart app from running on an x86 processor. After all, we all know for a fact that Linux has never EVER been ported to different hardware platforms... oh wait.

People comparing x86 performance to other ISAs

[overshoot]

Might remember to do so at the same process node.

An Intel x86 chip build on 22 nm stands a very good chance of blowing the doors off of an ARM (or MIPS, or ...) built on 45 nm. However, this is not a decisive win for the x86 ISA.

Found it!

[Anonymous Coward]

Got your citation right here!

MIPS ain't heavy, it's my brother

[marxmarv]

It's worth noting the inventor of the MIPS processor (John L. Hennessy) also coauthored the leading computer engineering texts. Write what you know, they say....

Why not a hybrid x86/ARM chip?

[Anonymous Coward]

If Intel is serious about smartphone/tablet SoC's anyways, the radio baseband will likely be ARM anyways, combine into a single monolithic hybrid chip, with x86 and multiple ARM cores. Since most discrete chips for Bluetooth/WiFi and GSM/UMTS/HSPA/LTE have an ARM core already, combining would reduce power consumption and possibly eliminate an ARM core or two. The final obnoxiousness would be effectively running a heterogeneous cluster OS variant of Android on the phone, but to a lesser degree Intel had already started research on this with NTT for hybrid phone/cloud VM personal cluster instances, telegraphing HID actions to the cloud VM and streaming display info back so the VM does the grunt work usually.