09-25-2017 07:54 PM
263 ... 91011
tools
  1. Drael646464's Avatar
    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).
    06-11-2017 11:41 PM
  2. nate0's Avatar
    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 likes this.
    06-12-2017 12:02 AM
  3. Rosebank's Avatar
    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.
    nate0 likes this.
    06-12-2017 03:34 AM
  4. a5cent's Avatar
    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 :-/
    Last edited by a5cent; 06-12-2017 at 07:59 PM.
    Rosebank and Drael646464 like this.
    06-12-2017 07:47 PM
  5. a5cent's Avatar
    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.
    nate0 and Rosebank like this.
    06-12-2017 07:58 PM
  6. Drael646464's Avatar
    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
    06-13-2017 03:56 AM
  7. Rosebank's Avatar
    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 likes this.
    06-13-2017 04:13 AM
  8. a5cent's Avatar
    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.
    Rosebank likes this.
    06-13-2017 07:17 AM
  9. Drael646464's Avatar
    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.
    06-13-2017 08:36 AM
  10. Drael646464's Avatar
    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.
    06-13-2017 08:36 AM
  11. Grant Taylor3's Avatar
    When I was running FX!32 it would take 3 or 4 runs of the application before it was fully optimized.
    Drael646464 likes this.
    06-14-2017 02:12 AM
  12. Rosebank's Avatar
    Hi Folks, I was wondering if there were any developments? Last I heard there were copyright issues with Windows on Arm and x86 Emulation, Intel had piped up and since then I have heard very little, looked like a minefield tbh. Any updates very welcome, Many thanks.
    09-21-2017 11:30 AM
  13. Joe920's Avatar
    Hi Folks, I was wondering if there were any developments? Last I heard there were copyright issues with Windows on Arm and x86 Emulation, Intel had piped up and since then I have heard very little, looked like a minefield tbh. Any updates very welcome, Many thanks.
    Nothing new afaik. We'll have to wait for the MS Hardware event in London on Oct 31st. If they introduce a Surface on ARM we'll hear all about the emulation part.
    09-25-2017 07:54 PM
263 ... 91011

Similar Threads

  1. Win 8.1 enterpise to W10
    By costas60 in forum Windows 10
    Replies: 1
    Last Post: 11-15-2016, 11:49 AM
  2. Replies: 2
    Last Post: 11-15-2016, 11:25 AM
  3. No, Microsoft isn't working on Xbox game streaming to Windows 10 Mobile, but it should!
    By WindowsCentral.com in forum Windows Central News Discussion
    Replies: 0
    Last Post: 11-15-2016, 09:42 AM
  4. how to download in my lumia 1020 this w10 build 10586
    By Windows Central Question in forum Ask a Question
    Replies: 1
    Last Post: 11-15-2016, 03:45 AM
LINK TO POST COPIED TO CLIPBOARD