A new version of DotGNU’s Portable.NET and libjit (designed to be independent of any particular virtual machine bytecode format or language)
has been released. There are a lot of new features, enhancements and bug fixes accompanying this release.
DotGNU Portable.NET 0.7.4 / LibJIT 0.0.6 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Thought you guys were dead or something.
Good to see that the project is still moving forward, even if slowly.
Do they currently share any code in the class libraries? How does the VM quality compare? It would seem that Mono has had some fairly serious issues getting a quality VM/GC combination put together and it has suffered from some stability issues. Is Pnet any better?
…It would seem that Mono has had some fairly serious issues getting a quality VM/GC combination put together and it has suffered from some stability issues…
Can you please mention which are these serious stability issues?
It would help us all understand and serve as the bases of comparison with PNET.
Monos biggest goal is to have a nice environment to program Gtk+/GNOME-programs in Gtk#.
PNets biggest goal is to be most compatible with MS.NET (from the library-side). So the SWF is in PNet more advanced.
On the other side, Mono have a lot of more developer. So mcs (Monos C#-Compiler) is more advanced then PNets cscc.
PNets Compiler compile C# and C code to IL Code. And you can mix C# and C in one file.
Monos mcs can only compile C#-Code. But that is more like the C#-Compiler of Microsoft. It can not compile C-Code, but have the C# 2.0 enhancements, which PNets compiler don’t have.
Monos mcs is itself written in C#. PNets cscc is written in C.
Mono used IKVM for Java-programs. IKVM is a JVM for .net. So Java-programs running on IKVM which runs on Mono. And with it you can use .net-libraries in Java and the other way around.
DotGNU wants to have its own virtuel machine, which can run .net and Java and which should be easyly exteded for other virtual machine-langages.
Mono on the other side, want that the .net/mono-platform is the basis of all. Thats the reason why they let run a JVM on .net.
Gtk# works with PNET and already for long. http://handhelds.org/~krokas/screenshots/
Monos biggest goal is to have a nice environment to program Gtk+/GNOME-programs in Gtk#.
That’s not true at all. Mono has also as a goal to achieve compatibility with .NET, since we want to re-use thoso codes that the developers in Windows create (we wanted to create an easy way to let those coders ‘port’ it to Linux systems). Obviously, the Gtk# side is very important to us, but not the only one goal.
And about the Windows.Forms area, we are next to release the 1.2 version of Mono, which provides a much much better support of it.
On the other side, Mono have a lot of more developer
Wehn you think about the differences between the two projects (technical ones, specially) it’s rather useless to speak about these things IMHO.
Carlos.
On the other side, Mono have a lot of more developer.
This isn’t as important as you make it out to be. Look at some of their ChangeLog entries from the release announcement:
* Integrate Mono’s latest regex code (Rainer Größlinger).
* Merge in Mono’s changes to jit-gen-x86.h (Aleksey Demakov).
Mono’s class libraries are licensed under the MIT/X11 license. PNet can import all of Mono’s class libraries, if they so desired, so in a sense all of Mono’s developers are also working on PNet. (How (im)practical this is can be debated, especially when internal calls enter the picture, but in theory large amounts of code can be integrated from Mono into PNet.)
Mono’s runtime libraries (JIT, etc.) are LGPL, which can also be used by PNet (as evidenced by the reference to jit-gen-x86.h).
The biggest problem is likely that the Mono developers don’t regularly test their code under PNet, which would allow any shared code to diverge and break when used by PNet. I don’t know how likely this is though…
It would seem that Mono has had some fairly serious issues getting a quality VM/GC combination put together and it has suffered from some stability issues
I don’t know what are you talking about (seriously). It’s a little dangerous to put a comment like this, because you are not specifying teh exact problem you are suffering.
Anyway, Mono is not having those serious problems you are talking about, because the JIT runs fine (it could be tuned in some areas, but tha’s taking some time, but there are people working on it). In the GC side, we are using the conservative Boehm GC, which has proved to be a very good solution in this area; observe, however, that a generational GC is going to be plugged in the nexts months (I don’t know if that’s going to be before or after the 1.2 release).
And I can’t speak about the stability problems, specially because we have some arquitectures supported, so it could be habppening in one of them (at least x86 runs fine).
Hope it makes it clear (on the Mono side, becasue I don’t know about pNet)
Carlos.
Yes, I know, my comment was a little dangerous. If I knew the system well enough to put all the details, I would have (and probably will post some to the mono list as I gain more experience with the platform). Having said that, here are my experiences:
1. I’ve used the system for a very limited time with a few simple ASP.Net applications and some client code (all managed). I’ve seen various crashes during the limited time testing on the platform that should not happen in a server application (took down XSP2 completely). One day, I’ll take the time to get more details into the Mono bug database, in the mean time, I keep testing new releases.
2. GC — The current one is non-compacting at the moment, which can lead to memory leaks through fragmentation. Hopefully the generational collector will fix this, but obviously it has not yet been released.
3. JIT — Well, I didn’t specifically mention this, as I’ve seen pretty good performance out of Mono generally.
In any case, I do see steady improvement over there, and the code that I’ve seen in the class library is generally very well done.
pnet uses code from the Mono project both in their core libraries and as a separate package (they use an old version, though, since their compiler is too limited to compile it).
As for stability issues: Mono and Portable.Net are not comparable. pnet can’t even execute most of the programs that run on Mono (for example even a few of the Gtk# simple samples fail with pnet). This is because both pnet lacks many of the runtime features that mono has (like full appdomain, serialization, reflection.emit support) and because it is not as widely tested as Mono, so it has lots of little bugs. It is also too slow to execute, so for a range of programs, you can’t even test if it is stable.
As for the GC: even though both Mono and pnet use the Boehm GC library, Mono uses it in advanced mode (typed allocations for examples), while pnet doesn’t take advantage of some of the features, so it suffers more from memory fragmentation and other issues of a conservative GC.
“a few of the Gtk# simple samples fail with pnet” Testcases, please?
“It is also too slow to execute”. In fact it is the Mono Just-In-Time compiler engine which is too slow to execute for the amount of memory it uses. For example on ARM: the Mono JIT uses so much memory that it become absolutely useless for .NET programs runing on ARM or MIPSEL based systems.
As for the speed — on my iPaq 3950 (ARM Linux) the PNET Dynamic Compiler has a 70% average performance of the Mono JIT engine and a 300% speed up on floating point operations. Floating point operations are very critical for speed performace of GTK# and Windows.Forms apps runing on ARM based systems.
If to speak about x86 based systems, about features and speed performance, well, one still cannot run Quake 3 rewriten for .NET with Mono.
The PNET Dynamic Compiler engine is an excellent compromise within the amount of memory used and speed performance.
Edited 2006-01-31 06:58
“a few of the Gtk# simple samples fail with pnet” Testcases, please?
You could do a tiny bit of homework: just go in the gtk-sharp/samples dir and try them out. For example fifteen dies on exit.
“It is also too slow to execute”. In fact it is the Mono Just-In-Time compiler engine which is too slow to execute for the amount of memory it uses.
I’ll just note that Mono generally uses less memory than ilrun. Try for example the fifteen sample, mono uses 31848/14244 (VSZ/RSZ) and ilrun 32260/19632.
Also, large programs will use less memory with Mono because mono uses the Boehm GC library in a more precise mode, so it will have a less fragmented heap and a much lower rate of pointer misidentifications.
As for the speed — on my iPaq 3950 (ARM Linux) the PNET Dynamic Compiler has a 70% average performance of the Mono JIT engine and a 300% speed up on floating point operations.
So ilrun uses more memory and it is still slower in a pnet-specific benchmark, good to know:)
Googling it seems you used pnetmark. On ARM one of the subbenchmarks is fp-related and since it’s emulated by the kernel the speed differences are limited (with scimark mono is only 2 times as fast as ilrun, while on x86 it is faster by one or two orders of magnitude).
This benchmark is also intersting, because one of the subtests is faster with ilrun: this is because pnet doesn’t implement collation of strings correctly or at all, so you get (wrong) results faster. Once you enable jit optimizations and run without collation support also in mono, you’ll find that mono is more than twice as fast in the overall score even of this flawed benchmark.
Floating point operations are very critical for speed performace of GTK# and Windows.Forms apps runing on ARM based systems.
You never tried running the treeviewdemo Gtk# sample, I see. It takes about 6 minutes on my x86 box vs 15 seconds with mono. I wouldn’t want to run it with pnet on an ARM system.
The PNET Dynamic Compiler engine is an excellent compromise within the amount of memory used and speed performance.
The pnet engine has advantages only for platforms where the mono jit has not been ported yet (and this is an increasingly small subset). And it is also easy to prove that ilrun will never use significantly less memory than mono. The only practical difference in favour of pnet vs memory usage is in the size of the in-memory representation of the code to execute.
Mono’s representation is optimized native code which amounts to about 2.5x the size of the original IL code.
ilrun uses both a bytecode representation which is less dense than IL and unoptimized binary code for the chunks it can translate. This means an overhead of 1.5-2 times over IL code.
Typical apps run with mono generate less than 500 KB of native code, so for a memory advantage that is almost down to noise, with ilrun you just have a huge performance downside.
Why with all the gigabytes of memory available on modern desktop systems, you have designed the Mono JIT to use only 500 KB on memory? Yes, I agree for a Just-In-Time compiler which uses only 500 KB on memory speed performance of Mono JIT is fantastic.
Do you know that on modern CPUs several simple instructions is usually better than one complex instruction, even though it may not seem like it, don’t you? On the 386 and 486, code size was the most important factor in execution speed. Now with L1 and L2 caches on CPU’ssize is not as important as what the instructions actually do.
Much more interesting would be to allow the end-user to select what is important for him (speed performance, memory used, startup time or the maximum time of JITing of each function), allow him select a value of that factor and do an in-built automatic optimization with this fixed value. But I image that for this you should stop talking about current Mono JIT as a best achievement in software development that ever was in the history of IT.
Edited 2006-02-01 22:54
Your view of cache issues is peculiar, that is the opposite of what really happens with modern processors.
I suggest you consult some literature on the subject.
Mono generates larger sequences of code when needed for speed, but generally the smaller the code, the better, since reduced icache footprint is a big win on modern processors.
As for your tuning reference: I suggest you read the mono manpage, especially the –optimize option section.
I would like to see a compariosn of Mono and dotGNU too.
On which areas Mono has more to offer and on which does dotGNU? How complete are both implementation?
Personally i’m a little bit sad about dotGNU doesn’t support Gtk# as good as Mono. dotGNU is a GNU project and Gtk+ is a GNU project so actually Gtk# should be the toolkit no.1 of dotGNU. But dotGNU seems to run behind windows (windows.forms, which is in some sense already outdated and wpf is the future) instead integrating Gtk# well into itself.
>> Do you know that on modern CPUs several simple instructions is usually better than one complex instruction, even though it may not seem like it, don’t you? On the 386 and 486, code size was the most important factor in execution speed. Now with L1 and L2 caches on CPU’ssize is not as important as what the instructions actually do.
> Your view of cache issues is peculiar, that is the opposite of what really happens with modern processors.
Your view is quiet specific. I suggest you consult some literature on the subject. For example, look how works memcpy optimized for modern Intel or AMD CPUs.