2

I don't mean to start a war between iPhone vs Windows Phone 7, nor am I against Windows Phone 7. But I've noticed on both of my computers Windows Phone 7 emulator (Beta and CTP) lags like it's running on a crappy last-decade Celeron computer.

I have 2 computers: Macbook Pro 13" (2010 Model) with 2.4GHZ Core 2 Duo, 4GB RAM and ASUS G1 with 2.0 GHz Intel Core 2 Duo, 3GB RAM with fresh install of Windows 7.

Now iPhone emulator on Mac OS X is on the other hand so much smoother, and loads faster and just has better feel to it.

So why is Windows Phone 7 emulator so slow? Is that what we should expect from the devices that will be coming out this october? I hate more than anything on the phone is laggy UX; it just gets under my skin.

It would be nice if someone with the prototype device could comment on this issue.

Jon Limjap
  • 94,284
  • 15
  • 101
  • 152
Sahat Yalkabov
  • 32,654
  • 43
  • 110
  • 175
  • 3
    The iPhone simulator is not an emulator believe it or not. –  Jul 16 '10 at 02:41
  • And what is the difference between Simulator and Emulator? And if Simulator is so much better then why is there no WP7 Simulator? – Sahat Yalkabov Jul 16 '10 at 02:44
  • 1
    How is any of this programming related, anyway? – dmkc Jul 16 '10 at 02:45
  • @mitjak Because I am currently working on a WP7 app! – Sahat Yalkabov Jul 16 '10 at 02:47
  • 1
    @Rihanna.Rain: Basically the efficiency is different because emulators are emulating non-native stuff to be run on that computer but, simulators are pieces of software that are normally non-native re-written for that computer. Ones emulated (emulator), ones not (simulator). The problem with emulators is that they are less efficient. But, simulators give less accurate results (but if done very well it shouldn't matter much). –  Jul 16 '10 at 02:58
  • Hi Sahat, before I comment on this question, I'd like to understand which performance you are talking about. Are you describing 1. time to load the emulator, 2. time to deploy the app to a running emulator or 3. the execution speed of apps running within the emulator? Could you also roughly quantify the observed behaviour differences. As you're probably aware, in the absence of specifics, this particular topic is likely to encite more of a religous debate than comments that would qualify as an answer to a question. – Mick N Jul 16 '10 at 03:50
  • "Beta and CTP" - guess what... – Pavel Minaev Jul 16 '10 at 03:53
  • I can't believe you put that junk on your MacBook Pro. Your Mac is trying to tell you something. – kirk.burleson Jul 17 '10 at 02:17
  • @Rihanna.Rain - check out this SO question for some thoughts on the differences between emulators and simulators: http://stackoverflow.com/questions/2174638/whats-the-difference-between-emulation-and-simulation/2174909#2174909 – Coxy Jul 22 '10 at 07:47
  • you should have seen how slow it was on my 2006 core duo macbook pro! :) I'm just remoting into a better machine to do my dev now, and its super fast. – John Gardner Jul 31 '10 at 00:15

7 Answers7

12

That is because the so called "iPhone Emulator" is a simulator (hence the real name is "iPhone Simulator"). Simulators are non-native programs re-written for that computer. Emulators are non-native programs not re-written they are emulated which takes extra effort to translate everything to display the right things etc. This is why the Windows Phone 7 Emulator is slower than the iPhone Simulator.

But, since simulators do not quite as accurately represent the device as an emulator you can get better error results since the stuff is rewritten in simulators but everything is preserved in an emulator. But, even saying that, you usually don't need to worry about that.

  • So Apple did the simulator properly to give a combination of accuracy and performance, but Microsoft couldn't guarantee the accuracy if they wrote a simulator, and thus decided to sacrifice performance? Sounds about right ;) – Michael Shimmins Jul 16 '10 at 03:14
  • Yeah. The already have enough "features" (if ya know what I mean). They don't need any more. –  Jul 16 '10 at 03:15
  • 13
    @Michael I'm a fan of the iPhone Simulator, but it certainly doesn't give a "combination of accuracy and performance." It gives a decent *tradeoff* of accuracy and performance. We've been long plagued with code that would run fine in the simulator but wouldn't even *compile* for the device. (iOS4 hopefully will clean up the last of that.) The iPhone simulator also does nothing to attempt to emulate the limited memory and performance of the device. It's not just that the device is slower; it only has one core. The simulator uses all the cores. It's nice, but it's not a total win. – Rob Napier Jul 16 '10 at 03:54
  • How can we assert that this is the answer when we don't know what the nature of the performance observations are? Refer to my comment on the OP. – Mick N Jul 16 '10 at 06:05
  • @Rob - good reply. I was being tongue-in-cheek, and taking a cheap shot at Microsoft, but you've turned that around to make some good points. I wasn't aware of the things you mentioned, and haven't done too much with the simulator, but I would be annoyed by the resource issue, and especially if things plain old didn't compile for the device when they ran on the simulator. So I take it back, and a +1 to your reply :) – Michael Shimmins Jul 16 '10 at 06:30
7

Boy, there's a lot of "emulators are this, simulators are that" in some of those answers and I feel more confused after reading them, especially when we get into suggestions that things are "re-written for that computer"

What you need to understand is that the iPhone Simulator is an OPERATING-SYSTEM simulator, not a DEVICE simulator.

When you build for the simulator, you are compiling for an Intel x86 CPU. You link against special libraries that are for an x86 CPU but which implement the functions that are part of the iPhone operating system (call that UIKit)

