Writing fast native applications, with API calls and etc, in a modern cross platform programming language like C# would be awesome, wouldn't it? For example if you want to write a simple utility for helping IT people with installing things, which wouldn't need another components, in an easy and modern programming language? or if you want to write a 3D game, it should be fast, and JIT would just make it slower...
Why, why isn't it possible? Why there are no native modern programming languages for these things?
C# and .Net are native code. I think you misunderstand the JITter. It's not a VM. A C# program is compiled to fully native code before any of it is executed.
Now, the "needing other components" part is a concern. Give it time, though. You'll be hard pressed to find a windows installation these days without at least .Net 2.0, and even a couple mainstream linux distros include mono out of the box.
Don't assume the JIT makes things slower. The JIT can optimize for the exact computer running the application rather than a generic computer like a 386 or Pentium. It can even make better speed/memory trade-off decisions when generating code because it knows exactly what's available. And if JIT still makes things slower, you can NGEN them so that JITting is all done beforehand.
As proof of this, consider that Quake has been ported to the CLR a couple of times, and in my personal tests, the frames per second have been faster when Quake runs on the CLR about half the times I demo it.
Compiled .NET programs have been shown to run just as quickly as C. If you want it ultra-lean write it in assembly for your native processor.
You can use the Microsoft NGEN.EXE tool to create a native image of a .NET assembly.
See MSDN NGEN documentation. Microsoft already though about what you're getting at here.
Microsoft also makes ILMERGE.EXE tool to merge multiple assembly files into one. This might border on optimization and speed too.
As a side note, Mono has full ahead of time compiling, eliminating the runtime. (I think that's how they get away running on iPhone, which prohibits any JIT.)
So, does this mean that we could fully compile and link a C# program using (limited) .NET calls into a standalone EXE that would run without .NET being installed at all?
FYI: Checking a server estate of some 5000 servers revealed about 200 without even .NET 2.0.
This causes problems for code that must run on "all Windows instances". With .NET 4.0+ not including 2.0 this gets worse as both new AND old Windows machines might not have the 'right' .NET
there is, C. C can be used to write any application , ever !!!
Related
As .net matures, the JIT capabilities have been improved to be brilliantly lazy. That is, don't produce machine code if it isn't needed. In general, this is a good thing.
However, if I am trying to warmup an application I may prefer an aggressive JIT stance. Is there a way to configure a .net application so that all methods of a class are JIT compiled, simply because -the class was constructed?
If yes, my favorite object-creational pattern could instantiate my appliation's object-graph, and I would have everything JIT-ready simultaneously. That would be nice.
Can this be done?
As a side note - you could use NGen.exe to produce native image of your dll's at deployment time (NB:It's not a perfect solution - as it has some drawbacks - check out the documentation carefully)
you mean, you want everything ahead-of-time compiled :-)
They finally did this for you - announced at Build 2014:
Somasegar told me that developers told Microsoft that .NET was always
a very productive language to program in, but it didn’t always deliver
the performance they were looking for. “We’ve been working on a lot of
innovation to show developers that .NET is still a very viable
platform for developers who want to build apps in this modern world,”
he said. With the .NET native ahead-of-time compiler, developers will
see faster startup times, lower memory usage and overall better
performance, Microsoft promises. This new feature is currently in
preview and allows developers to target both the X64 and ARM
platforms.
You can try it out (preview only at the moment, and possibly only working for 'universal' apps so YMMV as to how useful it is), more info is available on MSDN
I am trying to decide upon using Mono with C# or Python (Django) for a Linux based Web Site. My concern with C# is that Mono may not be as reliable as .NET. Does anyone have any experience with this?
i do a variety of things using mono/c# on linux - all projects compiled on a windows machine, no less.
i've done services, web sites, console apps, you name it. unless you're doing real edge-case things, you should have no problems.
i also run sites using lighttpd + fastcgi + mono with no problem. i love it
I think it's a given that Mono is less reliable than .NET on Windows, given the resources available for development, and the size of the user base. How much less is a moot point.
This blog post from Miguel de Icaza illustrates the sort of problems that would concern me when using Mono.
However I can't give you any comparison of Mono and Python.
This depends what you are doing. If you are creating a non-enterprise website, you should do fine with ether. I've heard good things about Mono. The problem with using Mono is that it is constantly playing catchup with MS and that it has to support multiple platforms, whereas MS does not. I have written desktop applications with mono, but I have never done website related things with it. With C# and the Windows platform, your best bet is the MS implementation. My recommendation would be to use Python.
I can not speak for the supportability, reliability, etc of Django, but Python has been arround for a while, and it has a long track record for working well on Linux/Unix.
Personally, I would steer you away from using C# (Mono) if you are targeting Linux.
Your development community could be very small for any platform issues; while there are obviously a lot of C# developers, the number who use Mono is relatively tiny1.
In my experience, there are a lot of issues with even finding a recent version of Mono for Linux, unless you run SUSE2.
While Mono may have the features you want, and may have the reliability (I can't comment, I'm still using 1.x!) you may also want to look into the speed if you expect heavy usage.
If you plan to deploy to more machines (especially if you can't clone them) these are much more of an issue; they matter somewhat less if it's just one server.3
There are some who have concerns about the threat of lawsuits over Mono technology, and what might happen to the end users (you and your users) if those occurred. From what I've read, I'm not overly concerned, but I am not a lawyer.
Good luck.
I could be mistaken; I didn't look at download numbers for Mono although that'd be the
upper bound.
Ubuntu Karmic (9.10) has Mono 2.4, but I regret I upgraded from Jaunty (9.04) which had 1.9.
Building from source can be taxing. And there are other sources for the Mono 2.X binaries, but they aren't easy to locate.
This might be pure speculation, but here is my experience. I'm using ubuntu and mono (as well as monodevelop) is shipped 2 years behind current version. You could compile newer one, but that's pain. I've used it in 3 hobby projects, here is my conclusion: comparing to microsoft implementation it's buggy and has memory leaks and slower. Well, most of the time it will work, but should you stress your software and you'll see. I wish I knew C++ as good as C#, so I could go with it on linux. All applies to v. 2.10 and below.
I have the following questions:
Is it possible to compile a C# project using VS.NET, and run it on mono?
Are there any performance benefits associated with approach 1 (vs compiling with the mono compiler)?
What about running the output .exe/.dll on linux? And what are the associated performance characteristics?
Thanks
Yes, you can do that. It should work unless the code uses some framework elements that are not implemented on mono.
Not that I am aware of.
Not sure what the difference between #3 and #1 is. If you are referring to using mono to compile on Windows, then porting it to linux, it should still work the same. Both compilers generate essentially the same IL code.
1:
Yes. The compilers compile into IL code, which runs in either system.
Not every library is implemented in Mono, but those that are should work seamlessly. Also, the code has to be written to be independend of the system to work properly, for example:
Use Path.DirectorySeparatorChar and Path.Combine to form file paths, instead of using the string literal "\" or "/".
Use the BitConverter class to do byte manipulation that is independend of big-endian / little-endian achitecture.
2:
There may be some differences in what code the compilers generate, but as almost all optimising is done by the JIT compiler that should rarely make any measurable difference.
3:
The exe and dll files does not contain native code, they contain IL code. The native code is generated by the JIT compiler when the exe/dll is loaded.
To expand on others answers:
For point 3. Yes there will be a performance difference when using MSCLR vs Mono, and no, I don't know what it will be. Maybe nothing, maybe little or perhaps one is vastly faster - you'll have to profile your specific application.
Note also, that notwithstanding the speed of the code made by the JIT compiler, the libraries will be implemented very differently and will almost certainly have varying performance characteristics.
If you plan on supporting your application under Mono, you will need to run performance testing there as well as MS CLR.
I don't know about the performance but this article attempts to show how to compile the MonoDevelop tool under vs. This should give you some idea as to what the differences will be.
in other words, now that we have Mono, has C# become just as OS-agnostic as Java when it comes to server-side web applications? Or are there still big limitations having to do with what Mono can/cannot do or maybe with what libraries can be made available to a C# server-side app on Linux?
The answer to 'can any (or most of) the ASP.NET apps be made to run' is YES. There's a page with some common pitfalls: Mono: Porting ASP.NET Applications (also of interest the Porting WinForms applications page)
The most common problems I've seen in the field[1] are, by number of occurrences:
Code that is not aware of case-sensitive filesystems or careless about file/path handling. These ones require work.
P/Invokes: there are a lot of P/Invokes to Windows native functions. Most of them are not supported in Mono (nor they make sense in a unix environment). However, we have mappings for a few or the most common ones (CloseHandle and such). These ones require redoing the same things using a .NET API.
Bugs: believe or not, there are still bugs in the 3M+ lines of code. We try to be responsive and fix bugs as soon as possible (and we'd love to do more, blame it on the 24h rotation period). The simpler the test case to reproduce the problem, the faster it gets fixed. File a bug report and we'll try to fix it ASAP.
Missing or unimplemented APIs: we still have these and try to focus on the most used ones. Some times we use the Moma Reports (see link below) to prioritize.
Take a look at the Moma Reports page, which contains user-submitted data about applications on which Moma has been run.
[1]: the field ranges from one of the largest ASP.NET deployments in the Western Hemisphere to small open source applicatoins.
Yes and no... yes, you can now run asp.net on Linux via Mono.
However, I think in practice you will find many more platform specific limitations than you would with similar Java applications. I rarely see major platform specific issues even in average quality software written in Java.
With ASP.Net, you'll routinely see apps and third party libraries that barely work on Mono, or just don't work at all. The porting effort may not be high, but its much higher than similar Java applications, in my experience.
Not every application:
The Mono API today is somewhere in
between .NET 2.0 and .NET 3.5 see our
Roadmap for details about what is
implemented.
From Can Mono run binaries produced by Visual Studio? in the Mono Faq General. You can view the detailed state of ASP.NET in Mono in the ASP Tests page.
A lot of useful information here from the Mono Team.
http://www.mono-project.com/ASP.NET
What can be done in VC++ (native) that can't be done with VC#?
From what I can tell the only thing worth using VC++ native for is when you need to manage memory yourself instead of the CLR garbage collector, which I haven't seen a purpose in doing either (but thats for another question to be asked later).
Cross-platform development. Yes Mono exists, and Java's somewhat more predictable to have it function EXACTLY the same on more platforms, you can find a C/C++ compiler for just about any platform out there, where you can't with C#.
Also linking into 3rd-party libraries, while I'm sure there's a way to leverage them in C#, you'll be able to take advantage of them without interop (Marshaling, etc) in C++.
Edit: one last thing: RELIABLE memory management. Yes you can use dispose(), and try-finally, but there's nothing quite like KNOWING the memory is gone when it's popped off of the stack. Through techniques like RAII, when you use well-constructed classes, you will KNOW when your classes release resources, and not waiting around for the GC to happen.
With P/Invoke there is very little that is impossible in .NET (most obviously device drivers).
There are also things where the advice is to not use .NET (e.g. shell extensions, which get loaded into any process that opens a file dialogue1).
Finally there are things which will be much harder in .NET, if possible at all (e.g. creating a COM component that aggregates the FTM).
1 This can create a problem if that process is already using a different version of .NET. This should be alleviated in the future with .NET 4 having the ability to support side by side instances of the runtime.
I'm not sure if you're talking about language features or applications. My answer though is for applications / components.
Really there are only 2 things you cannot do in C# that you can do in C++.
You cannot use C#, or any other .Net language, to write a component for a system that only accepts native components
You cannot use C#, or any other .Net language, to alter certain properties of a CCW for which the CLR does not allow customization
The most notable item here is Device Drivers. This is a framework that only accepts native components and there is no way to plug in a managed component.
For everything else it's possible to do the same thing in C# as it is in C++. There are just a lot of cases where you simply don't want to and a native solution is better. It's possible for instance to manage and manipulate memory in C# via unsafe code or IntPtr. It's just not nearly as easy and generally there's no reason.
You can't write device drivers for one.
I think there are several important points:
You can do anything in C#/C++/Java/Python/Lisp or almost any other language, finally all of them Turing complete ;)... The question is it suits your needs?
There is one big and extreamly important limitation of C#... It runs only one single platform Windows... (Mono is still not mature enough).
There are many applications where GC is just a waste of resources, applications that can't afford you throw up 1/2 of memory untill next gc cycle: Games, Data Bases, Video auido Processing and many other mission critical applications.
Real Time applications (again games, video processing and so on). Non-deterministic GC makes life much harder for them.
In fact, most of desktop applications: Web Browsers, Word Processors, Desktop Environment itself (like Windows Explorer, KDE or Gnome) are written in compiled languages with careful thinking about resources... Otherwise, they would just be terrible bloated applications.
Whereas writing shell extensions in Windows XP was possible in C# it is next to impossible to write shell extensions for Vista and Windows 7. Shell extensions and Namespace extensions (and anything else that uses the new Properties system) (kindof) must be done in C++ unless you're into pain.
There are two obvious answers:
VC# can never run without the .NET
framework. Native C++ can. That may
be necessary in some areas (others
have mentioned device drivers, but
more common examples might simply be
clients where the .NET framework is
not installed. Perhaps you're
distributing an application and you
know not all of your customers are
willing to install .NET, so your
sales would go up if you made an app
that just worked without the
dependency on .NET. Or perhaps you're
working on some mobile device where
the couple of megabytes taken up by
the .NET CF can not be justified. Or shell extensions where using .NET can cause nasty problem for the user.
And VC# can never use C++ language
features. Native C++ can. (Managed
C++ can too, of course, but that's a
different issue). There are, believe it or not, things that can be done more conveniently or elegantly in C++. And they're only accessible if you're programming in C++.
System calls are no problem, however. p/invoke lets you do those from C#, almost as easily as you could from C++.
inline assembler
You cannot use C++-Libraries with classes (P/Invoke can only be used for functions AFAIK)
You cannot use callbacks with P/Invoke.
Is C# in particular and .NET in general self compiling yet (this is not a troll, I genuinely don't know)? If not, you can use VC++ to write C# and .NET, but you can't use C# to do the same job.
This is tongue in cheek, but it also is an answer to your question... you can screw things up much more severely in VC++ than you can in VC#. Not that you can't manage to screw things up severely in VC#, but in general, you can screw them up easier and more thoroughly in VC++.
Again, kind of tongue in cheek, but also an answer to your question. Perhaps not what you were hoping for, but... :-)
There's also hard real-time applications. Any language with a GC cannot be used, just in case it decides to collect during a time-constrained part of the code. Java was notorious for not even allowing you to try (hence the EULA about not using it for software "intended for use in the design, construction, operation or maintenance of any nuclear facility"
(yes, I know they've since made a modified version of Java for real time systems).
For example, it makes sense to use C++ if it's harder to translate the header files for existing libraries than it is to give up the existing managed libraries.
The Main difference is:
C++ is a core language with which you can build stand-alone programs. These Programs communicate directly with the the operating system and nothing else. C++ compilers exist for more or less all platforms (operating systems).
C# is a language that conforms to the CLS. A program written in C# can not start without a CLI engine (.NET Framework, Mono, etc.). A Program written in C# communicates with the .NET framework AND with the operating system. You have a man in the middle. Like all servicing personal, this man can help but it will cause additional trouble. If you want to port, you have a different man in the middle etc. CLI Implementations do not exist for all platforms.
By my opinion every additional framework is a additional source of problems.
Using SSE instructions seems to be one of these cases. Some .NET runtimes will use some SSE instructions, depending on your code. But in VC++, you can use the SSE intrinsics directly. So, if you're writing a multimedia code, you'd probably want C++. (C++/CLI might work as well, presumably)