W10 Mobile x86 .exe Emulator

[Rosebank]

It's exactly this type of thing that leads me to believe MS is translating x86 to ARM on-the-fly at runtime, rather than ahead of time, which would make it completely different from the approach used by FX!32.

MS have quite clearly stated that this is exactly how they deal with this, its clearly mentioned in the last video link. No guess work required.

 

[Rosebank]

The translated code is then cached into memory or Disk for subsequent use.

 

[a5cent]

MS have quite clearly stated that this is exactly how they deal with this, its clearly mentioned in the last video link. No guess work required.

Well that settles it then. I haven't checked the video yet, but I'll take your word for it. It already seemed like the far more likely approach based on the existing documentation.

 

[Drael646464]

MS have quite clearly stated that this is exactly how they deal with this, its clearly mentioned in the last video link. No guess work required.

Which - ahead of time, or on the fly?

 

[Rosebank]

Which - ahead of time, or on the fly?

Watch the link, its been on this Thread for months, but I just posted it again today. On the previous page.
https://channel9.msdn.com/events/Build/2017/P4171
Goto 7 mins 45 seconds.

 

[Drael646464]

Watch the link, its been on this Thread for months, but I just posted it again today. On the previous page.
https://channel9.msdn.com/events/Build/2017/P4171
Goto 7 mins 45 seconds.

Okay, that was very clear. They convert chunks of code, and cache them in memory and on disk for later use, plus they run the system DLLs in native arm.

So the software itself is run real-time, with caching, and all the OS calling is run native (helped along by the fact that conversion from 32 to 64bit is light work via WoW).

So the performance, as they say, is going to depend on the app, and what use it makes of the same code repeatedly, or OS dlls.

I wonder how much disk caching is involved, and how much ram caching? Presumably this will be a factor in running some apps.

 

[a5cent]

Okay, that was very clear. They convert chunks of code, and cache them in memory and on disk for later use, plus they run the system DLLs in native arm.

Could it be that MS' claim of it running near native speeds applies only after everything has been translated and written to disk for subsequent use?

If that's the case, then it would be somewhat of a hybrid solution. Slow execution once but near native speeds with a FX!32 like approach afterwards?

 

[Rosebank]

Could it be that MS' claim of it running near native speeds applies only after everything has been translated and written to disk for subsequent use?

I have been thinking about that, the program might be slow to begin with but once all the translation has taken place then its stored for subsequent use and faster preforming, what I wonder is if you have x2 x86 programs running can the translated code be shared if there are duplicate code conversations or would the two x86 running programs be treated totally separate? I would be interested to know if there is any cross over (sharing) between 2 or more running x86 programs under Emulation.

 

[nate0]

There is NO water or any other type of liquid cooling on the 950 or 950xl.

The 950 xl has a heat pipe wick cooling system. I am unaware if any or if so what kind of substance/material was inside.

The 950 might have a pipe too.

The mention of it when announced has been of controversy so the thought behind it was that it was a wicking/condensing cooling system. Physical liquid/water inside well no. At least not to the naked eye.

 

[a5cent]

I wonder is if you have x2 x86 programs running can the translated code be shared if there are duplicate code conversations or would the two x86 running programs be treated totally separate?

That I can already answer. If the executable binary itself is shared, as is sometime the case with a DLL, then the translation would likely also be shared (at least it should be). Otherwise the binary translation is totally separate. There is virtually zero overlap in in two unrelated binaries, so just trying to find overlap would be rather fruitless and a waste of CPU cycles that would be better invested elsewhere.

 

[Drael646464]

Could it be that MS' claim of it running near native speeds applies only after everything has been translated and written to disk for subsequent use?

If that's the case, then it would be somewhat of a hybrid solution. Slow execution once but near native speeds with a FX!32 like approach afterwards?

Yeah that's how I would expect this to operate, because its caching - which is why every time we've seen this demo'd the application is either pre-installed, or something light and repeatitive (7zip). Presumably it'll take disk space and ram space, the more win32's you run too.

What they said in the video was basically "near native speeds depending on how much is executed on the native side versus the emulated side". So its going to depend on how much OS dll calls there are, and how well the code can be cached, whether that function has been previously caches, as to how close it can get to that 70% ish mark.

Which would explain why they executed a single filter in photoshop (presumably pre-executed).

 

[nate0]

Yeah that's how I would expect this to operate, because its caching - which is why every time we've seen this demo'd the application is either pre-installed, or something light and repeatitive (7zip). Presumably it'll take disk space and ram space, the more win32's you run too.

What they said in the video was basically "near native speeds depending on how much is executed on the native side versus the emulated side". So its going to depend on how much OS dll calls there are, and how well the code can be cached, whether that function has been previously caches, as to how close it can get to that 70% ish mark.

Which would explain why they executed a single filter in photoshop (presumably pre-executed).

On the caching part does it depend on what part is volatile or not? Meaning if executed once (assuming the Photo Shop filter) is that something that is cached during that programs run time indefinitely until next boot, the program exits, until more space is needed (if volatile cached)? Maybe that is something we can not answer yet. Also is this type of caching or method of new?

 

[Rosebank]

