Sir is a title
Does this mean Intel will change Microsoft's status from 'ARMless' to 'mostly ARMless'?
I was just going...
Microsoft may have caused a disturbance in the PC Force with its announcement that the next version of Windows will run on ARM processors, but Intel isn't worried. "You want to come and party in our kitchen and rattle the pots and pans? I've got Sandy Bridge. Bring it on," Intel spokesman Dave Salvator told The Reg on Friday …
"like considering things like an out-of-order processing execution engine, going multi-core, and cranking up their clocks."
Crank the clocks up like Intel did with the P4? How did that work out for them? In 2004 they released the 3.8GHz P4, they haven't reached that again with any of the newer chips.
On a daily basis, I work with and develop software which can be broken into two categories. Stuff that can be spread across a bunch of processors. And stuff which is linear in nature and you can't do the next step until the previous step is finished. For example, the video codec I work on performs GREAT in parallel across 32 or more processors when looking at each individual part of the picture it's compressing. But when it's done, you need to perform what's called entropy coding which is a very linear process to produce the final stream. There is simply no possible way to split that task into parts that can be consumed by separate cores.
Therefore, to handle the 800 megabytes per second of data that is being "entropy coded". I need a processor that can sustain a minimum of 3.4 Ghz and handle multiple operations at a time to simply produce a 90 megabyte per second stream (these are bytes not bits I'm talking about).
Sure, what I'm doing is hard core and almost no one is working with that much data at a time, but it's just an example of what a "professional work day" is like.
How about the nearly million people a day programming using C++ compilers. Those things need to cope with hundreds of megabytes of data per second to compile and optimize a program. Sure, you can wait a little longer, but in a "trial and error" phase, you might be hunting down a bug and you want to print a message in one spot. Then another, then another. Seconds very quickly turn into hours of lost time. So often programmers will code for their monster 8-16 core x86 machine at 3.4Ghz to test the code on that system before moving it to an ARM device.
ARM processors WILL need to be produced that are capable of running at 3Ghz and have multiple cores... OR programmers will maybe code for them, but they won't use them as their native programming platforms. And as a result, the quality of the code WILL suffer. If you can't program on the machine you're programming for, the amount of time necessary to accomplish each task is MUCH longer and fixing bugs is MUCH harder. Programmers don't want to sit around and wait an hour to run their code.
So, when you bring up that Intel peaked at 3.8Ghz, that is true. In fact, for running electronics engineering tools here, we have several overclocked systems with complex cooling (liquid, gas, etc...) to get an extra few Ghz out of our machines because 3.8Ghz is NOT even close to enough for some tasks. Those machines have 12-32 cores each and 75% of the job can not be run on more than 1 core given the all operations are dependent on previous operations.
If you don't clearly understand the tech, don't comment on it. It makes you sound kind of lame.
You case is at one end of the computing spectrum. Most PC's do not require the sort of horsepower you are describing. Even hardcore coders can get by with lower power machines as and when Although I do have a quad code box here, and its does help with productivity - cross compiling to Arm targets, but it is not essential. The important part is cross compiling - the end device does NOT need the horsepower of the development device. So the dev device can be a Wintel box - doesn't need to be Arm. I disagree this leads to worse code. People work with coprocessors, and cross compilers all the time (think the mobile phone industry) and although it's not as fast, the code produced can in fact be better quality - because you have to be more careful (and you can run on simulators which can provide better error checking)
(and I am not quite sure why you are doing the hard work on video encode on a general purpose CPU when there are hardware solutions that can do it for you without the expensive multi core wintel boxes you describe. I'm sure there's is a good reason - just would like to know what it is)
> to handle the 800 megabytes per second of data ... I need a processor
> that can sustain a minimum of 3.4 Ghz
That's related to your choice of processor.
It is theoretically possible to get by with a processor whose clock speed is your target data rate divided by your bus width. Your 3.4GHz need is much more than that for several reasons - some of which pertain to the architecture of the chip. The classic x86 architecture has all sorts of terrible problems - somewhat alleviated by the SIMD instruction sets - that mean you waste many clocks compared to a more efficient architecture.
But with number-crunching, it's always about I/O. It doesn't matter how fast the core can be clocked - if it has no data to process, or hasn't shifted the last lot of results out just yet, that core is idle. Avoiding register re-load and pipeline stall will always get you more advantage than another 10% on your clock speed...
> ARM processors WILL need to be produced that are capable of running at 3Ghz
I doubt it.
> OR programmers will maybe code for them, but they won't use them as
> their native programming platforms.
I know a number of companies who compile code on their targets. There is good reason for that, sometimes.
> the quality of the code WILL suffer
You're going to have to produce some sort of, y'know, evidence before making such sweeping assertions that fly in the face of techniques that have been producing mission-critical systems for decades...
> 75% of the job can not be run on more than 1 core given the all operations are
> dependent on previous operations.
You missed out the vital clause "with the knowledge we currently have at work". Have a read of some of the old Transputer literature; most problems - even those that appear fully serial in nature - can be factored across multiple cores if the appropriate techniques are applied.
A couple of years ago, I ran some performance analysis for one of my customers. I produced more performance in that one afternoon than his in-house coders had found in several years. He actually had his brochures re-printed because his systems were so much faster. And I didn't touch the CPU clock speed, nor the number of processors, because neither of those parameters were important - the cores were slow because they were stalled, not because they weren't being driven hard enough.
For an alternative point of view, read this:
The ARM Cortex A9 is expected to have "comparable performance to the Atom". And here's a comparative Atom vs. Cortex A9 demonstration video here:
The Atom netbook on the left is running at 1.6Ghz with graphics acceleration, while the Cortex A9 development board on the right has no graphics acceleration enabled (it's a development board) and it's running at only 500MHz. YES! A quarter the speed of the Atom CPU, and it's only just slightly slower at rendering web pages.
Despite this impressive performance, ARM are clearly not hoping to compete with Intel in terms of their "Core" line of processors, but they're within touching distance of the Atom (in terms of raw performance, possibly better in clock-for-clock terms) and they blow Atom away in terms of power consumption.
In terms of "the experience" I'd say ARM with the Cortex A9 should now be able to compete favourably with the experience you get from an Intel Atom based system quite easily, and when they're both running Windows the ARM based system may well be the better option over Atom.
The Intel spokesman is only saying what he has to say to keep his job, and he knows he's talking cr@p just as well as the rest of us. The threat from ARM is very real.
The problem is not the CPU performance but the software or lack thereof for it. A trivial example - I can fire up Lord of the Rings Online on my Atom based Netbook. It's no speed demon and all the settings are at their lowest but it runs.
I couldn't even install the thing on ARM. Why can't I install the thing on ARM? Because MS say Windows on ARM won'emulate t x86 instructions and the chances of Turbine producing native binaries are likely to be 0.0001%. It's too much hassle to port software and maintain it on an ongoing basis.
That's stupid game amongst millions of programs past and present which will never run on ARM. Sure there might be some very prominent native ports but it certainly doesn't justify any consumer buying or using the device as a Windows device. I expect Windows on ARM has more practical use in servers, or perhaps in tablets but ONLY where Windows is acting as a glorified shell for some touch interface and users have low expectations of its practicality as a replacement for an x86 netbook.
Personally I think MS would get a lot further pitching the idea if it had some x86 emulation either assisted with hardware or not.
> Because MS say Windows on ARM won'emulate t x86 instructions
[ As a total aside, this is one significant strength of open-source software that is *really* going to become important in the coming years. Binary not available for your platform? Grab the source and recompile. Yes, you will be able to. As will your granny. ]
> I expect Windows on ARM has more practical use in servers
I don't think Windows on ARM has any place whatsoever.
It's either doing Windows-type things - in which case, it'll hit the compatability barrier you mentioned above - or it's doing generic browser-type things - in which case, you gain nothing at all from having Windows.
The former dilutes the Windows image - stuff will frequently just be borked. The latter adds cost to the BOM without adding any functionality. Microsoft would look ever more like a leech, and people will tend to experiment with other OSes...
I firmly believe that full-fledged Windows on ARM will remain vapourware. I think Ballmer announced it just to stop people playing with cheapie Android tablets - which 3 months ago were terrible, but today are getting rather good.
This guy sounds just about as clueless as a PR berk could get, complete with his self-made terminology and technical words. The - clearly rattled - bluster might fool a few and comfort some nervous shareholders, but:
..... I doubt if even the most died-in-the-wool Intel fanbois will be chomping at the bit to get their hands on any Moorestown product (if any actually launch). Reports indicate that it has roughly 1/3 to 1/4 the performance per watt of the latest A9 cores @ 40nm. Awesome!
The newer GPUs included on the the A9 SoCs are also vastly more capable than the integrated graphics on the Moorestown platform. The tri-core and quad core A9s will just extend ARM's lead.
Whether it be Eagle or other as yet unnannounced products, ARM will then start a major push into the server, desktop and laptop market. People who doubt the capability of these future SoCs should take a look at what is widely touted as the very slowest A9 dual-core (Tegra 2) can do on the Motorola Atrix 4G.
The Ivy Bridge / AMD equivalent laptop I intend to buy at the end of this year should be my last x86 portable. The Bulldozer desktop I intend to build in Q2 will probably be my penultimate x86 desktop, though it wouldn't surprise me if it was my last.
I think x86's fall could be a great deal more swift than many realise. I also wonder if Windows 8 will mark a return to OpenGL for MS and the death-knell for DX. The latter made a lot of sense when OGL was very lacking and directionless and when they had nascent console platforms to push and define the boundaries of, but now that OGL has caught up, much less so.
Most of the technology related statements made here don't hold water. The two that stand out most are:
1) Out-of-order execution
Cortex A9 ARMs (of which Snapdragon and Tegra 2 are derivatives of) in the latest phones (and tablets and netbooks like Toshiba AC100) have OOO Execution. Ironically, Intel's XE compiler is good enough to minimize the impact of in-order execution. Sadly, most developers don't use it, even though it is much, much better than the rest.
2) HD Video
I find the mention of HD video being a defficiency on ARM to be laughable. Anyone who tried playing back HD video on an Atom N450 that doesn't have an external Broadcom Crystal HD accelerator will know that Atom N450 can't do it, either.
And while we're talking about this, Atom N450's total system TDP (CPU+mobo) is about 25W (measured - I have some Advantech N450 based industrial motherboards), and that includes only the CPU, NB, and a CF card. The Toshiba AC100, including the screen which according to the Samsung's spec sheet draws about 3W, pulls 6W total. So call it 3W without the screen. That is more than 8x improvement. Now consider that the Atom N450 is single core, and Tegra 2 is dual core. And I can vouch that the Tegra 2 is faster (tested with a real-world redneck-test of kernel compiling) than the Atom N450.
I really hope that Intel can use this game-change and the vastly overdue death of x86 to come up with something new and even better. They still have by far the best silicon processes.
There have been ARM powered Linux systems for years, both on old Acorn boxen and other bespoke boards running various ARMs.
Windows, on the other hand, is new to the ARM side of things. Given the limitations of earlier ARM processors, putting something as inefficient as Windows on one wasn't likely to happen, even though it has been proven that they could happily run GUIs of other types, including various *nixes, RISC OS, more recently Android. That's before we even get to the knotty problem of device support, something that causes headaches even in the traditional Windows x86 heartland.
As an Acorn user of some considerable years, I suppose I'll find it particularly ironic if and when Microsoft rolls out an ARM powered Windows system. As for Intel, some of the blurb is to be expected from them, especially as they no longer seem to have any time for their own ARM-bastard children, the StrongARM and the XScale. However it isn't the first time that Intel have blundered with the selection of their future tech, so we shall have to wait and see what comes next.
Linux is blessed in that most of the software users need everyday are available as source code. So whether Linux is running on x86 or ARM is largely academic to the end user. Even so it can still bite, e.g. WINE doesn't work on ARM, neither does Flash, or some proprietary drivers.
Even so Linux is vastly more ready to power low power ARM based netbooks than Windows is. The danger is that just like Linux powered the first netbooks, MS may catch up in time, providing emulation or whatever to ease the transition. I also think MS would be better positioned for tablets. Ubuntu or whoever had better make a damned good first impression to get the OEMs on board and maintain the momentum to keep them.
Intel says "Windows is too bloated to be saved by an ARM processor", so people will keep buying hot power hungry x86 boxes to make it run acceptably fast?
Quite possibly true, and MS' announcement is all to stall OEM defectors to Linux who can compete with Apple on use-versus-battery life.
As for playing the 'HD video' card in his argument, surly that would be subject to hardware acceleration in the graphics chip set, no?
That rant by Intel/Dave Salvator is mirrored in another parallel/dimension and is evidenced in the these few words, which are a panicked admission of catastrophic failure/lipstick on a really sick pig ........[blockquote]"We have seen increased evidence that a self-sustaining recovery in consumer and business spending may be taking hold," Mr Bernanke told the committee.
However, the labour market had improved "only modestly at best", he added.
"Persistently high unemployment, by damping household income and confidence, could threaten the strength and sustainability of the recovery," he continued.
At the same time, inflation was likely to remain "subdued" for some time.
Federal Reserve Governor, Elizabeth Duke, said there was a "lot of slack" in the US economy and the government still needed to support recovery.
"My view would be that we need to have a credible plan for reducing the debt and the deficits over the long run, but not in the immediate time frame. In the immediate time frame, we still need to support a recovery that's just getting started."
“If the financial markets start questioning the creditworthiness of the US government - or the long-term value of the US currency - things in the global financial system could get quite ugly, quite fast." .....Stephanie Flanders ..... http://www.bbc.co.uk/news/business-12136155 [/blockquote]
And support for the diseased pig identifies the rotten pork traders and mad media moguls turned mega moaning minnies and traitors to the cause of Peace and Stability, Harmony and Prosperity. The American Dream, which is also an entertaining little animated video by the Provocateur Network worth watching [although they are trying to get folks to buy it to watch, so you may have to look a little harder than usual for it in its free Youtube versions] turns to Global Nightmare.
And they did all that themselves, and have only themselves to blame and punish. And how pathetically stupid was/is that.
""There's some immutable laws of physics that say that if you do <go bigger/faster> your transistor count is going to go up, so is your voltage, so is your heat, so is your power."
Probably true. But it's all relative. ARM are already so far ahead of x86 in this respect that even when ARM clock faster and add more cores and more memory ARM are still going to perform better for the same power or use less power for comparable performance.
How does that work? Well part of it is stuff that x86 simply can't do without stopping being x86. Things like ARM code density (how much memory it needs to do a given piece of work) cannot be bolted on to an x86 without it stopping being an x86. That's because the ARM instruction set and architecture isn't evolved from a 4bit washing machine controller derivative, it's designed clean from the ground up with features like predication (less need for branches so code is smaller AND faster) and the ARM/Thumb subset using 16bit instead of 32bit instructions for ultimate code density.
Part of it is also about the years of experience of SoC design that the ARM licensees have. Neither Intel nor any of their recent acquisitions (McAfee??) have that experience or skill, and that kind of thing doesn't come overnight.
So, other than their core Wintel platform, what successes have Intel had in the last decade or so?
So, Microsoft ports Windows to the first new architecture in years, with the trigger level for MS set much higher this time because of the wasted efforts of the old Alpha/MIPS/Power/Itanic ports, and it's not a big deal? Yeah, right.
An ARM port had been on the cards for a while as MS can saw the low-end SmartBooks, phones and especially tablets cannibalising the mid-range and even threatening to go into the server realm. And they've got no real offering for that hardware. There's a massive difference between WinCE on ARM and the mainstream version of Windows.
Despite what Intel says, and the fact they have so much to say about how it doesn't matter underlines this, ARM is going to seriously threaten them (and AMD too) in the long term.
Can't agree that AMD will be threatened by this. They already licence x86 from intel and I doubt they have any sort of prideful attachment to that platform. They could just as easily licence ARM if they saw any benefit to doing so.
Intel on the other hand, despite once being an ARM licencee would see it as a massive ego deflation to be forced into becoming just another ARM shop with absolutely none of the monopoly bullying power that they currently enjoy.
They will be pissing in their pants. AMD, not so much.
They've got a lock on the vision now. Can they execute?
By the time real Windows runs on ARM (2013) Intel's Atom processor will be on the 16nm node. Interesting. And Intel's under no further obligation to facilitate Windows on this chip so they can instead deliver the best engineering they're capable of. They can let go of legacy technologies and let whoever builds the best OS for it win. That sounds like progress to me. I wonder how nimble Microsoft's OS porting team is. I'm quite confident in the competence of the Linux crew that's going to be building the kernel for Android - they've even ported their ware to run on a dead badger.
I guess we can dismiss Windows 7 tablets now since even Microsoft won't stand up for them. That has to have all the hardware partners who went to such great engineering feats to have the thing ready for CES feeling a bit jilted. And the ones that have been keeping the faith and not building ARM because they were promised that would go are going to be looking sideways at future promises. They've lost last Christmas and now won't have product under the trees next Christmas either. Asus, who had a Snapdragon mini-notebook ready in the summer of 2009 but was talked out of it in mid-tradeshow must feel especially harmed. When they do finally get to market now they're going to be trying to crack an installed base of over 100 million units with a new and different technology that's untried and not appreciably better. Not a good place to be.
So at least we don't have to hold off anymore, waiting, before we buy our tablets. Who's in motion on the ARM tablets, to bring us the revolution until Microsoft, Intel and their herd get their act rolling? Apple of course. Samsung and HTC. Visio and, oddly, Dell. All of the cellular providers naturally, and Amazon, and Google. HP may come out of nowhere with WebOS, but somehow I doubt it. No ASUS, Acer, Lenovo, IBM or Toshiba.
You certainly don't need x86 for great video which is why phones now do easily 720p and higher encoding.
So, Mr. Salvator, when it comes down to it, what do you really need x86 for? The ARM design allows hardware optimisation such as video or cryptography on a per device basis. This is great engineering.
The x86 is needed to run the vast, uncountable number of Windows apps in existence. Games, productivity apps, utilities, databases, web servers etc. If Windows on ARM doesn't support them through emulation, it immediately consigns itself to a very small niche of uses where MS can persuade a company to port their code to a new hardware architecture. Easier said than done but for the most trivial of apps.
The Atom might be power hungry by comparison but the reason it's popular is because it *does* support those apps. If you don't need that support you may as well not even bother running WIndows at all.
Besides, I think Apple would be better positioned to go to ARM than MS and even they haven't tried it yet. Just as they jumped ship from PowerPC to x86, they could do the same to ARM. Linux is better poised again by virtue that most of the code is clean and portable to begin with and recompiling is part and parcel of building a new dist.
As for video, crypto etc. it's a side issue. Intel are moving their GPU into the same silicon as their CPU and I expect it's the least of their concerns compared to CPU power consumption.
"The x86 is needed to run the vast, uncountable number of Windows apps in existence. Games, productivity apps, utilities, databases, web servers etc. If Windows on ARM doesn't support them through emulation, it immediately consigns itself to a very small niche of uses where MS can persuade a company to port their code to a new hardware architecture. Easier said than done but for the most trivial of apps."
You already said this once before, but saying it again doesn't make it more true. If Windows on x86 were absolutely required for all computing, we wouldn't have seen the likes of netbooks, and people wouldn't use stuff like Google Apps. You can moan all you like about netbooks being bad for gaming, or Google Apps not delivering the full Microsoft Office experience, but about 2% of users share your concerns and most of that 2% will admit to not really being sure when quizzed about it.
And databases and Web servers needing Windows on x86? Only if your universe is one where a gold-plated big name on a big badge for lots of cash is necessary when acquiring and deploying software. In the real world, portable, (typically) open source software is cleaning up in those areas, and is not in any special need of either Windows or x86.
"You already said this once before, but saying it again doesn't make it more true. If Windows on x86 were absolutely required for all computing, we wouldn't have seen the likes of netbooks, and people wouldn't use stuff like Google Apps. "
I never said Windows was required for computing dummy. I said x86 emulation was required for a satisfactory Windows experience. If I buy a Windows tablet, or a Windows server I have very reasonable expectations that it is able to run Windows apps. Windows on ARM is largely pointless and redundant without that emulation and is consigned to niche uses.
"And databases and Web servers needing Windows on x86? Only if your universe is one where a gold-plated big name on a big badge for lots of cash is necessary when acquiring and deploying software. In the real world, portable, (typically) open source software is cleaning up in those areas, and is not in any special need of either Windows or x86."
I never said that databases had to run on x86. Go read what I said. Potted summary, I said that without emulation only databases and other server apps are likely to get native ports to ARM. Windows databases. Just like what happened with alpha, Itanium etc. where they became niches and eventually got the heave ho.
Windows devs simply won't be bothered to support multiple architectures unless their apps are clean .NET apps, or MS produces something akin to LLVM that allows C/C++ apps to compile to a target neutral bytecode which runs on any platform. Even then it doesn't help run all the legacy apps in existence.
I'm also quite aware that Linux is more portable and I said that in this very thread. I've been an ardent supporter of Linux for many years, but the topic at hand is Windows on ARM and it's practicality with and without emulation.
"I never said Windows was required for computing dummy."
What's a "computing dummy"? Clue up on punctuation before slinging insults, buffoon.
"I never said that databases had to run on x86. Go read what I said. Potted summary, I said that without emulation only databases and other server apps are likely to get native ports to ARM."
No you didn't. You wrote, "The x86 is needed to run the vast, uncountable number of Windows apps in existence. Games, productivity apps, utilities, databases, web servers etc." Although you probably meant to use a colon rather than starting a new sentence.
In effect, you were whining that all that stuff just can't be made to run on anything other than Windows on x86, and that isn't true. Sure, Microsoft have to persuade developers to deliver stuff on other architectures, and with proprietary software, people can't just step in and port the stuff themselves, but there's a ton of stuff that could be made to work for Windows on any architecture in fairly short order given toolchain availability.
What you're arguing is that every last little shitty utility and written-for-Win95 application must be available or the punter is being short-changed. Well, I doubt that the average punter really cares, even if they are drawn towards the Windows logo: they'll be using their Facebook and YouTube stuff and only occasionally wondering about whether some game or other runs; if Microsoft has any level of success, such games will become available, anyway.
I think you need to learn how to make a solid point before accusing other people of missing one.
'Create' is becoming the new 'consume' ???
Interesting thought that ... I thought consumer tech was swinging away from 'creation'? Certainly Apple's whole view of consumer tech is primarily on consumption and not creation and a lot of punters seem to buy into that? I am sure thing move in cycles so this could change, but currently I do not see the momentum swinging to 'create' or else the Apple iPad and legion of clones would have been based on their full OS and not the mobile iOS version with just about zero easy-to-use support for creation?
Content creation may be growng, but I suspect that the proportion of consumers purchasing devices for this purpose is smaller than those purchasing devices focussed on consumption? Plus creation today does not necessarily equal desktop PC requirements as higher MP counts become commonplace in phones with the functionality to perform light editing and upload directly to FB et al. And power IS important for these devices hence ARMs dominance.
The question is really what Microsoft thinks (or knows) it can do. My guess is an attempt to have a unified OS across desktop and mobile offerings even if certain features are disabled on platforms requiring more oomph. MS cannot be blind to the advances ARM have made and the future market for mobile / embedded computing is way larger than the current desktop market.
Yes, it's "the user experience". Apple indeed built its success on that, time and again. Yet most of us see themselves stuck with an inferior experience and don't seem to mind. So it's not all that important, either. What he's really referring to is "it's the expectation", and expectations can be managed. redmond does that really well, even selling an inferior experience and making people like it. I don't thank them for it, but there it is: They do do that.
"Behind every great experience is great performance. And behind every great performance is a great engine."
I liked el reg's coverage of how symbian came to be. Psion's gear sported a great software engine, making do with very little cycles and bringing a performance so fantastic that it still has its affiniciados. Don't need grate powar from teh intendo for that. If you're making do with an inferior experience that wastes cycles, however....
The power envelope argument is a bit moot, too (see p4 reference upthread). It means he's assuming there's a linear relationship between power and performance, and that isn't true. He's also assuming all chips are equal in quality, and that too isn't true. Getting rid of x86 --something at least some of us have deemed overdue for decades now-- might disprove that assumption. Though that getting rid bit has successfully been set back by intel's attempt to do it by themselves. They just couldn't do it. What that says about intel I'll leave as an excercise.
So there's holes in his argumentation a solid competitor could drive a truck through. But as we've seen with transmeta and be for example, the entrenched industry is willing to squash the small inventors and innovators in the name of, well, they all call themselves innovators, don't they? Maybe I should patent that. But I digress.
The most important point is probably that redmond sees itself forced back to this multi-architectures thing, something they abandoned once already. That probably influenced intel's thinking too. I wonder if they've managed to fix the bags of downright excreable code with lots of stupid little machine dependencies snuck in with windows 6.1. Probably not... yet, if ever. So Salvator may turn out to be right after all, on the danger of redmond shaking its intel dependency.
"the future market for mobile / embedded computing is way larger than the current desktop market"
Microsoft have known this for years, and failed abysmally to do anything about it with Windows CE and its assorted failed variants. Windows HPC? PocketPC 200x? <edit for brevity> Windows Phone 7? Who cared?
When it doesn't absolutely have to be Microsoft, sensible people (be they end users or system builders or even the occasional clueful IT department) don't want Microsoft. Especially so in the embedded market, where engineers not IT people generally make the decisions, and where performance, reliability, and value for money are factors to think about rather than deliberately ignore because there's a nice sweetheart deal at stake with the supplier in the picture.
Even in the set top box market where MS's best friends in the "content providers" and "rights owners" ought to have been able to pull a few DRM-related strings, MS haven't had much visible success. In the UK their only visible success in STBs looks very much like it was the result of a top level CEO-to-CEO deal driven by MS' desperation to show off a success in the STB sector, rather than anything driven by STB product people following an evaluation of all relevant options.
If MS wanted to be taken seriously in the embedded market, they could have bought Wind River (for VxWorks, a real embedded OS). Microsoft didn't buy Wind River, Intel did. Or MS could have bought one of the successful embedded Linux vendors (MontaVista?) or maybe even the QNX folk. But that would have meant publically admitting that Windows, be it CE or classic, was not the one size fits all universal solution (which is of course true, but...).
So, given that Windows CE is basically dead in the water, what's left for MS in the embedded market?
Unless Microsoft's vision is for every Microsoft-badged embedded system to have enough flashdisc and RAM to cope with a complete copy of XP Embedded (which isn't going to happen), not to mention vendors (and therefore customers) paying the Windows tax on every box shipped, MS might as well give up soon on the embedded market.
Just let them do us all a favour before they do that, and hang around long enough to legitimise ARM as a player in the traditional x86 territory of notebook, desktop and server market (as well as ARM's current home territory of consumer and embedded electronic stuff).
Surely someone stating such a self-evident truth need not hide behind an AC mask. Not an intel employee are we? But I do wholeheartedly agree with you. Marvell's ARM range, derived from Intel's XScale, is just one of many very nice looking ARM offerings.
Just goes to show how dangerous short-termism driven by shareholder and stock market pressure is. Intel sold XScale to Marvell at a time when Intel were being hammered quite hard by AMD. Intel needed a quick boost to prop up their share price (and executive's bonuses?) and selling XScale fitted the bill. To justify the move they invented this new strategy - Atom being the result - without paying any attention to certain fundemental physical truths:
1) ARM's better code density is always unfailingly going to translate in to lower power and smaller memory sizes;
2) a single ARM core (excluding on chip peripherals) hovers around about a count of 32,000 transistors, and an X86 must be many times that so is alway going to draw more power;
3) Intel's silicon processes are never going to be sufficiently far ahead of the competition to make up for those deficiencies of X86. At least not for very long anyway;
4) No matter what Microsoft were saying, Microsoft's exclusive loyalty to Intel could not be guaranteed. Same goes for Apple if it comes to that;
5) Demand for raw computing power from consumers was never going to keep growing; most desktops were and still are woefully under employed as it is;
6) A lot of data centre workloads are actually about IO performance, not computational power (e.g. Google's supposed use of Via's processors)
7) More tenuously - the need for computing power in the client machine would decline as cloud type services took off, supported by ever increasing internet bandwidths (supplied perhaps by Intel's own WiMax???).
They may indeed have been an element of corporate pride influencing their decision; X86 has been phenomanlly successful. But past success is no indicator of future performance, so the saying goes. Intel haven't developed a new sucessful chip type for many years now. Itanium has been a disaster; AMD did x64, which Intel had to copy; i960 wasn't too popular; anyone remember i860? Have they lost their mojo?
Intel could have used some cold hearted soul searching deep thinking back then and might have realised the 6 or 7 points I outline above. Even if someone in Intel did do that thinking it might have been very hard for that person to get a fair hearing.
I have to say that Acorn (now ARM) did do a phenomally good job all the way back in the 80s. I bet those few engineers had only the wildest dreams about where their architecture might end up, none of which are surely as impressive as today's reality!
Pint - someone deseves a toast for their stunning successes so far
Windows on the ARM architecture is, indeed, not much of a threat to Intel in the short run.
Great, Microsoft can port Windows. Does that mean that when I upgrade my CPU, I can recompile my old copy of Lotus 1-2-3 or AmiPro and make it run on my new machine at native speed? Oops; unlike the case for Linux, software for Windows, being commercial, is usually distributed (because it's sold for money when it's distributed) in the form of binaries, not source code.
So a great many consumers and businesses would just shake their heads and say "That's nice, but it's not really what I wanted" when presented with an ARM machine running Windows.
Such a machine might be a great Internet appliance, or fill some other niche, but in the conventional computer market for desktops and laptops, it would be struggling against the very same forces which explain why more people aren't using Macintoshes - or Amigas, or Atari STs - these days.
And, to top it off, Windows users are not the same kind of long-suffering people who have the patience to put up with their operating system being ported, over time, from the 68000 to the PowerPC to the x86, one after the other.
OK, so everyone's talking about multicores, right? How about an asymmetrical multicore? An ARM core runs the operating system, office suite, web browser et al, and legacy apps run on an x86 on the side.
As the x86 is a "hot" chip, it could be powered down when on battery and not required, much like the current tranche of laptops with two graphics chipsets. If the OS isn't on it, there's no problem, surely?
This is how I always envisioned the endgame for x86, but everyone said asymmetrical multiprocessing was too complicated to schedule, but now that GPUs are now fully-fledged computers in their own right rather than highly limited coprocessors, we're working in an asymmetrical environment already. The problem is already solved.
I respectfully submit that such a hybrid is not necessary for MS's strategy.
Firstly, a .NET app wouldn't even need recompilation; the CLR environment for ARM would be perfectly capable of running a .NET app as the CLR environment for x86.
Secondly, ARM (ignoring thumb mode) tends to be a 32bit little endian processor. x86 is 32 bit little endian. If I were to have to recompile source code written for the x86 on another platform, retaining the same bit width and endianness removes 95% of the difficulty (assuming that MS offer the same APIs). It's no where near as hard a job as Apple had when they moved from PowerPC (which they used as big endian) to x86 (little endian). From what I remember reading in the dim and distant past, ARM deliberately chose 32bit little endian in anticipation of MS making this move.
Thirdly, get just a few key apps ported and the rest of the world will follow suit. I would suggest that those key apps might be Office, a browser plus Flash plugin, and maybe something like iTunes. Well, they've already shown Office running and printing. I bet that IE already works, and Firefox would be a doddle (already running on ARM on a number of linux boxes). Adobe are familiar with Flash on ARM already, so that doesn't look like a difficult port. iTunes might be the interesting one; iTunes would make the product more commercially attractive, but that product would likely be aimed fairly and squarely at Apple's own iPad. So would Apple make the port? But then again if a Windows/ARM was a direct competitor, would iTunes really be necessary?
"OK, so everyone's talking about multicores, right? How about an asymmetrical multicore? An ARM core runs the operating system, office suite, web browser et al, and legacy apps run on an x86 on the side."
Acorn wasted a load of time on this kind of thing with their Risc PC and the PC card concept - not the podule-based thing seen on the Archimedes, but a CPU card which plugged into the same kind of slot as the main ARM CPU and gave a kind of dual processing capability sharing the same system bus.
What they learned is that people wanting the Windows experience will just buy the kit that delivers it for the lowest cost, not horse around with some halfway house solution which doesn't give the best experience in either environment.
What Acorn should have done is just packed a bunch of ARM CPUs in the box and worked on getting their OS to use them all - something they never really got round to doing. The lesson for everyone today from all this is to not be afraid to break with the past and just ship decent new stuff where people aren't asking all the time whether it's Windows or not, just because they've been trained like parrots to do so.
> An ARM core runs the operating system, office suite, web browser et al, and
> legacy apps run on an x86 on the side.
That would limit you to legacy apps that do not need to call into the OS - and that's a vanishingly small market. Pretty much every app needs the OS underneath it - that' s why you can't just take a given binary and run it on a different OS using the same chip.
> If the OS isn't on it, there's no problem, surely?
If it's to do anything meaningful, the OS would need to be on it.
This sort of arrangement *is* possible - I've created several designs along that line, albeit with different CPUs and OSes than you're talking about. But it is quite complex - you've basically got two heterogenous computers that need to talk to each other, and the programming environments aren't even *similar*. This is not for the faint-hearted, and it won't provide the sort of legacy support you're after without some serious compromises.
I am no fan of wintel but ARM will have to be at least %40 faster to cover the overhead of a instruction translation layer (ala Apples Rosetta) which will be necessary to run the vast majority of software users will need to run. Users don't care about OS or chips only software. And software publishers hate having to support multiple code bases so the ARM native software will be very slow coming if at all due to low market share. Classic chicken and egg thing and reason wintel has been around so long when they have seldom been the best solution.
I think this is really interesting times. We have known this battel was coming for a while, and now it looks like it's about to start proper. Netbooks caught MS with thier pants down and Linux started to come at them from the bottom into their market. Linux had always been at the top, I think MS conceeded big iron and servers. I also think MS conceeded the embedded market, but the netbooks with on MS turf, and they poo'ed themselves. They brought back XP, and reduced the specs of their next OS so it could complete in the market (though does it?). The Linux platform doesn't care about processor type, and ARM's rock, so ARM is coming into MS turf now too, now that the netbooks showed that Linux in that turf isn't completely crazy. Why is Linux so important to this? Well without Linux there would no point on ARM entering this turf as their is no software, it's all x86 locked, as it has been, for years. But with Linux/openness, there is no hardware platform locks. ARM vs x86 when power requirements come into play is a no brainer, ARM win hands down everytime. So with ARM coming in, Linux would start coming into too, again, so MS poo'ed themselves again and start talking about real Windows on ARM. But the thing is, that won't matter because you can't run any Windows software on it. So you either have a Windows ARM machine you can't run any Windows software on, or you have a Linux ARM machine you can't run any Windows software on, but you can run the world of free software on it. Really interesting. Worse for MS, is that ARM starts coming in, again with Linux, from the top too where data centers want to save power. Intel will be watching all this in horror. If you stop caring about Windows, and go open, you stop caring about backwards compatbility with x86. This could all snow ball rather nicely for ARM and free software. Great for consumers to break the Wintel catch 22 we have been stuck in.
I don't see Intel being worried about the ARM after all, if you want to download a Windows program in the future you'll need to choose the x86 or ARM executable version if it's offered by a developer at all and that will mean 90% of Windows software will not run on a Windows 8 ARM PC.
No, the important thing about ARM is what it can do in 1GHz and small amounts of RAM that x86 can't. Just look at how amazingly smooth the graphic display is in the iPad and Android. See how fast it runs and how great the UI is.
Not even Windows 7 can offer that without GBs of RAM, a very powerful graphics card and multi-core, multi-GHz CPU.
I remember when the humble Acorn Archimedes was so much faster than the IBM PCs back then. It wasn't all down to hardware, it was better coding practises too that come from using a RISC processor.
"...if you want to download a Windows program in the future you'll need to choose the x86 or ARM executable version if it's offered by a developer at all and that will mean 90% of Windows software will not run on a Windows 8 ARM PC"
Or you get the .Net version that will run on any Windows OS.
Additionally, how long will it be before the jazelle silicon that executes java bytecode natively is replaced with something that executes CIL bytecode natively?
.NET apps are frequently polluted by calls to unmanaged DLLs. They'll use an ActiveX control, or some COM component, or some legacy DLL, or call some esoteric Win32 API, or one of their dependencies will and that's that. I expect most real world .NET apps are unclean and stuck to x86 in some manner.
True, but that's not Microsoft's fault. That's the fault of programmers who either don't have the time, or are too lazy to implement real solutions.
While some apps may have teething troubles today, those apps will soon be fixed if and when Windows on ARM gains market share. It's no different to how a lot of apps needed to be fixed to work correctly with Vista and Windows 7. Once the developers saw that was the way the world was moving, they soon fixed them. How many apps today don't work on Windows 7? Not many, and it'll be the same with Windows supporting multiple architectures. Microsoft have a solution in place, and ultimately, developers will start to see that that is the way to go.
In a way it sucks, because the performance of .net apps still has a long way to go, in my opinion. At some point in the future though, we'll just quietly forget about what could have been possible if we'd stuck with native apps, and accept the performance loss for a world where the developer doesn't care whether the user is running on x86, ARM, PPC, Cell, or whatever.
The main advantage for Windows on ARM is that there will be some sort of homogeneous hardware platform. Since Windows is not delivered as source code, the hardware needs to be adapted to make the OS run.
This is where Linux comes in. Once you have such a platform it's fairly simple to adapt Linux to it, giving you the "install and run" experience you already have on PCs.
And then the fragmentation that plagues linux today can carry on for ever and ever and ever.
Ubuntu have their own ARM strategy. I can't see that lasting for very long if MS create a different ARM hardware ecosystem with its own boot mechanisms, memory layouts, etc. I just hope that MS don't try and make an ARM ecosystem and lock it down to Window only.
This originally posted on Thursday in one of the other ARM threads...
"if MS managed to get a sufficiently consistent ARM hardware platform for Windows 8 to run on, the Linux world would be quite capable of exploiting it for OS and apps (including recompiling existing printer drivers) very very very very quickly - more quickly than MS, probably. Unless of course MS and friends manage to encumber it with some proprietary non-disclosable stuff (probably disguised as DRM/DMCA support) to stop this happening, and they wouldn't do that would they?"
I think it's fairly obvious the reason ARM chips don't come in umpteen-core varieties is simply that the current target market (phones, embedded systems) don't need them. Windows on ARM will make a market for more powerful processors.
But I do ask myself why MS is doing this.
Presumably they're aiming for the tablet market, and netbooks, if they get a second wind.
But part of me worries that they're aiming for the embedded market -- remember the Windows 95 cash machines that were down as much as they were up? That could be your next TV....
fetid hot air at that - i think they [intel] have realised that they've let the bottom end go (with only the Atom as a weak half-attempt). they were focussed on silly-power desktop processors and cranking out higher clock rates and lost the focus on chip design
ARM, on the other hand, remember their old CPU architecture classes.
RISC will beat CISC - Intel are trying to bodge RISC into their cores - whereas ARM started in that position. If you think about what a current decent ARM CPU can do wrt instructions per second
and compare it to the desktops we used to run, its more than matched. their only downside as I see it? their floating point performance. one argument does remain.... the current ARM processors can play HD video but thats only good if you are a consumer. if you are a prosumer or want to take your clips and make videos/mashups etc then ARM isnt there yet
You use a decent graphics coprocessor Or one of the new SoC Arm devices - 2 Arm cores, embedded graphics processor on the same die accessing the same memory space e.g. Nvidias Tegra, although that's not too great on power consumption (and has other issues - there are better offerings on the way)
That way you get dedicated HW with consequent (very) low power for the video and 3D tasks, the Arms can blast along doing everything else without worrying about encode/decode, 3D and 2D graphics, mp3 playback, camera ISP etc. Get rid of all that stuff in a dedicated unit and you would be surprised how little CPU power you need for everything else.
Biting the hand that feeds IT © 1998–2021