Qualcomm Wants a Piece of the PC Market 215
jfruhlinger writes "Much of Intel's story of the past few years has involved its so far fruitless attempts to break into the smartphone and tablet market. But as it keeps trying, it may find competition on its home turf: Qualcomm, which makes many of the ARM-based chips in those smartphones and tablets, wants to make PCs, too. The advent of Windows 8 for ARM and Android will make this possible."
Hmmm... (Score:5, Interesting)
At one time, Apple pitched RISC (ala PowerPC) as the logical successor to CISC (x86). They were also an early investor in ARM (along with Acorn and VLSI). Intel, though, had the development resouces ($$$) to stave that off.
Sounds like it might finally be happening.
(Opinion: Too bad Apple has turned evil in the interim.)
Re: (Score:2)
(Opinion: the POWER architecture rocks! (disclaimer, I've not only worked for Freescale Semiconductor, but also run linux/ppc64 as my primary OS).)
Re: (Score:2)
Apple did transition from the 68K to PPC, obviously. But the reason was that they (along with Moto/IBM) expected to be able to advance RISC faster than Intel could advance x86 CISC. 68K just wasn't keeping up, and PPC was expected to provide a "leapfrog."
Re:Hmmm... (Score:5, Interesting)
but that's all because the x86 chips just havn't been small enough to be efficient and use little power to keep devices going for a long while.
I wonder why Intel doesn't rip out the x86 decoder from it chips and then write compiler back-ends that directly generate micro-ops.
Since the decoder stage is large and power-hungry, the resulting chips would be faster than any ARM variant while also being much smaller are low-power than Atoms.
Re:Hmmm... (Score:5, Insightful)
but that's all because the x86 chips just havn't been small enough to be efficient and use little power to keep devices going for a long while.
I wonder why Intel doesn't rip out the x86 decoder from it chips and then write compiler back-ends that directly generate micro-ops.
Since the decoder stage is large and power-hungry, the resulting chips would be faster than any ARM variant while also being much smaller are low-power than Atoms.
Yeah, thats RISC.
Re: (Score:2)
Depends on the chip. Sandy Bridge, maybe. Atom, probably not.
Re: (Score:2)
I wonder why Intel doesn't rip out the x86 decoder from it chips and then write compiler back-ends that directly generate micro-ops.
Since the decoder stage is large and power-hungry, the resulting chips would be faster than any ARM variant while also being much smaller are low-power than Atoms.
Probably because the internal architecture is far from stable. Of course, they could write a new compiler for every chip generation, resulting in all kinds of fun for both developers and end users.
Re:Hmmm... (Score:4, Insightful)
Since the decoder stage is large and power-hungry
It isn't. Decoding was a major expense when RISC was invented, but transistors are cheap now. Even on a phone.
Re: (Score:3)
Removing the instruction decoder is a bad idea. The microcode is different for every CPU out there and it wouldn't be as fast without an instruction decoder in any case. CISC tends to be memory efficient while RISC tends to be processing efficient. Thanks to the instruction decoder, the x86 currently gets to store it's instructions CISC style while running them RISC style. If you had to write your code using the microcode directly you'd end up with ~100bytes of code for something as simple as the equivalent
Re: (Score:3)
Because the micro-ops change every generation, and the decoder is a tiny, tiny part of the chip anyways. It's not large and power-hungry.
Seriously, you'd need at least six different binaries just for the processors Intel has released in the past five years (Presler, Core, Core 2, Nehalem, Westmere, Sandy Bridge). Maybe two more for the Atoms. And then several more for AMD compatibility - I'm not sure how much they've changed over time, but you'd need at least K8, K10, Fusion and Bulldozer.
So that's a dozen
Re: (Score:3)
I think that is exactly it. If I recall correctly pipelining came out first in the RISC area which helped a lot. It took a few years for the CISC chips to follow suit.
Finding the parallelism needed to keep busy is hard at all levels. Instruction level parallelism down at the op level and task level parallelism at the core level. Small transistor count operations that can be data-paralleled for speed is all fine and dandy but finding enough chunks consistently to keep all of those parallel channels full is h
Re: (Score:2)
More like 20 years ago. The other "RISC" chips started to drop off the map in the late 1990s. For general purpose performance computing, we're now left with x86, SPARC, and POWER.
Re: (Score:2)
Dammit, meant 15 years...
Driverless PC (Score:5, Insightful)
Just what I can't wait to have, a PC that I can't get any drivers for or put anything but the singular blessed Windows 8 installation it came with on.
Re:Driverless PC (Score:5, Insightful)
Re:Driverless PC (Score:5, Funny)
I've long since believed that WINE is going to be the new API people write apps for. Especially for legacy Windows apps.
Re: (Score:2)
I guess you didn't notice the logical disparity between "API people write apps for" and "legacy Windows apps" ?
In case it still isn't clear, a "legacy" app is one that was written years ago, while a "new" app is one that people are writing now. *cough*
Re: (Score:2)
(It was the last year I touched a boob.)
That's why it's better to be a fat nerd instead of a skinny nerd. Sure, the fat nerd might only be touching manboobs, but that's better than not touching any boobs.
Re: (Score:2)
Because x86 PCs will be able to handle Metro apps and x86 apps.
As Slashdot is often fond of pointing out, for 90% of users the capabilities of a PC are superfluous. ARM/x86 for lightweight apps and x86 exclusively for workstations.
Personally I think x86 will simply squash ARM within 18 months and it's only going to be useful to stave off the current Android/iOS onslaught but as Windows 8 moves onto the phone Microsoft needs a portable application framework which can run on their consoles, phones and PCs.
Re: (Score:2)
On the other hand, if use videogames for playing and Open/Libre/BR Office for working, I don't have any serious lockin on a X86 based Windows on the short run.
Since I do not believe that Microsoft would commit the übber-mistake of not porting MS-Office to ARM platform, the real question is: why I would buy x86 for my small/medium business?
Home computing is not the real incoming source of revenue for Microsoft. The real money are in business clients - big corporations, to be more exact.
Re: (Score:2)
Linux should run on it, especially since the Android drivers are supposed to go back into the vanilla kernel.
Re: (Score:3)
Not drivers, the custom modifications to the kernel for Android. Drivers for Android devices rarely ever make it upstream, let alone binary blobs the system depends on. Such blobs are almost always linked against Bionic and as a result useless with Xorg and other non-Android bits.
Re: (Score:2)
That could take a while longer then, to reverse engineer the thing.
Not going to work... (Score:5, Insightful)
Re:Not going to work... (Score:5, Interesting)
If Linux hasn't been able to succeed on the desktop, then I see no reason why ARM would succeed
Depends on the price, I guess.
Replace Linux with Android, get a price under $50 (even if display-less) and you have a desktop good for browsing, social networking and communication (Skype). As for the price: if Raspberry PI can, I think it is possible put a bit more RAM for the price.
Re: (Score:2)
Plus, Android is absolute crap on anything that isn't a smartphone. On smartphones? Its decent. On anything else? Not so much. Even on tablets most Android devices seem rather "forced" and hacked together on the best days.
Re: (Score:2)
Not really. We had this fad back a few years ago, it was called "netbooks" that sold for low prices but almost immediately people started complaining about that they didn't run the applications they needed.
Not enough screen-space, rather. I used one, great for Skype-ing, but couldn't do much of browsing because of the screen-space.
Re: (Score:2)
* as the owner of one of the first Eee700 [wikipedia.org], I can tell that 800x480 is just awful for anything but Skype.
* I can see later models of eeePc featured a 1366x768 resolution. Where they on an AMD cpu?
Re: (Score:2)
I am betting you haven't tinkered with Android 4.0 then...
Re: (Score:2)
Not really, what happened was that MS started leaning hard on ASUS and the other manufacturers to knock it off. Those devices were perfectly fine for what they were and what they cost, but almost immediately they were replaced by XP versions that were half as functional and another hundred dollars more expensive.
Re: (Score:2)
Uh, hate to disillusion you... Android's nothing more than the Android app framework sitting on Linux with an Android themed directory structure. WebOS was nothing more than the same story with WebOS being replacing "Android" in that statement. Tizen's the same thing as WebOS in that respect. If Google had skipped using Bionic and used glibc, many would have got this a bit better. If it helps think in terms of Ubuntu, Debian, Red Hat/Fedora, Mandriva, and Gentoo (and a whole host of others...)- those a
Re: (Score:2)
Emulating x86 on ARM seems to be the worst way to compansate for the lack of apps. And is it even possible? I mean, even discounting the usual losses due to emulation, x86 chips are usually much more powerful. Even if it were possible to get decent speeds, it wouldn't be feasible, since emulation (especially when high-level, which I'm assuming would have to be the case) usually causes annoying compatibility problems. Look at Wine. It's great work, doesn't even have to emulate different hardware and is not a
Re: (Score:2)
Re: (Score:2)
Wine is frequently buggy precisely because it is not an emulator. It is an attempt to create a set of compatibility libraries that shim between Windows APIs and a completely different OS. It's a miracle it works at all, given what a Herculean task that is.
If Microsoft wanted to emulate x86 on ARM, they'd probably do exactly what Apple did when they emulated PowerPC on x86 (which, incidentally, worked remarkably well for most apps): include a complete copy of the actual x86 Windows libraries, run it all in
Re: (Score:2)
If Microsoft wanted to emulate x86 on ARM, they'd probably do exactly what Apple did when they emulated PowerPC on x86 (which, incidentally, worked remarkably well for most apps): include a complete copy of the actual x86 Windows libraries, run it all in a dynamically recompiling emulator, and translate the few dozen system calls where the apps and libraries actually call down into the kernel. And boom. You're done.
The problem is that most architecture transitions are done for reasons of performance. A 500MHz Alpha running x86 programs under FX!32 could run them faster than the then-competing 200MHz Pentium Pro. Apple replaced PowerBooks with aging single core G4 processors with MacBooks with dual core Core-architecture processors at close to 50% higher clock speeds.
Emulating an x86 processor on a 1GHz ARM processor will yield performance similar to that of a 400MHz Pentium II, and the extra load will cause battery li
Re: (Score:2)
Emulating x86 on ARM seems to be the worst way to compansate for the lack of apps. And is it even possible? I mean, even discounting the usual losses due to emulation, x86 chips are usually much more powerful.
For the moment, true. However you don't need to do full x86 hardware emulation to get good results. Longsoon chips are MIPS based, but include hardware-assisted x86 emulation.
If someone like Qualcomm were to produce an advanced multi-core Snapdragon (a la Tegra) with a similar set of instructions, I have no doubt most productivity software would run well enough to be usable.
Hardware-assisted x86 emulation
Loongson 3 adds over 200 new instructions to speed up x86 instruction execution at a cost of 5% of the total die area. The new instructions help QEMU translate x86 instructions by lowering the overhead of executing x86/CISC-style instructions in the MIPS pipeline. With added improvements in QEMU from ICT, Loongson-3 achieves an average of 70% the performance of executing native binaries when running x86 binaries from nine benchmarks.
Re: (Score:2)
Well, what other options are there? Seriously, the lack of native support for 32bit software pretty much killed off Intel's first stab at 64bits at the start, it just took a while for those initial contracts to run down. It was a good idea in some ways as it dealt with the legacy infrastructure that had cropped up, but greatly underestimated the time it would take for the ecosystem to make it reasonable to go 64bit only. Apple had something in place both times that it switched architectures to deal with tha
Re: (Score:3)
You should note that Win8/ARM won't run "desktop" style applications anyhow, so an emulator won't do you any good. The only applications it will run are Metro applications, which are already going to support ARM. ARM + Windows is Metro from day 1, so you need only be concerned with new applications.
Re: (Score:2)
ARM + Windows is Metro from day 1, so you need only be concerned with new applications.
Why would anyone run Windows if it won't run their old Windows apps?
Re: (Score:2)
Because you can get something like the Asus Eee Pad Transformer with a real OS to run real apps, not some crippled consumer bullshit like iOS and Android. Well, that's what I hope for, anyway.
Re: (Score:2)
Because you can get something like the Asus Eee Pad Transformer with a real OS to run real apps,
Exactly. Why would you install Windows when you can run a real OS and you'll have to replace all your old software anyway?
Re: (Score:2)
If you think Windows isn't a real OS, you probably wouldn't recognise one anyway, and you certainly wouldn't be able to get one running properly on an ARM system.
Re:Not going to work... (Score:4, Informative)
http://www.zdnet.com/blog/microsoft/microsoft-desktop-apps-will-run-on-windows-8-on-arm/10756 [zdnet.com]
Re: (Score:2)
Normally Mary-Jo Foley is right on the money, but not in this case. Microsoft has made it very clear that ARM devices will only be able to acquire applications from the Microsoft Store (they're doing the Walled Garden) and that the Microsoft Store will only offer Metro applications for download. The desktop tile is enabled on ARM devices in some builds because of the shared codebase, but you won't find it on the retail version.
Re: (Score:2)
Re: (Score:2)
Really?
http://www.slashgear.com/windows-8-on-arm-wont-run-x86-apps-microsoft-admits-16180415/ [slashgear.com]
http://www.infoworld.com/t/microsoft-windows/will-windows-8-run-x86-apps-arm-tablets-or-not-173498 [infoworld.com]
There's tons more quoting Microsoft officials on this- ZDNet's the only one that says what you're saying. Reality is, in order to accomplish what you're talking about there, you're going to need a bit more oomph as emulation of the X86 on ARM's not exactly what one would call "stellar" and you're going to need that to
Re: (Score:2)
Re: (Score:2)
It doesn't and it won't from what I've saw on MS talks. Win 8 is meant to be a (not yelling just plain text emphasizing :-)) PLATFORM SWITCH + backwards compatiblity not platform switch + BACKWARDS COMPATIBLITY.
ie: your old stuff on an x86 platform will continue to work just fine. Your new stuff will work on both x86 and ARM. But old stuff non-ARM will not work. The idea (wishful thinking) is everyone is supposed to switch to Metro Style apps if at all possible running on the WinRT (Win32 is on the path to
Re: (Score:2)
I think MS finally clued into the power of a cross platform platform (a la iPad/iPhone/OS X)
The UI toolkits are different in Mac OS X and iOS; it's not as if you can just move an app between the platforms with little change.
Re: (Score:2)
Ah your right my bad. How similar are they? Both use Obj-C cocoa. Articles I've found say that UIKit is based on Application Kit which is the UI versions for iOS and OS X respectively. Of course things are more than just a UI but still lots of transferable skills if not complete binary compatibility. This might be a case of MS copying something with a slight improvement. MS is of course famous for promising something only to drop the feature by the time of final release so I guess we'll see how truly pain f
Re: (Score:2)
Nope not without recompiling/fixing whatever problems arise, or in the case of .net porting to .net 4.5.
Re: (Score:2)
Not only that but Intel is a behemoth opposite their closest competitor/rival: AMD. AMD is staying afloat. Unless they make the margins Intel is making on its chips or they can sell millions of PCs / tablet a year, I don't think this will work out well for them. There's also a lot of incentives and product placement for HP, Apple, etc online and in retail stores like Best Buy. Sorry but who is going to buy the Qualcomm ARM Windows 8 system. Intel and AMD are the brand people recognize. Besides the only grow
Re: (Score:2)
It will be a very difficult task to port x86 software to ARM...
Why? Because people who write x86 software in higher-level languages tend to assume they can get away with unaligned references? Or because your definition of "x86 software" means "software written in x86 assembler language"?
Re: (Score:2)
For that matter, the OS could even intercept and handle unaligned references - very slow, but potentially useful for compat purposes.
Re: (Score:2)
For that matter, the OS could even intercept and handle unaligned references - very slow, but potentially useful for compat purposes.
...which I think SunOS did on SPARC (and may still do, but I'm too lazy to go look at the OpenSolaris source to see what SunOS 5.x does).
Or, alternatively, if the compiler can determine that an access is potentially unaligned, it can generate "safe" code. I seem to remember at least some SPARC C compiler or compilers having an option to make them generate unaligned-safe code for all pointer dereferences.
Re: (Score:2)
Or, alternatively, if the compiler can determine that an access is potentially unaligned, it can generate "safe" code.
I think that would be pretty tricky. I mean, no standard conforming C or C++ code can do unaligned access by definition, so if someone does it, they're firmly in the realm of U.B. already, and you can only guess. You'd need whole program data flow analysis to see where the pointers come from, and flag any case of reinterpret_cast or analog that may produce an unaligned result. I think that may end up being too pessimistic, and generate slow code for cases where it's not needed in practice. The runtime solut
Re: (Score:2)
I mean, no standard conforming C or C++ code can do unaligned access by definition, so if someone does it, they're firmly in the realm of U.B. already, and you can only guess.
Unaligned accesses are probably rare, but I don't see why you can't do them in a C or C++ compiler.
char bitmap24bit[ 3 * 1024 * 768];
int pixel = (*(int *)(bitmap24bit + ( ( 1024 * y ) + x ) * 3) ) & 0xffffff;
Enabling packed structures in gcc should also cause lots of unaligned accesses.
I remember years ago when we first ran into a CPU which couldn't handle unaligned accesses we had to fix up a number of crashes in the software we were writing at the time. And that wasn't even developed on x86.
Re: (Score:2)
My point was not that it's impossible to write C/C++ code that will cause unaligned access on some implementation. Rather, that any such code inherently causes undefined behavior according to the letter of the corresponding language standard.
E.g. your example code invokes undefined behavior according to either C or C++ standard. The reason is that it the alignment requirement for char is 1, so bitmap24bit can be aligned by the compiler on any random byte boundary. And the alignment requirement for int is un
Re: (Score:2)
Notice how Office hasn't been announced for ARM yet.
Where were you a year ago when they did exactly that at CES?
Re: (Score:2)
IIRC, those windows tablets last year were x86, not ARM.
Microsoft didn't demo Office for ARM until a few days ago.
Re: (Score:2)
Nevermind, I was completely wrong about the Office for Arm thing.
Re: (Score:2)
unaligned references?
" The ARMv6 architecture introduced the first hardware support for unaligned accesses. ARM11 and Cortex-A/R processors can deal with unaligned accesses in hardware, removing the need for software routines."
Thanks; I guess my information was out of date. I'd have looked it up in the instruction set architecture documentation, but as I'm not a "registered ARM customer", I can't see the instruction set architecture documentation....
Re: (Score:2)
Re: (Score:2)
It will be a very difficult task to port x86 software to ARM...
Been there, done that, not a problem at all (> hundred thousand lines of code). The difference between x86 and ARM is much less than the difference between x86 and PowerPC.
Re: (Score:2)
But not all software is in C or C++...
OK, so recompile it if it's in Pascal or Ada or Fortran or....
The only software that you can't recompile (after checking for stuff that doesn't port) would be software in x86 assembler language; is there a significant amount of Windows application software out there written in assembler?
Re: (Score:3)
The only software that you can't recompile (after checking for stuff that doesn't port) would be...
..software you don't have the source code for.
Like every proprietary Windows app that I own.
Sure, the developer might recompile it, but then they'll expect me to buy another copy for ARM. Why would I want to do that?
Re: (Score:2)
Re: (Score:2)
Only in the sense of trying to get Windows on to it in the desktop context. ARM's not going away any time soon- it's used all over the place, just not in desktops and notebooks right at the moment.
Re: (Score:2)
Ah, but that doesn't change the reality of the GP poster's remarks. As long as it will do faceplant and pr0n, many, if not most users will never notice.
And at least some seem to be doing that with the current crop of Android tablets, citing that it does all of what they need while travelling when a keyboard's added either by dock or by bluetooth. And, I'd have to agree. There's two differing products that do good for what Office does on Android. There's several Facebook-centric apps, and a whole host of
...but not the piece that makes PCs. (Score:4, Informative)
But as it keeps trying, it may find competition on its home turf: Qualcomm, which makes many of the ARM-based chips in those smartphones and tablets, wants to make PCs, too [itworld.com].
The article linked to says
The company is talking with PC makers about building thin and light computers based on its Snapdragon chips, Jacobs said during a keynote address at the Consumer Electronics Show.
which isn't quite the same as "Qualcomm ... wants to make PCs".
The ARMy of fanboys is getting repetitive. (Score:5, Interesting)
Before I being, bear in mind, the whole annoying mantra that x86 will NEVER compete with ARM in low-power applications has just been shot out of the water: http://www.anandtech.com/show/5365/intels-medfield-atom-z2460-arrive-for-smartphones [anandtech.com]
I've been hearing ad-nauseum about how all ARM has to do to destroy x86 in the desktop market is to flip a couple of bits and they'll have "good enough" performance while using zero-point energy that produces free power and unicorns since about 2006. In the meantime, the exact same people who say that ARM is "good enough" rip dual-core Atoms for being too slow (while the single-core Medefield I just linked to is faster than dual--core A9's in the Iphone 4S and Galaxy Nexus, while using less power).
I've also heard about how the A15 will completely blow Intel away when it finally shows up blah blah blah (I heard the exact same story about the A9 cores btw, and Intel is still in business).
What I have yet to see is ARM *really* ratchet up performance... and no, I'm not saying that they need to beat Ivy Bridge... I'm saying they need to *approximate* a mobile 1.8Ghz Core 2 from about 2006 to get that "good enough" performance. I have yet to see that chip, and for all you fanboys out there, the A15 is *not* that chip (it'll likely finally beat a single-core Atom from 2008... but remember the single-core Atom was never good enough to begin with!). Intel has closed the gap for x86... it's a done deal, and no amount of "ARM is magical" will change the laws of physics.
ARM has *NOT* closed the performance gap with x86, and when you add in all the cache, real memory controllers (not those jokes used in current ARM designs) and I/O controllers needed to do real work, your ARM chip will end up using just as much power as a competitive x86, no matter how many forums you go on to brag about the superioirity of the ARM instruction set that doesn't even do 64 bit, and which you never even write assembler for anyway.
Re: (Score:2)
I'm eagerly looking forward to these devices. I have high hopes for this platform. But we need real-world samples of a production device in independent labs please. Until then we can't compare them to the shipping devices of their era, because their era has not yet begun. Intel has promised a lot of things over the years that never came to market.
One of the things that might prevent this from coming to market is pressure on OEMs to avoid Android on x86, if they want to get Window 8 platform development
Re: (Score:2)
Isn't GP's link to AnandTech review precisely this kind of independent testing? Sure, it's a reference device, not a production one, but provided it's the same size and weight, what's the difference?
Re: (Score:2)
It matters. And the review is not to AnandTech's usual rigorous and respectable standards. Like I said, we've seen a lot of these reference designs over the years and been disappointed when they didn't come to market, or were hidden under a rock. If Intel can't get anybody to make the thing then it does not matter how good it is. Intel is not designing this stuff for their own amusement.
I want to believe. Show me.
Re: (Score:2)
We'll see once K800 [techradar.com] comes out - which should be soon enough.
Re: (Score:2)
Re:The ARMy of fanboys is getting repetitive. (Score:5, Interesting)
There are market and structural forces that are driving x86 and ARM into competition. First, because of smart phones, ARM has a huge installed base. No matter what Anandtech says, I don't see a lot of x86 pushback in that area. Ignoring technical considerations, ARM has won that battle, just the same way that x86 won the desktop/laptop battle. (Note the use of past tense.)
Another important component is the number of players in the x86 vs. ARM competition. For x86 there is Intel, AMD and VIA. Any others are truly niche players. Even though ARM manufacturers all are licensed, the range of products and room for innovation is far greater in the ARM world because of the shear number of vendors. To succeed with an ARM product you have to stand out from the crowd, so innovation and price/performance are required to just stay in business. Even if a big player fails that will not change the dynamic.
So x86 "fanboys" should be happy about the ARM, because without the competition Intel would do what all other monopolies do: build products that are overly expensive, poorly performing, have built in obsolesce, and insure lock in, i.e. Microsoft. If it were not for ARM, it is very unlikely that the Intel ATOM would even exist. AMD is having trouble eve breathing, and VIA is small change. Without competition from ARM the x86 will die a slow death.
So smart phone and tablet manufacturers want to expand their market. One way is to expand the low end, and the other way is to invade the high end. It is inevitable that both will happen. Therefor ARM based products will end up competing with x86 products, and they will have success. The only question is when it will happen and how much market share they will take.
Microsoft has figured this out, because Windows 8 will do both. In this case I think they know what they are doing, even if they usually have their head in the sand. As long as ARM Windows 8 supports the core Microsoft apps, for a huge fraction of the customer base it makes no different what CPU they have. And there will be Windows 8 ARM hardware that says "Intel Inside". They can't afford to give up on that part of the market.
It's not about "fanboys". At some level, it is not even about technology. It is about market forces.
Re: (Score:2)
arm's huge installed base is not compatible with each other at all... the os side there is just so fragmented and so are their chips.
yes, windows8 "will do both" but that's just _lying_. but that's like saying that windows phone could be run on medfields because there's no native code for the user programs. saying that windows8 will do both is exactly the same as saying that windows 7 does both because windows phone 7 runs on arm - it's just branding them under the same umbrella - if it doesn't run counter
Re: (Score:2)
In the meantime, the exact same people who say that ARM is "good enough" rip dual-core Atoms for being too slow (while the single-core Medefield I just linked to is faster than dual--core A9's in the Iphone 4S and Galaxy Nexus, while using less power).
I don't know about the new ones, but older dual-core Atoms can't play HD H.264 without dropping frames. The dual-core 200MHz ARMs I worked with a few years ago could do that, because they also had some hardware decoding assist built in.
What does the average user do on a PC these days that an ARM can't do just as well? My i5 laptop is much more powerful than an ARM, but spends most of its time idle... and when I do something complex like playing H.264 video it hands off most of the work to the GPU.
Now, I do
Re:The ARMy of fanboys is getting repetitive. (Score:5, Informative)
First of all, this Intel Medfield thing is, at this point, nothing more than a publicity stunt, specially its power consumption. To put it in perspective, Intel's only official statement with vaguely objective numbers puts Intel Medfield with a power usage of over 2W. This isn't particularly bad when compared to Intel's previous offering.
Yet, once you compare it with today's ARM-based products, it still can't compete. Let me explain.
If you put it in perspective with today's real world ARM-based systems, you will see that they all have a less than 1W power usage. You can check link which you provided to AnandTech's article on Intel Medfield to learn that. So, this might not appear much, but it demonstrates that Intel Medfield is a power hog that drains at idle at best over 2x the power required by ARM systems at peak demand [extremetech.com]. Intel's official figures puts Intel Medfield with a idle power usage at around 2.3 Watts. With ARM-based systems, the idle power is at worse around 40mW. That is, according to Intel's marketing department, Intel Medfield uses 60x the power that ARM-based systems use at idle. Is that what you describe as shooting a claim "out of the water"?
Then you go on boasting Intel Medfield's performance. Yet, what you don't understand is that synthetic benchmarks don't matter in the real world. All that matters is that a computer is able to perform some task with an acceptable level of performance. So, a user may not notice any performance difference between two systems whose WhateverMark is over 200% apart. Why would it matters if a system is able to play three or five concurrent HD video streams if a lower-spec system is quite able to play only one HD video stream? After a certain point, performance is irrelevant, as Intel's Atom line demonstrates.
So, knowing that Intel Medfield's computational power is irrelevant and knowing that Intel Medfield's future best-case propaganda power requirements are huge when compared with today's ARM products, why exactly are you claiming that Intel's tomorrow showcase product even competes with yesterday's ARM systems?
Re: (Score:2)
while the single-core Medefield I just linked to is faster than dual--core A9's in the Iphone 4S and Galaxy Nexus, while using less power
Both of the benchmarks they ran are single-threaded, so you can only say that it's faster than a single core of those processors.
2012 will be the year of the ... (Score:2)
Qualcomm folks must be smoke'n something good to think Windows on ARM is going to be worth a hill of beans. It'll probably be just as good as Windows on the OLPC XO was, at best.
LoB
Re: (Score:2)
I would not doubt the ignorant press pundits are putting all the Windows 8 spin on things but if you've been around the tech sector for a while you also know that corporations are also run by ignorant people. ie you've seen them do things like license Java to Microsoft and think Microsoft is going to abide by it. Or si
They can't even duck thrown chairs yet (Score:5, Informative)
Re: (Score:2)
Windows 8 is only in an early state. Qualcom and Microsoft are both very motivated to expend resources to make this happen. Between the two of them, they can make it happen. It might be late and over budget, but it will happen.
I despise Windows software as much as any Unix/MacOS geek, but I can be objective. This will happen. It might die for other reas
Online apps (Score:2)
With even Microsoft's emphasis on online apps these days, it shouldn't matter what processor a system has. They made their bed, I guess they can lie in it.
As far as emulators, everyone recalls the PC emulators available for the PPC Macs. They did work, but the system they were emulating was slow by standards of the time. You could in principle emulate any processor on any other processor - but would it be worthwhile?
Re: (Score:2)
As far as emulators, everyone recalls the PC emulators available for the PPC Macs. They did work, but the system they were emulating was slow by standards of the time. You could in principle emulate any processor on any other processor - but would it be worthwhile?
Rosetta didn't suck too badly - it ran Quicken 2007 adequately on my MacBook Pro. ("Ran" because I dumped it in favor of Quicken Lite^WEssentials when Q2007 couldn't manage to avoid corrupting one of my credit card accounts.) Unlike the PC emulators, it didn't have to implement the raw hardware - it just had to run usermode code, and it translated system call arguments and results. Dunno how hard it'd be to translate x86 machine code to ARM machine code; if I remember correctly, ARM processors aren't gua
Re: (Score:2)
ARM processors aren't guaranteed to support unaligned accesses, so sufficiently-safe translations of x86 memory-reference instructions might be complicated code sequences.
About three instructions to perform a 32 bit load from an arbitrary address vs. one instruction if you know it is aligned. Store will be a bit more. On an iPhone for example, you can tell the compiler that a 32 bit integer is (potentially) unaligned and it will use three instructions, if you don't tell it but it _is_ in fact unaligned, then you get an exception, and the OS fixes it, taking several hundred cycles.
Great for Linux folks (Score:2)
That may be changing... (Score:2)
Re: (Score:2)
No, probably more along the lines of business tablets that need X86 and some warped version of Windows. Medfield allegedly has an idle power that is 2-2.5 times higher than the peak for a dual-core A9 configuration typically used in phones. If that's really the case, it's going suck seriously with only about a 2-4 max idle lifespan for the devices using them.
FP (Score:3)
Why would a lawnmower manufacturer want to make PCs?
Comment removed (Score:5, Insightful)
Re: (Score:3)
You know what? This makes sense. I wish I had mod points.
Microsoft is right now locking horns with the "innovator's dilemma" and are fighting hard to avoid it. A new computing platform has emerged, the mobile market, and despite having a 10 year lead on it, Microsoft managed to miss the boat so badly that they make more money on patent licensing on their competitor's product (Android) than on sales of their own.
Windows 8 is their attempt to merge their Desktop environment (their strength) with the mobile ma
Re: (Score:2)
MS makes Windows unworkable outside Intel (Score:2)
Re: (Score:2)
Re: (Score:2)
Think about it friends, the way to know a thing is to understand it, now why do people buy Windows machines?
I'd answer: because that is what is installed on a $300 Dell.
The days of bringing home the office suite from work are over for most people, thanks to DRM.
I don't think ARM windows will be much of a hit with corporations, but I don't think people in general will even know the difference - they will just buy whatever is on the app store. Plus, some enterprising company will come out with an emulator. Since most of the UI won't need emulation, it might even have a chance at not sucking performance-wise.
Re: (Score:2)
it's stupid anyways. windows for arm is going to be just wp7(or 8, but the point being it's just the vm shit) for big screens. but the tech media happily ignores this as they can sell "arm is going to kill x86" stories if they do.
so it's zune for desktop. who the fuck is going to buy that? bigger screens androids will sell more units in coming years though sure, but so what, they're for different uses - I really doubt people are going to flock to them to do android _development_ on them. why would you when
Re: (Score:2)
And ARM is great for in order, no speculation, no branch prediction, ultra power sipping designs.
The Cortex A9 core is dual-issue, out-of-order, speculative, and uses 2-level dynamic branch prediction. This doesn't seem to have adversely effected its power consumption in relation to previous designs, and it doesn't appear that the instruction set has made this difficult for them to implement.