That's a bit cynical. Maybe they recommend Windows 7 because it offers an industry beating Low Total Cost of Ownership and compatibility with leading Enterprise applications. Also It Just Works.
Plus Windows is the only OS covered by Microsoft's Patent Promise.
Most people would rather have a cheap NATted internet connection with a clause saying "servers are unsupported" than one that allows servers.
Most ISPs would rather offer two products - a cheap NATted one aimed at the majority of people who don't want to run servers and a more expensive "professional" one with a static IP aimed at the minority which do.
Why should the majority pay extra for a service they will never use?
in your scripts. Make sure you have backups and a good supply of technobabble explanations for the occasional failures. Try to talk your boss into letting you work from home.
Long suspected to hold the key to the tragedy of illiteracy, University of Apollonia researches have closed in on the genetic chromosome likely responsible for widespread reading comprehension disorders.
When presented with stimulating works of literature, including fourteenth century sonnets and the Magna Carta, a control group of mice possessing the illiteracy gene showed no signs of comprehension. Several of the mice relieved themselves on the canonical works. However, when the suspect gene was disabled through highly targeted radiation, the mice quickly died.
Scientists believe that the rodents, suddenly able to absorb some of the greatest works of mankind, were simply overcome, their tiny furry souls stirred past the breaking point. A repeat of the study on much more unpleasant rats yielded statistically identical results, confirming researchers’ suspicions. The University is hoping to follow-up with similar tests on feral children.
The Xboxes, our society giving more rights to criminals, gun control laws that embolden said criminals, lack of police power.
As a heartless libertarian I'd suggest the following - liberalize concealed carry, offer cash bounties for killing criminals and abolish the police. That would probably solve the obesity problem too.
Likewise they can take them for various reasons. Congress hasn't granted unlimited power in that regard, but there are a list of reasons for which they can say "That's ours now," and you get nothing. That was actually threatened in the NTP-RIM case and is probably part of the reason NTP took a settlement that didn't include future fees. NTP was requesting an injunction to shut down Blackberry service. The federal government wrote a brief to the court saying they believed that would have an impact on national security (the US government loves them some Blackberries, they are the biggest customer) and they'd prefer the court didn't grant it. They also noted that if it was, they might simply have to void the patent, which can be done on national security grounds. The judge then strongly suggested the two sides work their shit out now.
This is kind of cool - the Federal Government intervened and saved Blackberry, deus ex machina style. A bit like Eru Iluvatar doing a rm -rf/arda/Numenor/* && umount/arda/maiar/sauron or remount/arda/maiar/gandalf && bleach -white/arda/maiar/gandalf && rmnod/dev/maiar/balrogs/durins_bane
The problem with that is operator subsidy. Apple get $325-$480 in subsidy per device depending on who you believe. Most smartphones get much less. Operators love closed devices - they have a higher average revenue per user. Most people would much rather have a $99 device which is locked than a $500 device which is not.
This would be cool thing for Google to do actually. Launch a getandroid.com website which downloads some root code which installs android on iPhones. Keep updating it as Apple fix bugs.
Ah Apple. You can have a secure browser with outrageous roaming charges or an insecure browser which anyone can run arbitrary root code and no roaming charges.
I had an old Sony Ericsson K600i with a European SIM on a couple of trips to China and it would always warn about encryption being disabled.
There's no need for a the intelligence service of the US or an EU country to do this - they can just tell the telco to do a lawful interception even on an encrypted line because lawful interceptions happen inside the network after the call has been decrypted.
Whether they disable the warning on Chinese SIMs I've no idea. I actually think most of the Chinese system is based on self censorship - so if people get the warning it's a non too subtle reminder that the government is listening.
Great information in your post. I suspect the reason Microsoft doesn't go with an ODM is because it might be significantly more expensive, which would result in a more expensive phone that won't compete as well in the marketplace (see: Dell Streak @ $299).
The iPhone is an ODM product - it's made by Foxconn. An 8GB iPhone 3GS is $99 if you get it from AT&T. Of course it's not really $99, AT&T pay a kickback to Apple to cover the cost of the hardware. I've read "$20 per month" or $325. That's $325 or $480 over the cost of a 24 month contract.
Now it's hard to get an unlocked iPhone, but let's say
That makes me think the value of $480 is about right and they charge you $20 extra for unlocking. Now I could be wrong of course - other figures I've seen have been lower - the contract breaking fee is max $325, which would put the hardware cost at $424. But I've never seen an unlocked iPhone sell for as low as this.
I.e. and 8GB iPhone 3GS costs $424 to $599 without a subsidy and $99 with. A Dell streak costs $549 with no subsidy and $299 with. Dell have cheaper hardware but they failed to negotiate a good subsidy. They get $250 and Apple get $325 to $480!
Incidentally the BOM cost for an iPhone 3GS is $179.
So Apple are making a fortune regardless of the subsidy.
Now my argument is that one of the things that AT&T and the like tend to like is locked down devices. For example on my Windows Mobile device which is unlocked I get tethering for free.
On an iPhone I'd need to pay $20 per month. Given the sort of people who buy smartphones, I think they can argue that that added average revenue per month justifies more subsidy.
So my argument is that the Apple model is an ODM'd product which is locked down where things like tethering cost extra.
Actually if I got a subsidized Windows Mobile device, they'd probably disable tethering unless I paid them too.
I.e. unlocked devices have features that sell to customers. Locked devices have those features disabled to sell to operators if they want to get a high subsidy.
It's not quite the same thing. HTC is not an ODM, it's an OEM. It has its own software and brand name. When I talked to someone on the Microsoft stand at Computex he told me that HTC was irritated about Windows Phone 7. Since WinPhone can't run native applications HTC would have to rewrite their software (e.g. TouchFlo) in.Net to run on it. What they really wanted was a new version of Windows Mobile with the latest Windows CE kernel. Windows mobile 6.x uses Windows CE 5.x which has a 32MB per process limit because it uses FCSE on ARM. Windows CE 6.x has a 2GB per process address space.
So HTC want later versions of Windows Mobile. If Microsoft want to build Windows 7 Phone devices they'd be better off getting someone like Foxconn, Quanta or Compal to do it. They are ODMs and basically do whatever the customer wants. The end product would then be branded Microsoft (or Kin, Yo!, Hipstaah or something). Foxconn for example make the iPhone.
Now my argument is that they could do both. They'd sell Windows Mobile 7 based on WinCE6 with native app support to HTC who'd sell devices to me. And they'd get an ODM to make the Windows Phone 7 devices which they'd then sell effectively to operators the way Apple does with the iPhone. These devices would be slick and locked down and would have a low upfront cost like the iPhone does, though you need to sign up for an expensive monthly contract some of which would go back to Microsoft. This is how iPhones work.
I think the two markets are actually complementary. People that want an iPhone don't want Windows Mobile. And people that want Windows Mobile don't want an iPhone. And they certainly don't want a Microsoft knock off of an iPhone whch won't run their old apps.
A lot of people, including me, have applications that run on Windows Mobile. WinMo isn't going the iPhone but there's definitely an argument for keeping Windows Mobile alive for us. In fact Windows CE is pretty widely used for things like GPS devices. They should keep those customers and in parallel decide on whether launching an iPhone like product is worthwhile.
I think there's an argument that they should have an "Apple like" product which they do in house and a "Windows Mobile" like OS they license to third parties.
Right now they're trying to replace Windows Mobile 6.5 - which runs Pleco very well with Windows Phone 7 which probably won't ever.
It would make more sense to have Windows Phone 7 as their internal Apple like (i.e. locked down but slick) product and keep Windows Mobile going for people that have software for it they want to keep using.
If they really do replace the WinMo6.5 with WinPhone 7 there's a serious chance that it will be rejected by the sort of people who buy iPhones (why not stick just buy an iPhone?) and the sort of people who'd have bought a Windows Mobile Device. Why buy a phone which won't run your old software. In fact if you look at the Pleco site the software will work on an iPhone. The developers are fairly irritated by the whole thing
I'm done paying for mobile platform/carrier specific apps. If my need is critical enough to spend real money on (like the $100 for Pleco) I'll buy the best app I can find for Windows 7 desktop and just run it on one of the W7 tablet/hand-held devices coming out in the future giving me long-term investment protection. What I won't do again is invest in an application where there's a likelihood support for my platform will be dropped because of the ever-changing state of the mobile phone market, especially when it forces me to choose both a new hardware vendor and potentially lock into an undesirable wireless carrier. At least on Windows I know my app will work essentially forever.
I certainly understand your frustration - it's 10x worse on this end, I'd much much rather have spent the last year-and-a-half working on adding features on WM than rewriting the same darn program again for a different platform (or possibly two). Investing $100 in an application that might drop support for your platform is bad, investing several orders of magnitude more money than that in developing an application for a platform whose manufacturer drops support for it is even worse. (as happened on both Palm and WM about a year apart, though at least Palm had the decency to make some attempt at backwards-compatibility - Microsoft just plain screwed us, which is why I found myself feeling a bit of schadenfreude when the Kin turned into the latest iteration of Microsoft Bob)
We try to make it a bit easier on our customers by allowing free platform transfers whenever we can (though it does complicate matters somewhat on the business end) but we're very much hoping that the market will finally stabilize soon so that we can stop having to chase the latest mobile platforms and just focus all of our energies on making our software better.
I.e. they wrote an app for PalmOS, which was dropped. Then they wrote an app for Windows Mobile which is in the process of being dropped for Windows Phone 7 which will not support native Windows CE applications, only.Net ones.
I really have no idea what Microsoft are thinking by disabling support for Windows Mobile apps in Windows Phone. It's like if they'd launched Vista with no support for Win32 applications when most of those applications already run on Macs and Macs had a much larger market share.
I think Atom has more performance and needs more power. The efficiency of an ARM is better but I'm yet to convinced it is scalable to the same performance x86 is.
ARM does a bit better on CoreMark (5.7 vs 3.6 for a single threaded app, for dual threaded an N280 does 5.6. Most CPU intensive stuff is probably dual thread friendly these days, even the horrid flash)
Still CoreMark is small enough to fit in the L1 cache. The Achilles heel of ARM systems has been slow memory controllers. Admittedly that's because ARM is aimed at phones where power consumption is a much more serious issue than netbooks, but still.
On something like SpecInt which is large enough to exercise the DRAM interface I'd expect Atom to blow away an ARM from a similar generation. And Intel already have things like Core2 which can be migrated down to low power as you can see with ULV. I'm not convinced Arm can migrate up.
Emulation would likely make things worse - CPU core performance will drop and if a JIT is used it will stress the memory subsystem more because you need to access both the native code and the translated code. An Jazelle like solution implies a greater memory subsystem hit too - you need to keep the code that emulates the instructions you don't handle in hardware in the cache. That's cache memory an Atom could use on the code its actually executing.
In fact Anandtech reckons that Apple should switch from ARM to Moorestown
Would not make sense from a performance point of view, jacelle is possible but it has been dropped in later designs because it was slower than JIT solutions
If you read why that is it's not clear that it would apply to x86
He mentions that a JIT has an advantage over Jazelle (equivalent to his JPU case)
To be fair to the JPU, to get around the stack architecture problem, a JPU would probably implement a stack caching scheme where some registers will mirror some top N values on the Java operand stack. It will also have some registers mirror some locals. This effectively allows the JPU to avoid memory accesses just like the ideal JIT case, thereby allowing it to theoretically attain speeds approaching the ideal JIT case. However, register pressure also limits the JPU just as it limits the JIT.
In addition, the JPU can only mirror the top most operands on the stack, and maybe the first few locals. Which stack operand and/or locals get mirrored in registers usually isn't configurable at runtime. The JIT however can deal with this dynamically, and can arbitrarily choose which arguments and/or locals to keep in registers. Hence, the JIT has a higher probability of reducing memory accesses than the JPU.
Complex Bytecodes
But wait, that isn't the whole story. I said earlier that the above simple example was chosen because it shows off the JPU's best performance. Note that even when the JPU is best at its game, the JIT will still tend to beat its performance. Now consider the complex bytecodes in the VM instruction set (click here for a glossary of the VM bytecodes).
The VM instruction set also consists of bytecodes like new (for allocating objects), newarray (for allocating arrays), monitorenter (for locking an object), monitorexit (for unlocking an object), and field accessors like getfield, getstatic, putfield, putstatic, and many other complex bytecodes.
I call these bytecodes "complex" because their execution cannot be done in hardware. For example, new needs to work correctly in harmony with the VM's garbage collector; monitorenter needs to work in harmony with the VM's synchronization and threading mechanisms, etc. In the case of the field accessors, there bytecodes have to interface with the class' constant pool table which can be implemented differently depending on the software VM implementation. The constant pool entries will also need to be resolved (amongst other things) before the fields can be accessed.
Now it seems like an ARM has enough registers to mirror the x86 ones, so no extra loads. And x86 code doesn't have things like new which can't be implemented in hardware because it's an assembly language that is designed to run on hardware, not a byte code that is designed to run in a VM.
Most modern x86s actually map x86 instructions into Risc like uops before executing them, so it does seem like this technique is viable. Of course you need a lot of logic to do this. It's not clear what would happen performance-wise if you built an x86 instruction decoder as a front end for an ARM pipeline. There are probably legal issues too - there are still patents on x86. On the other hand, the patents on the core architecture will run out sooner or later.
Actually I don't think Microsoft will do this - A JIT or JPU for executing x86 code on ARM doesn't really appeal at all unless you have ARM cores that are faster than the fastest x86 to run it on. Right now the fastest shipping ARM cores probably have less performance than the slowest x86 - the Intel Atom. The fundamental problem is that ARM has aimed at the mobile market where power consumption is important. x86 has aimed at servers and desktops where power consumption is much less important than computational ability. Of course ARM has improved in performance and x86 has got thriftier but I be
Slashdot Mirror
Hey, I work in commercial biotech research! Are you calling me aggressive?
You wanna come over and say that, buddy?
That's a bit cynical. Maybe they recommend Windows 7 because it offers an industry beating Low Total Cost of Ownership and compatibility with leading Enterprise applications. Also It Just Works.
Plus Windows is the only OS covered by Microsoft's Patent Promise.
Most people would rather have a cheap NATted internet connection with a clause saying "servers are unsupported" than one that allows servers.
Most ISPs would rather offer two products - a cheap NATted one aimed at the majority of people who don't want to run servers and a more expensive "professional" one with a static IP aimed at the minority which do.
Why should the majority pay extra for a service they will never use?
Just put an obfuscated
in your scripts. Make sure you have backups and a good supply of technobabble explanations for the occasional failures. Try to talk your boss into letting you work from home.
There was a very interesting study on the gene for illiteracy in mice
http://www.apolloniathisweek.com/archive/issue_4_local2.html
Long suspected to hold the key to the tragedy of illiteracy, University of Apollonia researches have closed in on the genetic chromosome likely responsible for widespread reading comprehension disorders.
When presented with stimulating works of literature, including fourteenth century sonnets and the Magna Carta, a control group of mice possessing the illiteracy gene showed no signs of comprehension. Several of the mice relieved themselves on the canonical works. However, when the suspect gene was disabled through highly targeted radiation, the mice quickly died.
Scientists believe that the rodents, suddenly able to absorb some of the greatest works of mankind, were simply overcome, their tiny furry souls stirred past the breaking point. A repeat of the study on much more unpleasant rats yielded statistically identical results, confirming researchers’ suspicions. The University is hoping to follow-up with similar tests on feral children.
If people are running around killing each other for money in a Somalia like utopia they won't worry about their other problems.
The Xboxes, our society giving more rights to criminals, gun control laws that embolden said criminals, lack of police power.
As a heartless libertarian I'd suggest the following - liberalize concealed carry, offer cash bounties for killing criminals and abolish the police. That would probably solve the obesity problem too.
A 463MB update? WTF?
Likewise they can take them for various reasons. Congress hasn't granted unlimited power in that regard, but there are a list of reasons for which they can say "That's ours now," and you get nothing. That was actually threatened in the NTP-RIM case and is probably part of the reason NTP took a settlement that didn't include future fees. NTP was requesting an injunction to shut down Blackberry service. The federal government wrote a brief to the court saying they believed that would have an impact on national security (the US government loves them some Blackberries, they are the biggest customer) and they'd prefer the court didn't grant it. They also noted that if it was, they might simply have to void the patent, which can be done on national security grounds. The judge then strongly suggested the two sides work their shit out now.
This is kind of cool - the Federal Government intervened and saved Blackberry, deus ex machina style. A bit like Eru Iluvatar doing a rm -rf /arda/Numenor/* && umount /arda/maiar/sauron or remount /arda/maiar/gandalf && bleach -white /arda/maiar/gandalf && rmnod /dev/maiar/balrogs/durins_bane
Entertainment and Devices divison
Aka "toys and gadgets". Doesn't seem so crazy to me.
It was dumb of them to make the game start playing by default with sound enabled. I wonder how many calls they got in total.
Peace talks are rumoured in the Middle East, new developers for Duke Nukem Forever, a ruined global economy.
Stock up on tinned food and ammunition and pack warm clothes for hell people. The seventh seal is opening!
The problem with that is operator subsidy. Apple get $325-$480 in subsidy per device depending on who you believe. Most smartphones get much less. Operators love closed devices - they have a higher average revenue per user. Most people would much rather have a $99 device which is locked than a $500 device which is not.
This would be cool thing for Google to do actually. Launch a getandroid.com website which downloads some root code which installs android on iPhones. Keep updating it as Apple fix bugs.
Ah Apple. You can have a secure browser with outrageous roaming charges or an insecure browser which anyone can run arbitrary root code and no roaming charges.
It's probably part of the GSM and 3G specifications to allow for unencrypted networks.
I had an old Sony Ericsson K600i with a European SIM on a couple of trips to China and it would always warn about encryption being disabled.
There's no need for a the intelligence service of the US or an EU country to do this - they can just tell the telco to do a lawful interception even on an encrypted line because lawful interceptions happen inside the network after the call has been decrypted.
Whether they disable the warning on Chinese SIMs I've no idea. I actually think most of the Chinese system is based on self censorship - so if people get the warning it's a non too subtle reminder that the government is listening.
Great information in your post. I suspect the reason Microsoft doesn't go with an ODM is because it might be significantly more expensive, which would result in a more expensive phone that won't compete as well in the marketplace (see: Dell Streak @ $299).
The iPhone is an ODM product - it's made by Foxconn. An 8GB iPhone 3GS is $99 if you get it from AT&T. Of course it's not really $99, AT&T pay a kickback to Apple to cover the cost of the hardware. I've read "$20 per month" or $325. That's $325 or $480 over the cost of a 24 month contract.
Now it's hard to get an unlocked iPhone, but let's say
http://www.engadget.com/2009/03/18/atandt-to-offer-unsubsidized-iphone-3g-with-no-commitment-required/
$599 for 8GB
That makes me think the value of $480 is about right and they charge you $20 extra for unlocking. Now I could be wrong of course - other figures I've seen have been lower - the contract breaking fee is max $325, which would put the hardware cost at $424. But I've never seen an unlocked iPhone sell for as low as this.
Here's the Dell Streak
http://www.engadget.com/2010/07/27/dell-streak-retailing-for-299-with-contract-549-without-dell/
I.e. and 8GB iPhone 3GS costs $424 to $599 without a subsidy and $99 with. A Dell streak costs $549 with no subsidy and $299 with. Dell have cheaper hardware but they failed to negotiate a good subsidy. They get $250 and Apple get $325 to $480!
Incidentally the BOM cost for an iPhone 3GS is $179.
http://www.isuppli.com/teardowns-manufacturing-and-pricing/news/pages/iphone-3g-s-carries-178-96-bom-and-manufacturing-cost-isuppli-teardown-reveals.aspx
So Apple are making a fortune regardless of the subsidy.
Now my argument is that one of the things that AT&T and the like tend to like is locked down devices. For example on my Windows Mobile device which is unlocked I get tethering for free.
On an iPhone I'd need to pay $20 per month. Given the sort of people who buy smartphones, I think they can argue that that added average revenue per month justifies more subsidy.
http://gizmodo.com/5553135/att-iphone-tethering-an-extra-20month
So my argument is that the Apple model is an ODM'd product which is locked down where things like tethering cost extra.
Actually if I got a subsidized Windows Mobile device, they'd probably disable tethering unless I paid them too.
I.e. unlocked devices have features that sell to customers. Locked devices have those features disabled to sell to operators if they want to get a high subsidy.
Yeah, see my other posts.
It's not quite the same thing. HTC is not an ODM, it's an OEM. It has its own software and brand name. When I talked to someone on the Microsoft stand at Computex he told me that HTC was irritated about Windows Phone 7. Since WinPhone can't run native applications HTC would have to rewrite their software (e.g. TouchFlo) in .Net to run on it. What they really wanted was a new version of Windows Mobile with the latest Windows CE kernel. Windows mobile 6.x uses Windows CE 5.x which has a 32MB per process limit because it uses FCSE on ARM. Windows CE 6.x has a 2GB per process address space.
So HTC want later versions of Windows Mobile. If Microsoft want to build Windows 7 Phone devices they'd be better off getting someone like Foxconn, Quanta or Compal to do it. They are ODMs and basically do whatever the customer wants. The end product would then be branded Microsoft (or Kin, Yo!, Hipstaah or something). Foxconn for example make the iPhone.
Now my argument is that they could do both. They'd sell Windows Mobile 7 based on WinCE6 with native app support to HTC who'd sell devices to me. And they'd get an ODM to make the Windows Phone 7 devices which they'd then sell effectively to operators the way Apple does with the iPhone. These devices would be slick and locked down and would have a low upfront cost like the iPhone does, though you need to sign up for an expensive monthly contract some of which would go back to Microsoft. This is how iPhones work.
I think the two markets are actually complementary. People that want an iPhone don't want Windows Mobile. And people that want Windows Mobile don't want an iPhone. And they certainly don't want a Microsoft knock off of an iPhone whch won't run their old apps.
A lot of people, including me, have applications that run on Windows Mobile. WinMo isn't going the iPhone but there's definitely an argument for keeping Windows Mobile alive for us. In fact Windows CE is pretty widely used for things like GPS devices. They should keep those customers and in parallel decide on whether launching an iPhone like product is worthwhile.
I think there's an argument that they should have an "Apple like" product which they do in house and a "Windows Mobile" like OS they license to third parties.
Right now they're trying to replace Windows Mobile 6.5 - which runs Pleco very well with Windows Phone 7 which probably won't ever.
It would make more sense to have Windows Phone 7 as their internal Apple like (i.e. locked down but slick) product and keep Windows Mobile going for people that have software for it they want to keep using.
If they really do replace the WinMo6.5 with WinPhone 7 there's a serious chance that it will be rejected by the sort of people who buy iPhones (why not stick just buy an iPhone?) and the sort of people who'd have bought a Windows Mobile Device. Why buy a phone which won't run your old software. In fact if you look at the Pleco site the software will work on an iPhone. The developers are fairly irritated by the whole thing
http://www.plecoforums.com/viewtopic.php?p=18657#p18657
I'm done paying for mobile platform/carrier specific apps. If my need is critical enough to spend real money on (like the $100 for Pleco) I'll buy the best app I can find for Windows 7 desktop and just run it on one of the W7 tablet/hand-held devices coming out in the future giving me long-term investment protection. What I won't do again is invest in an application where there's a likelihood support for my platform will be dropped because of the ever-changing state of the mobile phone market, especially when it forces me to choose both a new hardware vendor and potentially lock into an undesirable wireless carrier. At least on Windows I know my app will work essentially forever.
I certainly understand your frustration - it's 10x worse on this end, I'd much much rather have spent the last year-and-a-half working on adding features on WM than rewriting the same darn program again for a different platform (or possibly two). Investing $100 in an application that might drop support for your platform is bad, investing several orders of magnitude more money than that in developing an application for a platform whose manufacturer drops support for it is even worse. (as happened on both Palm and WM about a year apart, though at least Palm had the decency to make some attempt at backwards-compatibility - Microsoft just plain screwed us, which is why I found myself feeling a bit of schadenfreude when the Kin turned into the latest iteration of Microsoft Bob)
We try to make it a bit easier on our customers by allowing free platform transfers whenever we can (though it does complicate matters somewhat on the business end) but we're very much hoping that the market will finally stabilize soon so that we can stop having to chase the latest mobile platforms and just focus all of our energies on making our software better.
I.e. they wrote an app for PalmOS, which was dropped. Then they wrote an app for Windows Mobile which is in the process of being dropped for Windows Phone 7 which will not support native Windows CE applications, only .Net ones.
I really have no idea what Microsoft are thinking by disabling support for Windows Mobile apps in Windows Phone. It's like if they'd launched Vista with no support for Win32 applications when most of those applications already run on Macs and Macs had a much larger market share.
I think Atom has more performance and needs more power. The efficiency of an ARM is better but I'm yet to convinced it is scalable to the same performance x86 is.
Actually not really true the current cortex A9 is about 2-3 times as fast as the Atom, you can google the performance numbers.
I'm highly sceptical of this
http://www.anandtech.com/show/3696/intel-unveils-moorestown-and-the-atom-z600-series-the-fastest-smartphone-processor/14
ARM does a bit better on CoreMark (5.7 vs 3.6 for a single threaded app, for dual threaded an N280 does 5.6. Most CPU intensive stuff is probably dual thread friendly these days, even the horrid flash)
http://blog.linleygroup.com/2010/04/arm-outmuscles-atom-on-benchmark.html
Still CoreMark is small enough to fit in the L1 cache. The Achilles heel of ARM systems has been slow memory controllers. Admittedly that's because ARM is aimed at phones where power consumption is a much more serious issue than netbooks, but still.
On something like SpecInt which is large enough to exercise the DRAM interface I'd expect Atom to blow away an ARM from a similar generation. And Intel already have things like Core2 which can be migrated down to low power as you can see with ULV. I'm not convinced Arm can migrate up.
Emulation would likely make things worse - CPU core performance will drop and if a JIT is used it will stress the memory subsystem more because you need to access both the native code and the translated code. An Jazelle like solution implies a greater memory subsystem hit too - you need to keep the code that emulates the instructions you don't handle in hardware in the cache. That's cache memory an Atom could use on the code its actually executing.
In fact Anandtech reckons that Apple should switch from ARM to Moorestown
http://www.anandtech.com/show/3640/apples-ipad-the-anandtech-review/17
Would not make sense from a performance point of view, jacelle is possible but it has been dropped in later designs because it was slower than JIT solutions
If you read why that is it's not clear that it would apply to x86
http://weblogs.java.net/blog/2007/02/13/when-software-faster-hardware
He mentions that a JIT has an advantage over Jazelle (equivalent to his JPU case)
To be fair to the JPU, to get around the stack architecture problem, a JPU would probably implement a stack caching scheme where some registers will mirror some top N values on the Java operand stack. It will also have some registers mirror some locals. This effectively allows the JPU to avoid memory accesses just like the ideal JIT case, thereby allowing it to theoretically attain speeds approaching the ideal JIT case. However, register pressure also limits the JPU just as it limits the JIT.
In addition, the JPU can only mirror the top most operands on the stack, and maybe the first few locals. Which stack operand and/or locals get mirrored in registers usually isn't configurable at runtime. The JIT however can deal with this dynamically, and can arbitrarily choose which arguments and/or locals to keep in registers. Hence, the JIT has a higher probability of reducing memory accesses than the JPU.
Complex Bytecodes
But wait, that isn't the whole story. I said earlier that the above simple example was chosen because it shows off the JPU's best performance. Note that even when the JPU is best at its game, the JIT will still tend to beat its performance. Now consider the complex bytecodes in the VM instruction set (click here for a glossary of the VM bytecodes).
The VM instruction set also consists of bytecodes like new (for allocating objects), newarray (for allocating arrays), monitorenter (for locking an object), monitorexit (for unlocking an object), and field accessors like getfield, getstatic, putfield, putstatic, and many other complex bytecodes.
I call these bytecodes "complex" because their execution cannot be done in hardware. For example, new needs to work correctly in harmony with the VM's garbage collector; monitorenter needs to work in harmony with the VM's synchronization and threading mechanisms, etc. In the case of the field accessors, there bytecodes have to interface with the class' constant pool table which can be implemented differently depending on the software VM implementation. The constant pool entries will also need to be resolved (amongst other things) before the fields can be accessed.
Now it seems like an ARM has enough registers to mirror the x86 ones, so no extra loads. And x86 code doesn't have things like new which can't be implemented in hardware because it's an assembly language that is designed to run on hardware, not a byte code that is designed to run in a VM.
Most modern x86s actually map x86 instructions into Risc like uops before executing them, so it does seem like this technique is viable. Of course you need a lot of logic to do this. It's not clear what would happen performance-wise if you built an x86 instruction decoder as a front end for an ARM pipeline. There are probably legal issues too - there are still patents on x86. On the other hand, the patents on the core architecture will run out sooner or later.
Actually I don't think Microsoft will do this - A JIT or JPU for executing x86 code on ARM doesn't really appeal at all unless you have ARM cores that are faster than the fastest x86 to run it on. Right now the fastest shipping ARM cores probably have less performance than the slowest x86 - the Intel Atom. The fundamental problem is that ARM has aimed at the mobile market where power consumption is important. x86 has aimed at servers and desktops where power consumption is much less important than computational ability. Of course ARM has improved in performance and x86 has got thriftier but I be