When you build for the device, you are compiling for an ARM CPU. You link against special libraries that are for an ARM CPU, again which implement the UIKit.

This means that your code runs at full "machine" speed in both environments. There is no notion of "emulating a CPU" which is presumably what the Windows Phone 7 Emulator is doing, something similiar to the MacOS Virtual PC product of years ago (that Microsoft bought from Connectix, as I recall)

The problems that Rob Napier mentions are probably related to using native headers and libraries in his build (call those AppKit). There are some APIs that Apple have let bleed into the wrong SDKs, I recall there were issues with NSTask being available in the SDK even though it wasn't on the iPhone itself, for example. I'm sure there are other problems in this space, its not ideal (though its pretty cool)

Anyway, unless Microsoft have a compiler-toolset that can target both the Phone CPU and the regular Windows PC CPU, they are stuck with emulation at the CPU level, rather than at the Operating System Level.

The only advantage that this cpu-emulation approach has, to my mind, is that you can take the exact same binary and move it between device and PC and run it on both. Apples simulator approach requires you to rebuild the binaries for each platform. Personally, even on my "bottom of the line MacMini", my build times are so small that its just not an issue to rebuild whenever I switch platform.

Jeff
  • 334
  • 1
  • 1
4

The Windows Phone Emulator is actually the Windows Phone 7 operating system compiled for x86 running in a virtualized environment. It uses a derivative technology from Microsoft's VirtualPC/VirtualServer/Hyper-V. Thus it is really neither emulation (there is no ARM to x86 emulation going on) nor pure simulation.

The typical Windows Phone 7 device will be running an ARM processor at close to 1GHz. Emulating (as in CPU emulation) of an ARM processor requires a very powerful x86 processor. The strategy of using visualization allows the OS to execute at native x86 speed. Applications written in managed (.NET) code are executed by the x86 based .NET runtime on the OS.

So code performance on a typical PC (~1.5 - 3GHz) should typically exceed what is found on an actual ARM based WP7 device.

However, GRAPHICS performance is a whole 'nother story. Windows Phone 7 is built from the ground up on a Direct3D stack. The core OS and all graphics all the way up to the Silverlight and XNA runtimes use Direct3D. In the Windows Phone Emulator the low-level D3D graphics are "passed through" to the host PC's D3D implementation. Many problems people see with Windows Phone Emulator performance are due to poorly performing host PC graphics adapters or drivers.

See this forum response for some troubleshooting tips. http://social.msdn.microsoft.com/Forums/en-US/windowsphone7series/thread/c4754ebd-f688-4c33-972a-a578b9db12ff

EDIT: Addressing Jeff's comment below asserting "Anyway, unless Microsoft have a compiler-toolset that can target both the Phone CPU and the regular Windows PC CPU, they are stuck with emulation at the CPU level, rather than at the Operating System Level."

All Windows Phone 7 applications & games are .NET based, thus are CPU independent. Repeating what I said above: The Windows Phone 7 Emulator does NOT emulate at the CPU level. It is running a native x86 compiled version of the OS in a virtual machine and runs the exact same application "binary" (a .XAP file) that will run on a physical device.

tig
  • 3,424
  • 3
  • 32
  • 65
2

You need a directx 10 graphics card to get the best performance.

Tuco
  • 43
  • 6
2

The beta appears to have introduced a problem effecting some peoples systems whereby GPU acceleration is not working in the emulator. The symptoms are slow rendering which is to be expected. I'd suggest adding your system details to the thread while the issue is being looked into for the best chance at a resolution on your system.

Mick N
  • 14,892
  • 2
  • 35
  • 41
0

I think we need to clarify the meaning of this question to glean any type of meaningful answer from it. At the moment we could all very well be talking about different types of performance observations which potentially reduces this to more of a religous debate. I've added a comment to this effect, but you have to click "more" to see it.

Mick N
  • 14,892
  • 2
  • 35
  • 41
0

The official MS document on this subject provides the reason for the slowness.

"Windows Phone Emulator is designed to provide comparable performance to an actual device "

http://msdn.microsoft.com/en-us/library/ff402563(v=VS.92).aspx

CodeGrue
  • 5,865
  • 6
  • 44
  • 62
  • Actually, on this page: http://msdn.microsoft.com/en-us/library/ff402567(v=VS.92).aspx they say "You cannot precisely simulate the performance of a Windows Phone device, because the performance of the emulator depends partly on factors that do not affect performance on a distinct physical device, such as the current operating system, the CPU, and the available system memory". then they go on to mumble about optionally getting "hardware assisted virtualisation". – Jeff Laing Jul 17 '10 at 01:42
  • @Jeff: Do you mean Intel Virtualization Technology that comes with with i5 500-series and i7 CPUs? – Sahat Yalkabov Jul 17 '10 at 05:48
  • Actually, I have no idea. I'm just quoting what Microsoft say in their usual less-than-informative way, requiring that you go look at a bunch of other linked pages to get at simple facts. I stopped being interested in it as soon as they said "you cannot precisely simulate..." since that answered the question at hand, from the horses mouth. Microsoft don't claim to be able to exactly simulate the performance of a device; perhaps by "comparable performance to an actual device" they mean "will crash as often and as randomly. ;-) – Jeff Laing Jul 18 '10 at 06:51
  • Still looking for some foundation based on facts in this thread. – Mick N Jul 19 '10 at 12:33