Slow data transfer for embedded Mono on Linux - mono

I have C/C++ code that currently use MS CLI support and runs on Windows. I use embedded Mono to replace CLI to port the code for Linux.
I use C# class library. The algorithm is
Set C# class fields
Run c# class member function
Read C# fields data to C++ space.
My problem is transfer of numeric, mostly int and double) fields. Currently mono_field_set_value function takes more than 30 times slower, than field update on Windows with CLI.
I am looking for ideas what can course performance degradation and ways to improve it.
I currently have C# DLL compiled on Windows for .Net 4.7 runtime.
I also pin C# classes with mono__gchandle_new( obj, true).

Related

Distinction between programming language and framework

I'm a student and started developing some projects in VB.Net and I'm liking it a lot. However, I asked this question to some colleagues and they couldn't answer. Even my teacher wasn't able to clarify what was exactly VB and .Net. I have checked this question here but even the accepted answer gives me some doubts.
For example, for this bit of code here
Class Example
Private _value As Integer
Public Sub New()
_value = 2
End Sub
Public Function Value() As Integer
Return _value * 2
End Function
End Class
Module Module1
Sub Main()
Dim x As Example = New Example()
Console.WriteLine(x.Value())
End Sub
End Module
How can the language be separated from the framework? I know the language is syntax and all but, where is the framework?
I've read that frameworks contain libraries: what are exactly libraries? The language (syntax and all) I can see it, it can be seen, but is the framework visible too? If so, where?
So in a VB.Net application, when I look at the code, all I can see is VB: the same goes for C#.Net applications.
Maybe silly example: For instance, for a car to function, all components must be good - from the tires to the hood, the engine, the fuel - but all of them are visible, and while from the outside we can't see the oil or fuel running inside or the pistons working, we can see them if we want.
Is it possible to see all the components when looking at a VB/C# .Net application? I mean, to look at code and clearly distinguish what is VB or C# and .Net?
Thanks
There are three primary parts to the .NET framework:
Compiler (MSBuild)
Runtime environment (CLR) - virtual machine, garbage collector, etc.
Supporting libraries (FCL)- System, ADO.NET, LINQ, WPF, WCF, etc.
All three of the above are included with the freely-distributed .NET Framework. The term .NET Framework refers collectively, and loosely, to all of those things, but they each perform very different roles. The answer to your question is different for each of those parts.
Compiler
As you probably know, you cannot run VB.NET code directly. It must first be compiled into an executable which can be launched as a Windows process. The compiler is used to compile a variety of high level languages (such as VB.NET and C#) into assemblies (e.g. EXEs, DLLs). Unlike native compilers, though, .NET assemblies do not contain native machine code. Instead, the .NET compiler compiles into .NET assemblies which contain MSIL code. MSIL is a slightly-higher-level-than-machine-code language which, in theory, can be run by a virtual machine on any platform.
The compiler is obviously not visible in your code. Obviously there is no place in your code where you can say "that's the compiler". Rather, the compiler is the tool that you use to compile all of your code. The compiler, though, does dictate what languages you can use. If the .NET framework does not contain a Ruby compiler, then you can't very well write a .NET application in Ruby. So, in that way, the fact that your code is written in VB.NET or C# at all is the indication that it will be compiled using the .NET Framework.
You may be thinking, "The compiler isn't part of the framework--that's part of Visual Studio." But if you were thinking that, you would be wrong. The compiler is installed as part of the .NET framework. You don't technically need Visual Studio to compile a .NET application. You could write an application in any .NET language, using Notepad, and then compile and run it with the .NET Framework without ever having installed Visual Studio.
The compiler portion of the .NET Framework is referred to as MSBuild.
Runtime Environment
Since the compiler compiles your high-level code into MSIL assemblies, rather than into native machine-code binaries, you must have the .NET Framework installed in order to run any .NET application. When you run a .NET application, the Framework is responsible for just-in-time (JIT) compiling the MSIL code into machine code so that it can be executed on your current platform. It also provides the memory management features such as garbage collection.
The same runtime environment is shared by all .NET languages (since all .NET languages compile to MSIL code). Therefore, it's not a VB.NET runtime environment nor a C# runtime environment, but rather, it's a MSIL runtime environment. Instead of having one runtime environment per language, there is actually one runtime environment per platform. A separate environment must be custom implemented for each processor architecture and each operating system on which the Framework will run.
This part of the framework is largely invisible to you and your code. There are some methods you can call to access the GAC, or the garbage collector, or the .NET security system, but other than that, you don't even know it's there. Unless the Framework isn't installed, that is--in that case, it becomes clear very quickly just how necessary it is.
The runtime-environment portion of the .NET Framework is referred to as the Common Language Runtime (CLR).
Supporting Libraries
The .NET Framework comes packed with many extraordinarily useful libraries (DLLs). For instance, every application references the mscorlib.dll and System.dll libraries, which provide many of the core data types in the System namespace. There are many other libraries which you can optionally reference with your projects as necessary.
These supporting libraries are provided as already-compiled MSIL assemblies, so they can all be referenced and used by projects written in any .NET supported language. When you call Console.WriteLine("Hello World") in VB.NET and Console.WriteLine("Hello World"); in C#, you are calling the exact same .NET Framework library. The Console class is defined in the mscorlib.dll library. It doesn't matter which language you use to call it, it always does the same thing.
The supporting libraries are very visible in your code. Any time you use anything that is not explicitly defined by you in your own code, you are using the Framework (unless, of course, it's something from a third-party library). In your example code above, you are using Integer and Console. Both of those types are defined by the .NET Framework's supporting libraries (both are defined by mscorlib.dll). In other words, the language is all of the syntax that you use to make the calls to the Framework. Everything else is the Framework.
If you want to "see" the supporting libraries, the best place to start is in Visual Studio. You can use the Object Browser to browse through all of the types defined by the libraries that you currently have referenced in your project. If you want to reference more .NET Framework libraries, go to your Project Properties designer's References tab, click the Add... button, then select the Asseblies > Framework option. That will list all of the supporting libraries that are provided as part of the .NET Framework. If you want to find out more about any of the functionality provided by any of those libraries, your best resource is the MSDN (and Stack Overflow, of course).
The supporting libraries portion of the .NET Framework is referred to as the Framework Class Library (FCL).
Here is how I envision the two
The framework is the set of libraries, APIs and runtime components that are available for the language to use
The language is the syntax by which the framework is accessed
In many cases it's hard to separate the two because the language when used is nearly always accessing some part of the framework. Take for instance even this very simple definition
Class Example
End Class
Even though it is unstated, this definition depends on the targeted framework having a definition of System.Object. This is necessary for the language to setup the appropriate base class for Example.
You have to keep in mind that if you're using a programming language, at some point it all must boil down to binary 1's and 0's.
This means that when your program gets compiled and run, it's making use of the C# compiler. The C# compiler is a program written in a native language (probably c or c++). This program allows yours to be converted into stuff that the .net framework runtime can understand. Essentially, your C# code becomes some sort of intermediate bytecode.
Similarly, after your program is compiled into this intermediate bytecode, it is run on top of a virtual machine (JVM for Java or the .net framework runtime for C#). This virtual machine is a pre-compiled program written in a native language (c or c++), which allows your program to interface with the computer's processor in a way that both understand.
All of these pre-written, pre-compiled pieces are part of a framework. They are installed to your machine in some particular location (which is why they might not be readily visible with the rest of your code and assets) and provide APIs to anything that wants to make use of them.
The APIs are analogous to the understanding between a gas pedal and an engine. An engine accepts more fuel as a result of someone pressing the gas pedal. In some sense, the engine "talks" to the gas pedal and understands that if you press firmly on the pedal, the engine should respond by injecting more gasoline into the combustion chambers.
These individual pieces, along with their "understandings" represent a framework. You might add a "Driver" who can operate a gas pedal as your "C# Application".
How can the language be separated from the framework?
For example... take for instance English, English is a language, while a book would be a Framework. In this example, you can write whatever you want in English, but you can't write in "The Hobbit", because it is a book, not a language.
However, you can make references to the book. For instance you can talk about Trolls, and you don't have to define it's behavior or looks, because the book already defines them for you.
Where is the framework?
The framework exists whenever you make reference to it. In the Trolls example, if you ask "Do you know how do Trolls look like?", I would need a context for that, it may be Harry Potter's, Tolkien's, World of Warcraft's, etc. And I will give you compilation errors because I can't understand you.
If however we "use" the same "Framework" (book), or if you tell me about them before, I would be able to respond you (compile).
Is the framework visible too? If so, where?
VB/C# are languages, you can't "really see" where it is, because you write it. It is like asking where is English. You can however compile it, and that is what you can "find", just like you can find a printer.
The Framework is a set of libraries/utilities already packed into a beautiful black box that you download and trust your life to.
VisualStudio helps you a lot, and it will hide "complicated stuff", imagine like it is a movie called The Lord of The Rings, and it removes a lot of stuff that you can't really look into unless you read the book.
You can't really dive into "what .NET does internally", because it is closed software. Imagine that I burn down all the books and you have to trust the movie.
But you could use an Open Source example such as Struts (a JavaEE Framework) because it is open source (books should not be burned in Open Source examples).
Here is an abstract example.
Speech is similar to a framework, you have phonation, producing sound;
resonance; intonation, variance of pitch, etc. Those are all the building blocks for communicating.
To speak a specific language, you must utilize phonology, morphology, language syntax, proper grammar; semantics, etc - all the rules for that Language.
...
In a programming framework, you have building blocks (code libraries, dependent files, specific folder/file layout, ect.) that you might need to complete a programming task.
A programming language is the set of rules you must abide to in order for your application to correctly work.
....
In the Java programming language, I could open notepad and write java code, compile it, and run it on any machine that has the JVM installed.
Java Server Faces (JSF) is a framework where a Model-View-Controller (MVC) paradigm exists as the basis to run web applications. You have necessary dependent files (like web.xml) that must exist for the server to correctly implement, structured layout of classfiles, and implementation/configuration of other libraries. In an essence, your files are still written in the Java Programming language and your syntax must be correct, but if you want to build a web application using that framework, you must have adhere to those other specific patterns and constraints.

Calling Matlab from VB

I am building an application in VB (VS2012) and the main code is written in Matlab. I would like to call the Matlab scripts from the VB form and also display the results of the calculations in the VB form in a datagrid. Can somebody suggest what my mode of exchange should be?
Thanks for the help.
You have two main options.
MATLAB has a COM interface. From VB, you can start an instance of MATLAB, pass data to it, execute commands, retrieve results, and quit MATLAB. To find out more, take a look at the documentation pages for the MATLAB COM Automation Server. This method will require you to have a live copy of MATLAB present when you run your VB application.
You can use an add-on product to MATLAB, MATLAB Builder NE for .NET (you'll also require another add-on that it depends on, MATLAB Compiler). MATLAB Builder NE allows you to convert your MATLAB code into a standalone .NET assembly or COM component that can be called from your VB application, and distributed with it.
Note that contrary to a comment, MATLAB Compiler alone without MATLAB Builder NE does not allow you to produce .NET assemblies.

How to call a MATLAB code from Objective C

I'm planing to write my algorithmic codes in Matlab. And I need to convert .m files into a format where Objective-C can access. When I try mcc, the following error appeared.
The -t switch is no longer supported; the Compiler no longer generates C/C++
source code for M-functions (it generates wrapper functions instead, see
the documenation for -W).
If mcc is not creating C source codes how can i generate wrappers? and do i have to copy both m file and the wrapper in order to make everything working?. And will those wrappers work in iOS??
MATLAB Compiler does not convert MATLAB code into C code, and has not done so for a long time now.
Instead, it archives and encrypts your MATLAB code and creates a wrapper (which could be an executable, a library or, if you have access also to any of the Builder products, a .NET assembly, a Java .jar file, or an Excel add-in). This wrapper dearchives and decrypts your MATLAB code, and executes it against the MATLAB Compiler Runtime, which needs to be included with your application (but is freely redistributable).
You are not going to be able to run the MCR on iOS - its footprint is just too big. If you are targeting another platform with Objective-C, you could produce a library using MATLAB Compiler and call that from your Objective-C.
MATLAB Coder (not the same as MATLAB Compiler) can convert a subset of the MATLAB language into C code. If you are targeting iOS this would be one approach, or you could alternatively run your MATLAB code remotely, and have your app access it via the web.
I'm a little confused by what you have written so I may not be answering your real question:
The Matlab documentation provides clear instructions on how to use the Matlab engine from C programs. Since Objective-C is just C with knobs on, I see no reason why you shouldn't call the engine from an Objective-C program. All that the Matlab engine will see when it is running are valid calls, it has no clue what language the calling program is written in.
I think that for your usage of mcc is irrelevant; what you need is an Objective-C compiler on your Mac. The Matlab documentation suggests that the compiler included in XCode up to v4.1 is OK for Matlab engine applications. In my experience, it may take a little fiddling with compiler options to make a more recent compiler work with your installation of Matlab, but no more than that.
If you plan to use Objective-C calling Matlab, you may not want to start by writing M-files for your algorithmic core. Actually, you probably will, but the Matlab engine doesn't really run M-files, it executes commands sent to it by an external program, such as your Objective-C program. Your development route might be (1) write M file to implement algorithm, then (2) write Objective-C program calling Matlab engine at critical steps when the Matlab functionality is required. You could write your application to make the engine run an M-file (I think) but this is outside my experience.
While you can use Matlab to run a compiler to build your programs, in this case you are probably better using XCode (or your preferred Mac IDE) to build your programs, taking care to ensure that the right linkages are made to the Matlab engine. Again, the documentation explains what you need to do.
No wrappers are involved. No M-files are required. And good luck getting the Matlab engine running on iOS !

OpenNETCF and Windows Embedded Standard O/S

If I have an application that is written in .net Compact Framework (and runs on Windows CE) and is theoretically compatible with Windows Embedded Standard O/S, would it still be compatible if it makes use of OpenNETCF functionality?
Things like running .exe files with help of OpenNETCF for example. I am assuming that OpenNETCF uses P/Invoke under the hood, which might make the application incompatible with other OS than Windows CE.
I don't use P/Invoke in my code, but I can't asnwer for sure whether OpenNETCF does or does not.
.net compact framework 2.0 and windows embedded standard
OpenNETCF does use P/Invoke extensively.
It is effectively a wrapper for some core OS functionality in Windows CE and its derivatives, that is not otherwise implemented in the Compact Framework. In practice this means extensive P/Invoking of coredll.dll; the basic OS module for Windows CE.
Windows Embedded Standard is Windows XP. For this reason I would not expect you to be able to use OpenNETCF.
Depending on the version you're using you may be able to get hold of the OpenNETCF code here (or buy the latest of course), and see what's going on under the hood. Also, what you may find is that the calls you are making to the OpenNETCF are actually implemented anyway when compiling for Windows Embedded Standard.
One way to approach this is to make another project to target this platform, containing exactly the same code files, but no reference to the OpenNETCF, then work through fixing the compile errors.
You can add a Conditional compilation symbol to either the CE project or the Windows Embedded project then fix the errors like so (This example is not for OpenNETCF, but you get the idea):
public static string ExecutingAssembly
{
get
{
#if WindowsCE
return Assembly.GetExecutingAssembly().GetName().CodeBase;
#else
return Assembly.GetExecutingAssembly().Location;
#endif
}
}
Obviously you will then have to create a build for each platform as the outputted assemblies will now be different.
As Chris points out, the SDF makes heavy use of coredll P/Invokes. That's not to say everything does, but it's certainly a minefield. I tend to have a CF project and a FFX project and places where I have overlap I use aliasing, like this:
#if WindowsCE
using Thread = OpenNETCF.Threading.Thread2;
#else
using Thread = System.Threading.Thread;
#endif
Then in the code you just do your normal
var thread = new Thread(...);
And things work out.
Now ages ago we did start an interesting side project of creating a coredll "shim" for the desktop. What that means is that a p/invoke to "coredll" on the desktop would actually call that DLL, which would in turn marshal the calls off to kernel32, user32 or whatever. Our testing for what we implemented (and there's a fair bit there) showed that it worked just fine, so if you're using a limited subset of APIs, just dropping it on the PC might make the CF assembly "just work".

Can JScript.NET be used to script a .NET application?

Since MS appears to have killed Managed JavaScript in the latest DLR for both server-side (ASP.NET Futures) and client-side (Silverlight), has anyone successfully used non-obsolete APIs to allow scripting of their application objects with JScript.NET and/or can explain how to do so? A Mono/JScript solution might also be acceptable, if it is stable and meets the requriements below.
We are interested in upgrading off of a script host which uses the Microsoft JScript engine and ActiveScript APIs to something with more performance and easier extensibility. We have over 16,000 server-side scripts weighing in at over 42MB of source, so rewriting into another scripting language is out of the question.
Our specific requirements are:
Noteably better performance than the Microsoft JScript (ActiveScript) engine
Better runtime performance and/or
Retention of pre-parsed or compiled scripts (don't reparse on every run)
Lower or equal memory consumption
Full ECMA-262 ECMAScript compatibility
a little porting can be tolerated
Injection of custom objects into the script namespace
.NET objects (not a hard requirement)
COM objects or COM objects wrapped in .NET
Instantiation of COM objects from Script
à la "new ActiveXObject(progid)"
Low priority given the preceeding
Include files
Pre-loading of "helper scripts" into a script execution context
An "include" function or statement (easy to create, given the above)
Support for code at global-scope
Execution of code the global scope
Retention of values initialized at global scope
Extraction of values from the global scope
Injection and replacement of values at the global scope
Calling of script-defined functions
with parameters
and with access to the previously initialized global scope
Source-level debugging
Commercial or Open Source Support
Non-obsolete APIs
I answered a similar question here. Have a look at IronJS, an implementation of JavaScript in F# running on the DLR.
Sooner or later, I imagine someone will write a DLR Javascript. I know that's not very convenient for you right now, but maybe you could start the project. I suspect it would have a better cost/benefit analysis to using JScript.NET.
If moving away from .NET and Microsoft is ok for you then you should try Mozilla's Rhino. It is an open-source implementation of JavaScript written entirely in Java. Alot of modern server side js libraries target this platform.
I have used CSScript.net as it will allow you to run C# as a scripting platform. From the site:
CS-Script combines the power and
richness of C# and FCL with the
flexibility of a scripting system.
CS-Script can be useful for system and
network administrators, developers and
testers. For any one who needs an
automation for solving variety of
programming tasks.
CS Script satisfies all the conditions that you laid out. I have used it in production as a substitute for Boo it has performed really well. You can see it in action here.
The use of Com interop means you are limited to an MS solution Java and Opensource want as little as possible to do with it.
I dont see any solution that supports all your requirements either you ditch all the COM/.NET stuff and go Java (Rhino) /Linux/Open source or you question the use of Javascript as your server language even in the Linux world we use PHP/Python/Ruby more on the server if we cant run Java. Your not going to see big performance gains with Java script as the language is the main barrier.
I wouldnt count on people writing a new DLR as server Java script is dying fast.
Considering you want performance ,what about F# , Microsoft will keep the Jscript engine supported for at least 5 years giving you time to create new stuff in F# while you slowly migrate the code.
Have you seen ROScript?
http://www.remobjects.com/script.aspx
Supports both PascalScript and ECMAScript (Javascript) syntax
The Jurrassic-Engine is alive and kicking.
From their codeplex site:
Supports all ECMAScript 3 and ECMAScript 5 functionality, including ES5 strict mode
Well tested - passes over five thousand unit tests (with over thirty thousand asserts)
Simple yet powerful API
Compiles JavaScript into .NET bytecode (CIL); not an interpreter
Deployed as a single .NET assembly (no native code)
Basic support for integrated debugging within Visual Studio
Uses light-weight code generation, so generated code is fully garbage collected
Tested on .NET 3.5, .NET 4 and Silverlight