Is there a way to complie code directly into Native Code instead of MSIL so that we can bypass JIT while executing the code on machine. If its possible. Please let me know the technique also.
Thanks
Compiling MSIL to Native Code Ngen.exe
SUMMARY:
The runtime supplies another mode of
compilation called install-time code
generation. The install-time code
generation mode converts MSIL to
native code just as the regular JIT
compiler does, but it converts larger
units of code at a time, storing the
resulting native code for use when the
assembly is subsequently loaded and
run. When using install-time code
generation, the entire assembly that
is being installed is converted into
native code, taking into account what
is known about other assemblies that
are already installed.
Take look at - How to compile a .NET application to native code?
In the .NET languages I'm familiar with, the source is compiled directly to MSIL. What the JIT does is subsequently compile the IL code to native code.
Related
I am building an application with Lazarus where I use a sqlite database to store thousands of records. Right now I am linking to the sqlite library dynamically via the sqlite3.dll.
Is it possible to link to it statically? Where can I find the Lazarus compatible lib file to do that?
Note:
I only started using Lazarus and Free Pascal a month ago so something that might look very obvious to one, might not be for me. So bear with me a bit.
Cheers
Actual static linking is difficult since the TSQLite3Connection component is inherently designed to actively load the SQLite3 DLL. In other words, it's not linking against the library when you compile the program, the component is coded to dynamically load the DLL at run time.
If you are looking to have a totally self contained program, then you can accomplish this two different ways.
Create a new TSQLite3Connection component that links statically against sqlite3 instead of loading the DLL dynamically.
Include the sqlite3.dll as a resource in your program and have your program automatically deploy it before it runs.
Solution #1 is not trivial and not for the faint of heart. I've done it, and I intended to include a link to the component, but the result isn't stable. The problem is that you have to compile a static version of sqlite3, which isn't a real problem, but you have to do it with something like gcc under MinGW and that introduces issues. Compiling with gcc under MinGW means you have to then link in libgcc.a, and because FreePascal's internal linker doesn't know how to interpret stdcall symbols properly, you also have to link against MinGW's libkernel32.a, and libmsvcrt.a. The result just isn't stable. Crashes galore.
Solution #2 should be fairly easy, but the Lazarus maintainers make it a little hard. The part where you store the dll inside the executable as a resource is easy enough to do. And so is writing it out as a temp file. The problem is that you can't tell the TSQLite3Connection component where to find it after. So it looks in the executable's folder, or in system folders. Neither of which can necessarily be written to by the executable. The only place you can guarantee that your program will be able to write to is a temp folder. So what I did is created a new version of TSQLite3Connection component call TSQLite3DynConnection, meaning you can dynamically specify where the DLL is. I made a published property called ClientLibrary where you can specify the location of the dll (it doesn't have to end in .dll, so you can use system temp filename generation routines). You can get this component at: http://icculus.org/~kfitzner/misc/sqlite3dyndll.zip. It will compile against Lazarus 1.6.2 FP 3.0.0, or FP 1.0.6 / FP 2.6.0, which are the two versions I use.
I'll update this answer if I can get the statically linked version stable.
2 Dec 2016 update: I managed to get a static version stable.
"When the managed code is compiled, the compiler converts the source code into a CPU independent intermediate language (IL) code. A Just in time compiler (JIT) compiles the IL code into native code, which is CPU specific" says here: http://www.tutorialspoint.com/asp.net/asp.net_introduction.htm
Please explain what 'CPU Specific' refers to.
It refers to native code that is specifically for the CPU it is currently running on.
According to MSFT docs:
JIT compilation converts MSIL to native code on demand at application run time, when the contents of an assembly are loaded and executed. Because the common language runtime supplies a JIT compiler for each supported CPU architecture, developers can build a set of MSIL assemblies that can be JIT-compiled and run on different computers with different machine architectures
I'm using a licensed version of Flex Builder Pro to develop an application.
I compiled the swc and generated swf successfully using ANT tasks.
It contains an Advanced Data Grid also. When this application is accessed, I get a runtime error and it fails to load.
TypeError: Error #1007: Instantiation attempted on a non-constructor.
at mx.controls::AdvancedDataGridBaseEx/getSeparator()
at mx.controls::AdvancedDataGridBaseEx/createHeaderSeparators()
at mx.controls::AdvancedDataGrid/createHeaderSeparators()
at mx.controls::AdvancedDataGridBaseEx/drawSeparators()
at mx.controls::AdvancedDataGridBaseEx/updateDisplayList()
at mx.controls::AdvancedDataGrid/updateDisplayList()
at mx.controls.listClasses::AdvancedListBase/validateDisplayList()
at mx.managers::LayoutManager/validateDisplayList()
at mx.managers::LayoutManager/doPhasedInstantiation()
at Function/http://adobe.com/AS3/2006/builtin::apply()
at mx.core::UIComponent/callLaterDispatcher2()
at mx.core::UIComponent/callLaterDispatcher()
I'm adding datavisualization.swc and datavisualization_rb.swc in the build paths.
How can I successfully compile the application without any runtime errors?
Please help.
Include the swcs in the library path as shown here.
Maybe this helps: http://kb2.adobe.com/cps/403/kb403121.html
By coincidence I had the same error a couple of days ago. The source of this problem was a library against I built, which was linked statically against an older version of the datavisualization libraries. Normally libraries should only be compiled against other libraries using the external-library-path compiler option, but this library was compiled incorrectly.
So that library contained older parts of datavisualization that were referenced by code in the library, while my code referenced newer parts from the datavisualization library itself. The result was a mix of older and newer datavisualization classes at runtime.
So check the SWCs that you include in your library path. You can extract these with a ZIP tool. You will then find a catalog.xml file in there. Search for mx/controls/AdvancedDataGrid in this file. In case you can see it included in the catalog, you've found the bogus library.
I'd like to see the command-line arguments that FlexBuilder is using to compile my application. This is so that I can build them into the ANT script I'm working on. Is there any way to view the command line compilation step?
The reason I'm asking for this is that when I compile my app using Ant/Flex SDK vs. FlexBuilder my app behaves differently.
So I figured out the answer.
First of all, you can get a better idea of how FlexBuilder compiles your app by adding a -dump-config=C:\myConfig.xml to the compile arguments in FlexBuilder. This outputs an xml file containing configuration settings used in the compilation step. You can also use this file as an argument to compc or mxmlc if you'd like. Read more about it
here...
But, here's what actually solved my problem. I was using the regular old Flex SDK installed on our integration server to compile my apps using Ant. This is the free SDK you can download from Adobe's site. I then took the FlexBuilder directory from my local machine and copied it up to the integration server and pointed my build script to use that version of the SDK (and changed my path env variable).
When I compiled using the FlexBuilder version of the SDK, all was well and the strange bugs I was seeing in my app disappeared.
Moral of the story, make sure you are using the same version of the SDK for your automated builds as you use to build locally.
What is default type of JIT compiler is used in .Net (visual studio)
out of (Pre-JIT,Econo-JIT,Normal-JIT)?
As far as I know default JIT is Pre-JIT but ASP.NET Does Not Support Pre-Just-In-Time (JIT) Compilation Through Native Image Generator.
A little bit of background on the various JIT types:
PRE-JIT: Compiles complete source code to native code in a single operation.
ECONO-JIT: Compiles only methods called at Runtime.
NORMAL-JIT: Compiles only methods called at Runtime and stored in cache.