but the phase 'compiling in the cloud' was very confusing, people thought Microsoft just run NGEN on the server and call it a big feature of innovation, that will be lame.
I think 'optimizing' is more appropriate here. Actually Kevin Gallo said apps will 'start faster and run faster', while NGEN or pre-jit might help in startup performance but can do little about runtime performance, so I think this 'Cloud JIT' or 'Cloud Code Generation' thing should be more like optimizing AOT compiler for MSIL, in order to improve the overall performance of managed apps.
I see a couple of the potential pitfalls for NGEN, in the cloud, to the phone.
* Sometimes the native image is larger on disk. * Sometimes the native image is slower, how do you tell without testing? * The apps are sandboxed, so it's not like one app is going to use a library in another.
I asked Charles about this on Ch9Live the other day. It's not NGEN'ed, it's JIT'ed. I thought it was NGEN'ed at first.
The main reason for this is because JITting allows code-generation on-box, which potentially means that the code you're running on a client computer is different to the code that was audited by Microsoft during the on-boarding process for the appstore.
Consequently, Microsoft are looking to deprecate JITting for apps distributed through the appstore - at least initially for Windows RT, but later rolling out to all of Windows8.
This also has the benefit that the cloud can do really agressive optimisations, rather than having to perform a trade-off between optimising more and needing to start running the function as soon as possible.
It also has the benefit that it allows Microsoft to be consistent when it starts telling other developers that they're not supposed to use VirtualProtect/VirtualAlloc or build their own JITters in Metro apps when they're doing it themselves for .NET.
Finally it has the added benefit that cloud-JITting means that 100% of your battery power in .NET apps on WindowsRT are spent running code, rather than JITting code, which should stretch your battery life a little while longer.
words from the WP8 SDK documents:
How to test the retail version of your app for Windows Phone
Before you release your app in the Marketplace, we recommend that you build it as a native image, to test its performance on a device as users will experience it.
When you build your app in Visual Studio, the code is not compiled into a native image, but into a machine-independent Common Intermediate Language (CIL) binary file. (CIL was formerly known as Microsoft Intermediate Language, or MSIL.) This CIL file is what you submit to the Marketplace when you're ready to sell your app. At that time, the binary file is converted from CIL to Machine Dependent Intermediate Language, or MDIL. Finally, when the user downloads your app to a device, the MDIL file is linked to produce a native image. You can repeat these steps in your development environment by changing certain build options in Visual Studio.
The functionality of your app is not affected by the native code generation. However the native image typically starts and runs faster.
To build and test your app as a native image
In Visual Studio, on the Standard toolbar, select Device as the deployment target. You cannot test native code generation on onthe emulator.
In the Solution Configurations drop-down list, select Release to create a Release build. You cannot generate native code for a Debug build.
On the Tools menu, select Options to open the Options dialog box. In the navigation pane, select Debugging.
In the list of debugging options, make the following changes:
Deselect the Suppress JIT optimization option.
Select the Enable Just My Code option.
Click OK to close the Options dialog box.
Build or rebuild your app, and test its performance and responsiveness.
And, there is a crossgen.exe which is “Microsoft Common Language Runtime native cross compiler”, version 4.0.50622.1 built by: CLR_TRITON
Microsoft (R) CoreCLR Native Image / MDIL Generator - Version 4.0.50622.1 Copyright (c) Microsoft Corporation. All rights reserved.
Usage: crossgen [args] <assembly name>
/? or /help - Display this screen /nologo - Prevents displaying the logo @reponse.rsp - Process command line arguments from specified response file /fulltrust - Assembly will be run in a full trust domain. /in <file> - Specifies input filename (optional) /out <file> - Specifies output filename (optional with native images, required with MDIL) /MissingDependenciesOK - Specifies that crossgen should attempt not to fail if a dependency is missing. /Trusted_Platform_Assemblies <path[;path]> - List of assemblies treated as trusted platform /Platform_Resource_Roots <path[;path]> - List of paths containing localized assembly directories /App_Paths <path> - List of paths containing user-application assemblies and resources /App_Ni_Paths <path[;path]> - List of paths containing user-application native images - Must be used with /CreatePDB switch /Platform_Winmd_Paths - List of paths containing target platform WinMDs used for emulating RoResolveNamespace Compatability Modes /PreWP8App - Set the Windows Phone 8 "Quirks" mode, namely AppDomainCompatSwitch= WindowsPhone_184.108.40.206 or WindowsPhone_220.127.116.11. MDIL Generation Parameters /mdil - Generate MDIL rather than native code. Requires presence of /out switch. /nomdil - create MDIL image with no MDIL code or CTL data structures, use to force fall back to JIT /EmbedMDIL - Embed a previously created mdil data in IL image into native image. /fxmdil - Generate framework assembly MDIL images containing minimal MDIL Debugging Parameters /CreatePDB <Dir to store PDB> [/lines [<search path for managed PDB>] ] When specifying /CreatePDB, the native image should be created first, and <assembly name> should be the path to the NI.
The interview covering this in detail will be released when the timing is right (I already filmed it with the lead dev and PM for the project). Go ahead and MJF this all you want, Felix... The reality of the situation will be made crystal clear in the future.
It means my time window is narrowing, lets see how much I can do before the truth surfaces.
Sofar I saw an MDILBinder.exe inside the emulation image, and apparently there will also be an mdilnigenlibrary.dll. Plus, evey managed assembly .dll or .ni.dll has a .mdil PE section, I hope these are related to CrossGen.exe.
Also, I saw a HDRLens.mdil.xap somewhere in the vhd.
OK, apparently the time is still not so 'right' yet, so let me looking at it a little more.
The word MDIL is not a new thing, we have seen it in Bartok before:
/TargetMdil=<bool> (currently False) Target MDIL rather than native code
/TargetMdilEHPerBB=<bool> (currently False) When targeting MDIL, emit separate EH records for each basic block
/TargetMdilBartokRuntime=<bool> (currently False) When targeting MDIL, assume that libraries include the Bartok runtime
/ClrMdil=<bool> (currently False) Target/consume CLR-MDIL rather than Bartok-MDIL (not complete)
/RedhawkMdil=<bool> (currently False) Target Redhawk-MDIL rather than Bartok-MDIL (currently implies ClrMdil as well)
/RedhawkBaseClassLibrary=<bool> (currently False) Generate MDIL for a Redhawk base class library (include well-known types table in the CTL)
/MdilV2=<bool> (currently False) Use version 2 of the MDIL instruction encoding (automatic/required for x64)
So there were CLR-MDIL, Bartok-MDIL and Redhawk-MDIL, and also MDIL v2, and thats many years ago.
Alright, Charon aka Ma-Config showed me this patent, it has a detailed description of MDIL.
MDIL Instruction Set: Explaining Instruction Formats and Conventions in MDIL Code
This section discusses the binary encoding and the semantics of MDIL instructions.
What is MDIL? MDIL is a lower level of intermediate language than MSIL. It gives up on the goal of machine independence—in fact the acronym MDIL stands for Machine Dependent Intermediate Language. MDIL doesn't compete with MSIL—rather, going through MDIL is another step in the compilation pipeline going from source code in languages like C#, Visual Basic®, Managed C++ via MSIL to native code (mark of Microsoft Corporation). MDIL doesn't try to abstract properties of the target processor, but it still provides a layer of insulation against versioning of both managed code and the execution engine MDIL code is compiled for.
MDIL is not directly executable. Instead, a binder reads the MDIL code and produces executable machine code from it. MDIL code is thus reminiscent of object files resulting from the compilation of unmanaged code which are run through a linker to produce final executable machine code. However, pseudo instructions in MDIL may go further than fixups in traditional object files—rather than just fixing up parts of instructions (like an address field), MDIL pseudo instructions may generate new native instructions which possibly differ in length from the pseudo instruction. Thus the MDIL binder is more complicated than a linker because the binder has to adjust the jumps in the resulting native code so they still jump to their intended targets. With this added complexity also comes added power—MDIL code can be robust against base types adding new fields or virtual methods, so it can be considered a solution to the "brittle base class problem".
You should clear up the point or discovery you are making here. Are you saying that you think Microsoft will be doing cloud compiling of applications in their App Store which will target the users (purchaser) hardware. This new feature will optimize the runtime to be more efficient. So if I have a phone with 4 cores it will compile to use all of them? What is it that you think Microsoft is doing here.
Well, the MDIL data generated by CrossGen has a version number 0x0002000c or 2.12, its much newer than the version descripted in the patent, 0x00020006 or 2.06. The header size of 2.12 is 120 bytes, larger than the 92 bytes of 2.06 version or 72 bytes in Singulariy's Bartok, so its hard to understand.
But I found another interesting thing in that patent:
PlatformID_Unknown = 0,
PlatformID_Triton = 1,
So that was CLR Triton !
@felix9: Oh Felix... Don't you have code to write, man?
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.