After posting the previous blog entry on Mono IL code, Marek Safar and Miguel de Icaza from the Mono team noticed that I had made the rather embarassing mistake of compiling the code in debug-mode when compiling with Microsofts compiler. That left me with quite a red face, but now is the time to do it properly.
For this test I have written a small application that computes prime numbers using a rather inefficient but simple algorithm. The program calculates the prime numbers between 2 and 100,000 (yeah, I just love primes). This is done 1,000 times and the average execution time is displayed. (more…)
When working on RemotingLite and MPAPI I came across a couple of oddities, and a single fact that one might expect:
- Mono”s gmcs.exe compiler generates much less IL code than Microsofts csc.exe.
- Code compiled with Mono”s compiler runs more efficiently on Microsofts runtime than code generated with Microsofts compiler.
- Code compiled with Mono”s compiler runs significantly slower on Mono”s runtime than Microsoft-compiled code on Microsofts runtime.
Keep in mind that this has only been tested with a couple of applications, and that Mono might not be fully optimized to run on my laptop with Windows XP as an operating system. For that this little test cannot be thought of as anything remotely conclusive. Furthermore I am not an expert on Mono, and perhaps I have left out some compiler optimizations that I am simply unaware of. If that is the case then please contact me.
Test setup
For this test I have compiled the RemotingLite v.1.2.3 and MPAPI v.1.0 frameworks with gmcs.exe. I have Mono 1.2.6.0 and Microsoft .NET 2.0 and 3.0 installed on my system. The tests have been done with the two sample applications I wrote for the MPAPI framework. (more…)
After weeks of writing, rewriting and testing the code for the Message Passing API (MPAPI) it is finally finished.
MPAPI is a framework that enables programmers to write concurrent, parallel and/or distributed software systems – in essence building cluster computers. I started writing it for a couple of reasons:
- My research into genetic programming (GP) was stalling a bit due to limited computing resources. Since I have a few computers around the house I wanted to enlist them in the huge computations that are necessary in GP, and I wanted to write a framework for building such distributed systems.
- For years I have written multithreaded (concurrent, parallel) software using the normal constructs for that in C++, Java and C#. Time and again I have debugged such applications, and I have yet to see a multithreaded program that is bugfree. It is simply too complex to write such applications using the normal synchronization mechanisms in languages with shared state concurrency. After writing a bit of Erlang code I was profoundly pleased with the way that language handles concurrency, and the ideas I have learned from that language has been incorporated into MPAPI. (more…)
Version 1.2 of the RemotingLite has now been released. Head on over to CodePlex to get the source and binary.
In this release
This release focuses on performance improvements. Up until version 1.1 the framework just used a BinaryFormatter to serialize an entire message to and from the service host. This is now done in a much more efficient manner.
Furthermore the service host will not send method arguments back to the client unless they are passed by reference. This was just a result of poor programming.
Finally I have tuned the transport protocol a bit. All this makes the framework much more efficient.
More to come?
I wrote this framework to provide remoting for the Message Passing API. Originally I used Windows Communication Foundation but that won”t work well on Mono.NET.
The rewritten MPAPI framework is currently being tested and as that progress I learn about shortcomings and bugs in the RemotingLite framework as well, since it is being tested in a “real world” situation with multiple distributed nodes. Hence I cannot guarantee that version 1.2 is the final release.
Remote method invocation has always been an issue in software development, especially when writing distributed enterprise level applications.
The Microsoft .NET runtime supports remoting, webservices has been used for years, and with the advent of version 3.0 of the framework Microsoft introduced Windows Communication Foundation (WCF). WCF greatly simplifies writing distributed software by encapsulating the transport mechanisms used – be it TCP, MSMQ, WS-* or some else – as well as security.
Unfortunately WCF does not run on the Mono.NET runtime, and System.Runtime.Remoting is a bit esoteric. So I have written a small framework which uses messages across a TCP channel to invoke methods remotely. The framework enables programmers to easily write distributed service oriented applications with a minimum of boiler plate code. Clients are produced by using Reflection.Emit to dynamically generate IL-code that delegates method calls to a host.
Read more and get the source and binary here.
How do we write secure, robust, scalable, mutilthreaded software? There are several aproaches, and no definitive answer to this question. But the recent advent of multicore processors have put a new emphasis on how we as programmers write software that can utilize this new hardware architecture so that the processors are not idle and we get maximum performance.
Traditionally we write sequential programs. That is what programmers are taught, and it is easy to understand the flow in the software. Programmers are also taught that we should avoid multithreading whenever possible, because chances are that bugs will be present – indeed one gets the feeling that bugs are inherent in multithreaded software. And the fact is that getting multithreading right in imperative languages like C++, Java or C# is extremely hard; the primitives provided in these languages for handling threads and their communication are not adequate. It might look simple on paper, but multithreaded software is rarely as simple as the textbook examples. (more…)