Surely it would have to be as the programs exits, we cant be filling up Ram and or Disk space like this stacking it all until next boot, would make sense to wipe the cache as the progam exits, this would be the best use of resources in my opinion, also the L950 does not use liquid cooling, this was a false flag when the devices were being manufactured and the pre release hype, it remained an issue of uncertainty even after release but as far as I know its not a liquid cooled device. L950 xl is purported to have liquid cooling because of 2 small copper pipes but nobody seems to know how it works, this may potentially be some form of liquid cooling but its still quite an unknown, it uses the 810 and not the 808 so runs hotter, I did read that there may be liquid in 1 pipe that boils, then travels along to the other pipe and condenses back to water but I am still uncertain. I watched several BEND tests of the device and there was no liquid escape, but we could be talking less than a tear drop of liquid I suppose.... Also there was a report of a person opening the heat pipe to discover some powder and not liquid, the thinking was that the powder got hot, turned to Gas and then condensed to a liquid?? Again that was hearsay from some time ago, Even now the general consensus is that this was a marketing gimmick to sell the XL but I am more than happy to be proved wrong.

 

[a5cent]

Yeah that's how I would expect this to operate, because its caching - which is why every time we've seen this demo'd the application is either pre-installed, or something light and repeatitive (7zip). Presumably it'll take disk space and ram space, the more win32's you run too.

What they said in the video was basically "near native speeds depending on how much is executed on the native side versus the emulated side". So its going to depend on how much OS dll calls there are, and how well the code can be cached, whether that function has been previously caches, as to how close it can get to that 70% ish mark.

Which would explain why they executed a single filter in photoshop (presumably pre-executed).

Yup. I'm not yet willing to bet on this being correct, but it's probably the best guess we can make with the information we have. I give it an 85% chance of being right. ;-)

The demonstration of the Photoshop filter is actually even worse than you assume. That filter runs on the GPU. That means the CPU is entirely uninvolved, and wouldn't require any x86 emulation or ISA translation of any kind, not even on the first run.

It's like demonstrating how fast a car can reach the finish line with a car that has already crossed it :-/

 

[a5cent]

On the caching part does it depend on what part is volatile or not? Meaning if executed once (assuming the Photo Shop filter) is that something that is cached during that programs run time indefinitely until next boot, the program exits, until more space is needed (if volatile cached)? Maybe that is something we can not answer yet. Also is this type of caching or method of new?

I agree with Rosebank. Whatever has been newly translated and still resides in RAM would be written to disk no later than when the application is terminated. Allegedly ISA translation occurs in chunks/blocks. If I was implementing this mechanism I would write individual blocks to storage whenever the system is idle, meaning potentially before the application is terminated. No idea what MS' actual approach is.

 

[Drael646464]

I agree with Rosebank. Whatever has been newly translated and still resides in RAM would be written to disk no later than when the application is terminated. Allegedly ISA translation occurs in chunks/blocks. If I was implementing this mechanism I would write individual blocks to storage whenever the system is idle, meaning potentially before the application is terminated. No idea what MS' actual approach is.

Seems like it would be "until more space is needed". So priority programs will run better, and systems with more internal storage would be more ideal for peak performance - that's my guess shruggity

 

[Rosebank]

Another interesting fact is the core speeds, on the video I linked we see a screen shot of 1.9ghz, but the Qualcomm guy goes on to say "We have not released what the peak speed will be of the big cores and the 1.9ghz refers to core ZERO a little core" So when put to him this will be in larger boards than a mobile... he remained tight lipped about the maximum GHZ of the larger cores, a crucial factor in the "Near Native Speeds" surely.

 

[a5cent]

Seems like it would be "until more space is needed". So priority programs will run better, and systems with more internal storage would be more ideal for peak performance - that's my guess shruggity

So, if more space is needed while a priority program is running, then your proposed solution would be counter productive. It would do exactly what you are hoping to avoid at the worst possible time.

More importantly, writing translated ARM code to disk wouldn't even necessarily free up space when "more space is needed". Why? Because if the program is still running, then the ARM code must continue to reside in memory. Being written to disk is NOT what determines if translated ARM code cam be unloaded from RAM.

I don't KNOW how it works, but we can be quite sure that this is not how.??????

 

[Drael646464]

So, if more space is needed while a priority program is running, then your proposed solution would be counter productive. It would do exactly what you are hoping to avoid at the worst possible time.

More importantly, writing translated ARM code to disk wouldn't even necessarily free up space when "more space is needed". Why? Because if the program is still running, then the ARM code must continue to reside in memory. Being written to disk is NOT what determines if translated ARM code cam be unloaded from RAM.

I don't KNOW how it works, but we can be quite sure that this is not how.������

I think you misread me.

I just meant that this would run like conventional caching - held in ram, until something else pushes it out due to priotiy, held on disk, until something else pushes it out due to priority - with some set amount of disc allocated to it.

So programs you use more often will have more cache allocation, and programs more actively running will have more ram allocation etc.

All I was pointing out, is that the cache on disk should persist after closing, as current caches do (otherwise you'd be re-doing it every time, slowing performance), and that such a cache would take up system resources - ram and particularly storage, such that systems with more ram, and more storage would emulate better performance.

 

[Drael646464]

Another interesting fact is the core speeds, on the video I linked we see a screen shot of 1.9ghz, but the Qualcomm guy goes on to say "We have not released what the peak speed will be of the big cores and the 1.9ghz refers to core ZERO a little core" So when put to him this will be in larger boards than a mobile... he remained tight lipped about the maximum GHZ of the larger cores, a crucial factor in the "Near Native Speeds" surely.

Bigger devices means more cooling, which might be higher clock speeds.